| Description |
This article describes how the ICMP redirect works in FortiGate and the behavior when it is disabled. |
| Scope |
FortiGate |
| Solution |
Topology:
In this topology, there are two FortiGates. FGT-1 is the Internet Gateway for the subnet 10.30.0.0/20 and FGT-2 is the router to the subnet 10.11.0.0/20 (in the real environment it could be a router in a different brand other than FortiGate).
On the Internet Gateway FortiGate, there is a static route for the subnet 10.11.0.0/20 pointing to port 5 IP address on FGT-2 as below:
S 10.11.0.0/20 [10/0] via 10.30.0.221, port2, [1/0]
Since the endpoint PC has having FGT-1 port 2 IP address as the default gateway. All traffic will be going to port 2 by default including the traffic to the Server 10.11.1.15.
ICMP redirect is enabled by default on the FortiGate interface. With the default configuration, when PC 10.30.1.2 is trying to ping the server 10.11.1.15, the first ICMP echo request hits port 2 on FGT-1 and is forwarded via the same interface to FGT-2. After that, Port 2 sends an ICMP redirect message (ICMP type-#5) back to the PC.
c3po-kvm80 (root) # diagnose sniffer packet any 'host 10.30.1.2 and icmp' 4 0 Using Original Sniffing Mode interfaces=[any] filters=[host 10.30.1.2 and icmp] 11.888385 port2 in 10.30.1.2 -> 10.11.1.15: icmp: echo request 11.888469 port2 out 10.30.1.12 -> 10.30.1.2: icmp: type-#5 11.889242 port2 out 10.30.1.2 -> 10.11.1.15: icmp: echo request
The traffic direction is as below:
By taking a deep look at the ICMP redirect message (ICMP: type-#5) in Wireshark, the new gateway IP address 10.30.0.221 can be found.
This is to inform the PC 10.30.1.2 to send the ICMP request to port 5 on FGT-2 straightaway instead of FGT-1. FGT-1 will not receive any more ICMP requests from PC. The traffic flow will be like the following:
The ICMP redirect applies not only to ICMP traffic but also the TCP. Below is the ICMP redirect sent by FGT-1 to PC after getting the first SYN packet from PC when PC is trying to connect to the Server via RDP.
When ICMP redirect is enabled, no firewall policy is required on the FGT-1 when the incoming and outgoing interfaces are same. In the below debug flow, the policy matching will not be visible.
c3po-kvm80 (root) # id=20085 trace_id=41 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=6, 10.30.1.2:25281->10.11.1.15:3389) tun_id=0.0.0.0 from port2. flag [S], seq 1392901862, ack 0, win 64240" id=20085 trace_id=41 func=init_ip_session_common line=6046 msg="allocate a new session-000722ab, tun_id=0.0.0.0" id=20085 trace_id=41 func=vf_ip_route_input_common line=2611 msg="find a route: flag=05000000 gw-10.30.0.221 via port2"
On FortiGate, the ICMP redirect can either be controlled at the system global level or at the interface level, which is all enabled by default.
Interface Level:
config system interface edit "port2" set icmp-send-redirect enable set icmp-accept-redirect enable next end
Global Level:
config sys global set allow-traffic-redirect enable end
When having these options disabled on FGT-1 port 2, FortiGate will stop sending and accepting any ICMP redirect message. FGT-1 will keep receiving ICMP requests from PC and forwarding them to FGT-2. No ICMP reply will be received since FGT-2 will forward it back to PC directly. Firewall policy will be required for the traffic with the same incoming and outgoing interface.
c3po-kvm80 (root) # id=20085 trace_id=51 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=1, 10.30.1.2:1->10.11.1.15:2048) tun_id=0.0.0.0 from port2. type=8, code=0, id=1, seq=564." id=20085 trace_id=51 func=init_ip_session_common line=6046 msg="allocate a new session-000732eb, tun_id=0.0.0.0" id=20085 trace_id=51 func=vf_ip_route_input_common line=2611 msg="find a route: flag=04000000 gw-10.30.0.221 via port2" id=20085 trace_id=51 func=fw_forward_handler line=881 msg="Allowed by Policy-16:"
c3po-kvm80 (root) # diagnose sniffer packet any 'host 10.30.1.2 and icmp' 4 0 Using Original Sniffing Mode interfaces=[any] filters=[host 10.30.1.2 and icmp] 4.753352 port2 in 10.30.1.2 -> 10.11.1.15: icmp: echo request 4.754127 port2 out 10.30.1.2 -> 10.11.1.15: icmp: echo request 5.767577 port2 in 10.30.1.2 -> 10.11.1.15: icmp: echo request 5.767619 port2 out 10.30.1.2 -> 10.11.1.15: icmp: echo request 6.783534 port2 in 10.30.1.2 -> 10.11.1.15: icmp: echo request 6.783599 port2 out 10.30.1.2 -> 10.11.1.15: icmp: echo request 7.798736 port2 in 10.30.1.2 -> 10.11.1.15: icmp: echo request 7.798771 port2 out 10.30.1.2 -> 10.11.1.15: icmp: echo request
For TCP traffic, there could be an issue if the ICMP redirect is disabled. This is because the SYNC and ACK packet from PC is going via the FGT-1+FGT-2 but the responded SYNC ACK will only go via FGT-2. Thus, the ACK packet will be dropped by FGT-1 due to ‘anti-replay check failure’ so the TCP handshake between PC and server won’t be successful.
id=20085 trace_id=12 func=resolve_ip_tuple_fast line=5953 msg="Find an existing session, id-00070cc7, original direction" id=20085 trace_id=12 func=tcp_anti_reply line=1054 msg="org dir, ack in state syn_sent, suspicious" id=20085 trace_id=12 func=ip_session_core_in line=6612 msg="anti-replay check fails, drop"
The anti-replay check can be disabled at the policy level or global level according to the below instructions to make this TCP handshake work: Technical Note: How anti-replay works and sniffer usage for testing
Related articles: Technical Tip: Traffic handled by FortiGate for packet which ingress and egress same interface |
