Description
This article describes how a local-in policy affects traffic matching a Virtual IP (VIP) configuration on the FortiGate firewall.
Scope
A FortiGate Firewall configured with local-in policies and a Virtual IP (VIP).
Solution
Order of processing: Deciding whether VIP or Local-in policy comes first.
Destination NAT (VIP) takes place before traffic is evaluated by local-in policies, as explained here.
If at least one firewall policy that references the VIP is configured and enabled; then DNAT will take place for the traffic that matches the VIP configuration and firewall policies will decide the outcome of such traffic, not local in policies. Let us evaluate this statement in the following scenarios:
Scenario 1: VIP without port-forwarding i.e. 1:1 DNAT is configured.
If at least one firewall policy is configured referencing the VIP (and the firewall policy is in enabled status), then the traffic will undergo DNAT first and the outcome of the traffic will be based on firewall policies. Local-in policies will not be evaluated.
Note: If the firewall policy is configured for just one service/port:
As long as at least one Firewall policy exists, for one or more services/ports and the policy is in enabled status, traffic for the VIP external IP for all services/ports will be evaluated by Firewall policies, and not by local-in policies (as tested on FortiOS 7.4.4).
Scenario 2: VIP with Port forwarding enabled.
For traffic matching the VIP external IP and VIP external port i.e. for traffic matching the VIP configuration:
If at least one firewall policy is configured referencing the VIP and the firewall policy is in enabled status, (even if the service on the firewall policy does not match the VIP external port), firewall policies will determine the outcome of the traffic matching the VIP configuration, not local-in policies (as tested on FortiOS 7.4.4).
Traffic for ports other than the port(s) forwarded (external port(s)) will be processed by the local-in policies (assuming no other VIPs exist, that could match other ports, such as the example discussed later in this document).
Scenario 3: VIP configured but not referenced in a firewall policy.
Depending on the FortiGate firmware version, and as per the behaviour described here, if firewall considers the configured VIP external IP address as a local IP address, but the VIP is not referenced on any enabled policy, then the traffic will be processed by local-in policies.
Supplementary Scenarios: The use of 'Optional Filters' on VIP:
If Optional Filters are configured on the VIP, the same logic still stands, i.e. if the VIP is referenced in a firewall policy that is in enabled status, if the traffic matches the VIP configuration (either source address or service(s) or both), then firewall policies will decide the outcome of the traffic, not local-in policies.
Note: Service(s) specified imply the VIP external port to be matched by the traffic ingressing the FortiGate.
Example:
Sample configuration to allow only HTTPS traffic to a VIP-mapped IP and block all other services on Interface port3 via local-in-policy:
config system interface
edit "port3"
set vdom "root"
set ip 10.245.15.139 255.255.240.0
set allowaccess ping https ssh http telnet
set type physical
set snmp-index 3
next
end
config firewall local-in-policy
edit <1>
set intf port3
set srcaddr all
set dstaddr all
set action deny
set service ALL
set schedule always
end
config firewall vip
edit "https-VIP"
set extip 10.245.15.139
set mappedip "10.5.50.90"
set extintf "port3"
set portforward enable
set extport 443
set mappedport 443
next
end
config firewall policy
edit 5
set name "VIP-policy"
set srcintf "port3"
set dstintf "port2"
set action accept
set srcaddr "all"
set dstaddr "https-VIP"
set schedule "always"
set service "ALL"
set nat enable
next
Explanation:
With the above VIP and security policy and local-in-policy configuration, the HTTPS traffic to port3 interface on port 443 will be allowed through the security policy and all the other remaining services will be blocked by the firewall local-in-policy.
Flow Debug for Ping blocked via local in deny policy:
diagnose debug reset
diagnose debug flow filter saddr 10.245.10.81
diagnose debug flow filter daddr 10.245.15.139
diagnose debug flow filter proto 1
diagnose debug flow trace start 1000
diagnose debug enable
To stop filter:
diagnose debug reset
diagnose debug disable
FGT-02 # id=20085 trace_id=9 func=print_pkt_detail line=5844 msg="vd-root:0 received a packet(proto=1, 10.245.10.81:1->10.245.15.139:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=1, seq=10."
id=20085 trace_id=9 func=init_ip_session_common line=6023 msg="allocate a new session-0036c21a, tun_id=0.0.0.0"
id=20085 trace_id=9 func=vf_ip_route_input_common line=2605 msg="find a route: flag=84000000 gw-10.245.15.139 via root"
id=20085 trace_id=9 func=fw_local_in_handler line=500 msg="iprope_in_check() check failed on policy 1, drop"
Flow Debug for Https allowed through VIP and security rule:
diagnose debug reset
diagnose debug flow filter saddr 10.245.10.81
diagnose debug flow filter daddr 10.245.15.139
diagnose debug flow filter port 443
diagnose debug flow trace start 1000
diagnose debug enable
To stop the filter:
diagnose debug reset
diagnose debug disable
FGT-02 # id=20085 trace_id=33 func=print_pkt_detail line=5844 msg="vd-root:0 received a packet(proto=6, 10.245.10.81:50523->10.245.15.139:443) tun_id=0.0.0.0 from port3. flag [S], seq 1746916338, ack 0, win 64240"
id=20085 trace_id=33 func=init_ip_session_common line=6023 msg="allocate a new session-0036caf8, tun_id=0.0.0.0"
id=20085 trace_id=33 func=get_new_addr line=1221 msg="find DNAT: IP-10.5.50.90, port-443"
id=20085 trace_id=33 func=fw_pre_route_handler line=178 msg="VIP-10.5.50.90:443, outdev-port3"
id=20085 trace_id=33 func=__ip_session_run_tuple line=3483 msg="DNAT 10.245.15.139:443->10.5.50.90:443"
id=20085 trace_id=33 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-10.5.50.90 via port2"
id=20085 trace_id=33 func=get_new_addr line=1221 msg="find SNAT: IP-10.5.63.139(from IPPOOL), port-50523"
id=20085 trace_id=33 func=fw_forward_handler line=881 msg="Allowed by Policy-5: SNAT"
id=20085 trace_id=33 func=__ip_session_run_tuple line=3470 msg="SNAT 10.245.10.81->10.5.63.139:50523"
Session output for Https traffic through VIP:
session info: proto=6 proto_state=01 duration=3 expire=3597 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=0 use=5
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=may_dirty
statistic(bytes/packets/allow_err): org=5978/75/1 reply=560275/412/1 tuples=4
tx speed(Bps/kbps): 1763/14 rx speed(Bps/kbps): 165272/1322
orgin->sink: org pre->post, reply pre->post dev=9->6/6->9 gwy=10.5.50.90/10.245.10.81
hook=pre dir=org act=dnat 10.245.10.81:50553->10.245.15.139:443(10.5.50.90:443)
hook=post dir=org act=snat 10.245.10.81:50553->10.5.50.90:443(10.5.63.139:50553)
hook=pre dir=reply act=dnat 10.5.50.90:443->10.5.63.139:50553(10.245.10.81:50553)
hook=post dir=reply act=snat 10.5.50.90:443->10.245.10.81:50553(10.245.15.139:443)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=5 pol_uuid_idx=14768 auth_info=0 chk_client_info=0 vd=0
serial=0036db91 tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id=00000000 ngfwid=n/a
npu_state=0x000100
no_ofld_reason: npu-flag-off
total session 1
Related documents:
