View all questions & answers for the NSE 6 - Network Security 7.6 Support Engineer Materials exam


Question 92 Discussion

What are two reasons you might see iprope_in_check() check failed, drop when using the debug flow? (Choose two answers)

  • A. Packet was dropped because of policy route misconfiguration.
  • B. Packet was dropped because of traffic shaping.
  • C. Trusted host list misconfiguration.
  • D. VIP or IP pool misconfiguration.
Correct Answer: A,D

Brave-Dump Clients Votes

AC 50%
AD 50%

Comments



Adam 2026-01-07 03:08:10

Selected Answers: A, C


As per Study Guide, one of "iprope_in_check() check failed" debug log reasons is "The source IP address is not included in the trusted host list", so C is correct

As tested in my LAB,
-> Policy-based route (PBR) for transit traffic (source and destination don't belong to FortiGate), but with next hop set to same IP address of egress interface (so it simulates that misconfiguration), and setting Debug Flow, I was able to see "iprope_in_check() check failed" in logs, so A is correct
-> VIP for extip belonging to FortiGate outside interface and mappedip belonging to FortiGate inside interface, and configured firewall policy and local-in policy, I could see from logs that traffic was only hitting firewall policy, and never hit local-in policy for some reason, so D is wrong

Mehdi 2026-02-13 16:33:17

Selected Answers: A, D


Trusted hosts restrict management access (local-in traffic to FortiGate itself). While they can cause similar "iprope_in_check() ... policy 0, drop" for management protocols (e.g., ping/HTTPS to interface IP), this is more common in local-in policy checks or SSL VPN scenarios, not general forward/through traffic debug flow drops.