Troubleshooting Tip: Traffic dropped when firewall policy is permitting traffic
Description
When a firewall policy is configured to permit specific traffic, it may be seen that sometimes communication cannot be completed.
When troubleshooting connection problems, the following type of debug flow commands can appear, matching firewall policy configured but dropping traffic.
Example:
Policy 12, Action “Accept”
id=20085 trace_id=20 func=print_pkt_detail line=4478 msg="vd-root received a packet(proto=6, 192.168.1.10:53131->201.146.13.2:22) from internal. flag [S], seq 2985426820, ack 0, win 8192"
id=20085 trace_id=20 func=init_ip_session_common line=4631 msg="allocate a new session-00bc3835"
id=20085 trace_id=20 func=iprope_dnat_check line=4633 msg="in-[internal], out-[]"
id=20085 trace_id=20 func=iprope_dnat_tree_check line=835 msg="len=0"
id=20085 trace_id=20 func=iprope_dnat_check line=4646 msg="result: skb_flags-00800000, vid-0, ret-no-match, act-accept, flag-00000000"
id=20085 trace_id=20 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-170.166.13.1 via wan1"
id=20085 trace_id=20 func=iprope_fwd_check line=630 msg="in-[internal], out-[wan1], skb_flags-00800000, vid-0"
id=20085 trace_id=20 func=__iprope_tree_check line=543 msg="gnum-100004, use addr/intf hash, len=34"
id=20085 trace_id=20 func=__iprope_check_one_policy line=1833 msg="checked gnum-100004 policy-18, ret-no-match, act-accept"
id=20085 trace_id=20 func=__iprope_check_one_policy line=1833 msg="checked gnum-100004 policy-13, ret-no-match, act-accept"
id=20085 trace_id=20 func=__iprope_check_one_policy line=1833 msg="checked gnum-100004 policy-12, ret-matched, act-accept"
id=20085 trace_id=20 func=__iprope_user_identity_check line=1668 msg="ret-matched"
id=20085 trace_id=20 func=__iprope_check_one_policy line=2014 msg="policy-12 is matched, act-drop"
id=20085 trace_id=20 func=iprope_fwd_auth_check line=682 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-12"
id=20085 trace_id=20 func=fw_forward_handler line=561 msg="Denied by forward policy check (policy 12)"
When troubleshooting connection problems, the following type of debug flow commands can appear, matching firewall policy configured but dropping traffic.
Example:
Policy 12, Action “Accept”
id=20085 trace_id=20 func=print_pkt_detail line=4478 msg="vd-root received a packet(proto=6, 192.168.1.10:53131->201.146.13.2:22) from internal. flag [S], seq 2985426820, ack 0, win 8192"
id=20085 trace_id=20 func=init_ip_session_common line=4631 msg="allocate a new session-00bc3835"
id=20085 trace_id=20 func=iprope_dnat_check line=4633 msg="in-[internal], out-[]"
id=20085 trace_id=20 func=iprope_dnat_tree_check line=835 msg="len=0"
id=20085 trace_id=20 func=iprope_dnat_check line=4646 msg="result: skb_flags-00800000, vid-0, ret-no-match, act-accept, flag-00000000"
id=20085 trace_id=20 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-170.166.13.1 via wan1"
id=20085 trace_id=20 func=iprope_fwd_check line=630 msg="in-[internal], out-[wan1], skb_flags-00800000, vid-0"
id=20085 trace_id=20 func=__iprope_tree_check line=543 msg="gnum-100004, use addr/intf hash, len=34"
id=20085 trace_id=20 func=__iprope_check_one_policy line=1833 msg="checked gnum-100004 policy-18, ret-no-match, act-accept"
id=20085 trace_id=20 func=__iprope_check_one_policy line=1833 msg="checked gnum-100004 policy-13, ret-no-match, act-accept"
id=20085 trace_id=20 func=__iprope_check_one_policy line=1833 msg="checked gnum-100004 policy-12, ret-matched, act-accept"
id=20085 trace_id=20 func=__iprope_user_identity_check line=1668 msg="ret-matched"
id=20085 trace_id=20 func=__iprope_check_one_policy line=2014 msg="policy-12 is matched, act-drop"
id=20085 trace_id=20 func=iprope_fwd_auth_check line=682 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-12"
id=20085 trace_id=20 func=fw_forward_handler line=561 msg="Denied by forward policy check (policy 12)"
Solution:
This issue occurs because the IP pool is configured as one‑to‑one NAT while only a limited number of public IP addresses are available.
In a one‑to‑one NAT configuration, each internal IP address must map to a dedicated public IP address. Since Port Address Translation (PAT) is not used in one‑to‑one mode, the same public IP cannot be shared by multiple internal hosts.
As a result, if the IP pool contains only a single public IP, only one internal host can be translated.
Traffic from additional hosts is dropped, generating flow debug messages similar to:
"after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-12"
To resolve the issue, reconfigure the IP pool to use the overload type instead of one‑to‑one.
Overload mode allows multiple internal devices to share a single external IP address by using different source ports (PAT). Refer to: Technical Tip: How to resolve One-to-One IP Pool exhaustion
Overload mode allows multiple internal devices to share a single external IP address by using different source ports (PAT). Refer to: Technical Tip: How to resolve One-to-One IP Pool exhaustion
Related Articles