FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
HatiUjja
Staff
Staff
Article Id 261055
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: Which comes first? VIP or Local-in policy?

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: What 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:
 
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:
 
 
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: