|
An administrator might configure a virtual IP address or virtual server with the same external IP previously configured as the mappedip of another virtual IP. This is unusual but valid configuration.
config firewall vip
edit vip-A
set extip 10.0.10.111
set extintf any
set mappedip 10.255.108.2
edit vip-B
set extip 10.255.108.2
set extintf any
set mappedip 172.17.10.254
next
end
config firewall policy
edit <index>
set name "VIP-A policy"
set srcintf "mgmt"
set dstintf "port16"
set action accept
set srcaddr "all"
set dstaddr "vip-A"
set schedule "always"
set service "ALL_ICMP"
next
end
An IP pool is also created for other purposes, and has an external IP on the same subnet as the mapped IP of vip-A:
config firewall ippool
edit ippool-B
set startip 10.255.108.2
set endip 10.255.108.2
next
end
With this configuration, if an administrator attempts to ping from an endpoint in subnet 10.0.10.0/24 to the Virtual IP 10.0.10.111 (real server 10.255.108.2), the FortiGate will apply the intended NAT from vip-A, then detect the destination 10.255.108.2 as local traffic and drop the session because of the configuration of vip-B and ippool-B.
This issue can be resolved with the following steps:
- Disable arp-reply on the IP pool:
config firewall ippool
edit ippool-B
set arp-reply disable
next
end
- Disable arp-reply on vip2:
config firewall vip
edit vip-B
set arp-reply disable
next
end
While arp-reply is enabled, the local traffic verdict can be diagnosed from a flow trace.
FG3H0E-1 # diagnose debug flow filter addr 10.0.10.111
FG3H0E-1 # diagnose debug flow show iprope enable
show trace messages about iprope
FG3H0E-1 # diagnose debug flow show function-name enable
show function name
FG3H0E-1 # diagnose debug enable
FG3H0E-1 # diagnose debug flow trace start 1
FG3H0E-1 # id=65308 trace_id=1 func=print_pkt_detail line=6007 msg="vd-root:0 received a packet(proto=1, 10.0.10.254:5134->10.0.10.111:2048) tun_id=0.0.0.0 from mgmt. type=8, code=0, id=5134, seq=57778."
id=65308 trace_id=1 func=init_ip_session_common line=6206 msg="allocate a new session-000c974f"
id=65308 trace_id=1 func=iprope_dnat_check line=5535 msg="in-[mgmt], out-[]"
id=65308 trace_id=1 func=iprope_dnat_tree_check line=836 msg="len=1"
id=65308 trace_id=1 func=__iprope_check_one_dnat_policy line=5398 msg="checking gnum-100000 policy-1129"
id=65308 trace_id=1 func=get_new_addr line=1295 msg="find DNAT: IP-10.255.108.2, port-0(fixed port)"
id=65308 trace_id=1 func=__iprope_check_one_dnat_policy line=5490 msg="matched policy-1129, act=accept, vip=1129, flag=104, sflag=2000000" << intended Virtual IP is matched and functioning as intended.
id=65308 trace_id=1 func=iprope_dnat_check line=5560 msg="result: skb_flags-02000000, vid-1129, ret-matched, act-accept, flag-00000104"
id=65308 trace_id=1 func=fw_pre_route_handler line=188 msg="VIP-10.255.108.2:5134, outdev-unknown"
id=65308 trace_id=1 func=__ip_session_run_tuple line=3545 msg="DNAT 10.0.10.111:8->10.255.108.2:5134"
id=65308 trace_id=1 func=vf_ip_route_input_common line=2615 msg="find a route: flag=80000000 gw-10.255.108.2 via root" << 'gw-10.255.108.2 via root' indicates the traffic is considered local and firewall policies will not be checked.
<The firewall continues to check other iprope policy groups to check how it should handle the local traffic. Additional iprope check output omitted.>
id=65308 trace_id=1 func=fw_local_in_handler line=616 msg="iprope_in_check() check failed on policy 0, drop" << final verdict for the packet is drop.
Even though vip-A was configured as intended and has a valid firewall policy, the firewall policy was not matched because the mapped IP address 10.255.108.2 is considered a local address (because arp-reply is enabled on vip-B and ippool-B).
Disabling the arp-reply in ippool-B only will not resolve the problem, as vip-B will induce the same behavior. It is necessary to disable arp-reply for both objects.
In FortiOS v7.0.14 and v7.2.6 or later, both IP pools and VIPs are detected as local address objects if arp-reply is enabled. Arp-reply is by default enabled on the VIPs and IP pools. For more detail of FortiOS behavior with IP pools and VIPs on different firmware versions, consult Technical Tip: IP pool and virtual IP behavior changes in FortiOS 6.4, 7.0, 7.2, and 7.4.
Related article:
Technical Tip: IP pool and virtual IP behavior changes in FortiOS 6.4, 7.0, 7.2, and 7.4
Technical Tip: iprope policies group
|
