Description
This article describes the ARP reply setting in Virtual IP/IP Pool.
FortiGate.
Solution
The 'set arp-reply disable' is used in the case when IP addresses are overlapping with another device in the network. With arp-reply disabled, FortiGate should send an ARP request for the addresses defined in the VIP/IP pool if it needs to send traffic to units that own these IP addresses.
The 'set arp-reply enable'(default) command means that FortiGate will answer ARP requests for the IP address(es) mentioned in the VIP/IP pool.
Note:
Before FortiOS 6.4.9 / 7.0.1 all IP addresses in the IP pool and VIP are considered as local IP if arp-reply is enabled (following the FortiOS logic one IP can be bound to one interface). In v6.4.9-6.4.15/ v7.0.1-v7.0.12 /v7.2.0-v7.2.5/v7.4.0, the IP pool / VIP IP addresses are no longer considered local.
This change was reverted in v6.4.16, v7.0.13, v7.2.6 and v7.4.1. From these versions onwards, IP pools and VIPs will again be considered as local IP addresses.
The below debug output shows the behavior when 'set arp-reply' is enabled. FortiGate responds to the ARP requests for the IP configured in the VIP. Hence, traffic is processed locally. When 'set arp-reply' is disabled, FortiGate resolves the correct MAC address of the next hop.
id=65308 trace_id=5 func=print_pkt_detail line=5942 msg="vd-root:0 received a packet(proto=6, 10.10.10.1:64430->187.10.10.11:8080) tun_id=0.0.0.0 from port3. flag [S], seq 2143958925, ack 0, win 65535"
id=65308 trace_id=5 func=init_ip_session_common line=6127 msg="allocate a new session-25f73da6"
id=65308 trace_id=5 func=iprope_dnat_check line=5480 msg="in-[port3], out-[]"
id=65308 trace_id=5 func=iprope_dnat_tree_check line=824 msg="len=1"
id=65308 trace_id=5 func=__iprope_check_one_dnat_policy line=5345 msg="checking gnum-100000 policy-1"
id=65308 trace_id=5 func=get_new_addr line=1274 msg="find DNAT: IP-187.10.10.11, port-80"
id=65308 trace_id=5 func=__iprope_check_one_dnat_policy line=5435 msg="matched policy-1, act=accept, vip=1, flag=100, sflag=2
000000"
id=65308 trace_id=5 func=iprope_dnat_check line=5505 msg="result: skb_flags-02000000, vid-1, ret-matched, act-accept, flag-00
000100"
id=65308 trace_id=5 func=fw_pre_route_handler line=191 msg="VIP-187.10.10.11:80, outdev-port3"
id=65308 trace_id=5 func=__ip_session_run_tuple line=3487 msg="DNAT 187.10.10.11:8080->187.10.10.11:80" <----- Port translation is working.
id=65308 trace_id=5 func=__vf_ip_route_input_rcu line=1988 msg="find a route: flag=80000000 gw-0.0.0.0 via root" --> FortiGate is processing the traffic locally instead of sending to next hop
id=65308 trace_id=5 func=iprope_access_proxy_check line=458 msg="in-[port3], out-[], skb_flags-020000c0, vid-1"
id=65308 trace_id=5 func=__iprope_check line=2404 msg="gnum-100017, check-ffffffffa002c420"
id=65308 trace_id=5 func=iprope_policy_group_check line=4902 msg="after check: ret-no-match, act-accept, flag-00000000, flag2
-00000000"
id=65308 trace_id=5 func=iprope_in_check line=496 msg="in-[port3], out-[], skb_flags-020000c0, vid-1"
id=65308 trace_id=5 func=__iprope_check line=2404 msg="gnum-100011, check-ffffffffa002ce50"
id=65308 trace_id=5 func=iprope_policy_group_check line=4902 msg="after check: ret-no-match, act-drop, flag-00000000, flag2-0
0000000"
Related documents:
Technical Tip: IP pool and virtual IP behavior changes in FortiOS 6.4, 7.0, 7.2, and 7.4
