View all questions & answers for the NSE 6 - Network Security 7.6 Support Engineer Materials exam
NSE 6 - Network Security 7.6 Support Engineer Materials - Question #91 Discussion
Community Explanations & Comments (4)
Adam
9 months ago
Selected: 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
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
8 months ago
Selected: 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.
Anonymous User
6 months ago
Selected: C, D
The correct answers should be C & D. Below are reasons why A & B are not correct
A. Policy route misconfiguration: Policy routing usually results in a packet being sent out the "wrong" interface or failing a lookup in the fib_lookup (Forwarding Information Base), not specifically an iprope_in_check failure.
B. Traffic shaping: Traffic shaping (Rate Limiting) typically results in drops labelled as "shaper drop" or occurs much later in the egress process once the policy has already been accepted.
A. Policy route misconfiguration: Policy routing usually results in a packet being sent out the "wrong" interface or failing a lookup in the fib_lookup (Forwarding Information Base), not specifically an iprope_in_check failure.
B. Traffic shaping: Traffic shaping (Rate Limiting) typically results in drops labelled as "shaper drop" or occurs much later in the egress process once the policy has already been accepted.
Anonymous User
6 months ago
Selected: C, D
check KB https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Debug-flow-messages-iprope-in-check-check/ta-p/190119
What are two reasons you might see iprope_in_check() check failed, drop when using the debug flow? (Choose two answers)
Brave-Dump Community Votes