|
Verifying the true cause:
Topology:
Traffic in vlan10>>>501_WAN1>>>> hairpin routed in vlan10 reuses the existing policy 588.
No configuration change, the hairpin traffic (client PC connects the VIP external IP then forwards the traffic to the same interface) will be dropped once policy ID 588 has been added to an application control profile (monitor all).
Run the traffic flow debug below to identify the issue if related to the bug ID: 1058494.
When snat-hairpin traffic is enabled, SNAT is not automatically applied to hairpin traffic, causing an SNAT mismatch in strict-dirty-session-check: Resolved issues
Debug output:
id=65308 trace_id=2138 func=iprope_reverse_dnat_check line=1284 msg="in-[vlan501_WAN1], out-[vlan10_LAN], skb_flags-020000c0, vid-28"
id=65308 trace_id=2138 func=iprope_reverse_dnat_tree_check line=926 msg="len=0"
...
id=65308 trace_id=2138 func=__iprope_check_one_policy line=2025 msg="checked gnum-10000d policy-0, ret-matched, act-accept"
id=65308 trace_id=2138 func=__iprope_check_one_policy line=2243 msg="policy-0 is matched, act-accept"
id=65308 trace_id=2138 func=fw_snat_check line=673 msg="NAT disabled by central SNAT policy!"
id=65308 trace_id=2138 func=fw_strict_dirty_session_check line=287 msg="SNAT mismatch policy 588 (old nat 1 ! = new nat 0), drop" >>>>> drop happened
config system global
set strict-dirty-session-check disable >>>>> workaround
end
Action plan:
If the debug log matches and the workaround setting takes effect for the traffic flow, it would match the bug id. The firmware needs to be upgraded to v7.4.5 to fix the issue.
|
