Technical Tip: Case study of block intra-zone traffic unexpected behavior

[anikolov]

Description

This article describes a case study use of the block intra-zone traffic feature on different devices with exactly the same configuration and different behavior.

Scope

FortiGate.

Solution

In this case, the scenario is with two different devices, 2000E (NP6) and 1800F (NP7), on the same OS 7.0.12 having the same default configuration, for intra-zone traffic to be blocked. That would mean, that if communication between hosts on the same zone is about to be enabled, a firewall policy with the same zone to the same zone must be configured. 

config system zone

    edit "server_zone"

        set interface "infrastructure"

end

config firewall policy

    edit 123
        set srcintf "server_zone"
        set dstintf "server_zone"
        set srcaddr "192.168.1.10/32"
        set dstaddr "192.168.1.20/32"
        set schedule "always"
        set service "PING"
   next

end

In the case of the 2000E for the debug flow, the output shows:

id=20085 trace_id=1 func=print_pkt_detail line=5844 msg="vd-root:0 received a packet(proto=1, 192.168.1.10:1->192.168.1.20:2048) tun_id=0.0.0.0 f
rom infrastructure. type=8, code=0, id=1, seq=180."
id=20085 trace_id=1 func=init_ip_session_common line=6023 msg="allocate a new session-000060cb, tun_id=0.0.0.0"
id=20085 trace_id=1 func=iprope_dnat_check line=5336 msg="in-[infrastructure], out-[]"

id=20085 trace_id=1 func=fw_forward_handler line=881 msg="Allowed by Policy-123:"
id=20085 trace_id=2 func=print_pkt_detail line=5844 msg="vd-root:0 received a packet(proto=1, 192.168.1.10:1->192.168.1.20:2048) tun_id=0.0.0.0 from infrastructure.
type=8, code=0, id=1, seq=181."

While, for the 1800F device:

id=20085 trace_id=9 func=print_pkt_detail line=5918 msg="vd-root:0 received a packet(proto=1, 192.168.1.10:1->192.168.1.20:2048) tun_id=0.0.0.0 f
rom infrastructure. type=8, code=0, id=1, seq=201."
id=20085 trace_id=9 func=init_ip_session_common line=6098 msg="allocate a new session-00001aed, tun_id=0.0.0.0"
id=20085 trace_id=9 func=iprope_dnat_check line=5338 msg="in-[infrastructure], out-[]"
id=20085 trace_id=9 func=iprope_dnat_tree_check line=817 msg="len=0"
id=20085 trace_id=9 func=iprope_dnat_check line=5350 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
id=20085 trace_id=9 func=__vf_ip_route_input_rcu line=1993 msg="find a route: flag=00000000 gw-0.0.0.0 via infrastructure"

Which means the traffic is routed back to the incoming interface. In this case, the policy check is being bypassed.

As per the investigation in known issue 858749, 3.2.16 kernel, did policy check for redirect traffic with 'set icmp-send-redirect enable'. That is why the traffic was checked for a firewall policy. This is resolved in 7.0.14, 7.2.6 and 7.4.0. As the 1800F device was using the 4.19.13 kernel, that is why the 'issue' existed.

In other words, due to the known issue 858749 with the 3.2.16 kernel, the intended configuration to block intra-zone traffic worked, while the policy check was skipped as this known issue does not exist on the 4.19.13 kernel. To check the kernel version, see the following article: How-to-check-Kernel-version.

The way to block intra-zone traffic, while allowing specific traffic would be to use the commands below with a global setting (if there is a need to dictate the traffic for the whole FortiGate) or interface setting command (for a specific interface in a zone-only) and create a same zone to zone policy allowing the specific traffic:

config sys global

    set allow-traffic-redirect disable

end

config system interface

    edit "infrastructure"

        set icmp-send-redirect disable

        set icmp-accept-redirect disable

    next

end