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.
alif
Staff
Staff
Article Id 391935
Description

This article describes the functionality of interface-policy on FortiGate.

Scope FortiGate.
Solution

Consider an interface-policy configured on FortiGate as follows:

 

config firewall interface-policy
    edit 1
        set uuid b7c08d6c-1491-51f0-a0a2-0ec15c9290c1
        set interface "VLAN10"
        set srcaddr "all"
        set dstaddr "VLAN20_Subnet"
        set service "ALL"
        set ips-sensor-status enable
        set ips-sensor "all_default"
    next
end

config firewall address
    edit "VLAN20_Subnet"
        set uuid a7f651ae-1965-51f0-4b93-77bf316a7619
        set subnet 10.20.0.0 255.255.255.0
    next
end

 

As per the IPS log entries, traffic is showing 'srcip="10.20.0.70" and dstip="192.168.10.10"' which contradicts the destination address object "VLAN20_Subnet" defined in interface-policy ID 1:

 

date="2025-05-10" time="14:20:34" type="utm" subtype="ips" level="alert" action="detected" sessionid=1560004123 srcip="10.20.0.70" dstip="192.168.10.10" srcport=48026 dstport=22 attackid=51006 severity="critical" proto=6 logid="0419016384" service="SSH" policyid=1 incidentserialno=35747872 crscore=50 craction=4096 crlevel="critical" direction="outgoing" profile=" all_default " srcintf="VLAN30" dstintf="VLAN10" ref="http://www.fortinet.com/ids/VID51006" attack="Apache.Log4j.Error.Log.Remote.Code.Execution" eventtype="signature" srccountry="Reserved" msg="apache: Apache.Log4j.Error.Log.Remote.Code.Execution" tz="+0100" dstcountry="Reserved" poluuid="b7c08d6c-1491-51f0-a0a2-0ec15c9290c1" devid="FGxxxxxxxxx" vd="root" devname="FGT_VM" cve=CVE-2021-4104,CVE-2021-44228,CVE-2021-45046

 

The traffic matching interface-policy applies to both directions (incoming and outgoing). In the IPS log entry shown above, the traffic is hitting the interface-policy in the reply direction.

 

diagnose firewall iprope list | grep -B 4 -A 9 group=0005000
policy index=1 uuid_idx=0 action=accept
flag (2000): nids_raw
schedule()
cos_fwd=0 cos_rev=0
group=00050009 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=1
misc=0
zone(1): 9 -> zone(1): 9
source(1): 0.0.0.0-255.255.255.255, uuid_idx=555,
dest(1): 10.20.0.0-10.20.0.255, uuid_idx=663,
service(1):

        [0:0x0:0/(0,65535)->(0,65535)] flags:0 helper:auto

 

policy index=1 uuid_idx=0 action=accept
policy index=1 uuid_idx=0 action=accept
flag (2000): nids_raw
schedule()
cos_fwd=0 cos_rev=0
group=00050009 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=1
misc=0
zone(1): 9 -> zone(1): 9
source(1): 10.20.0.0-10.20.0.255, uuid_idx=663,
dest(1): 0.0.0.0-255.255.255.255, uuid_idx=555,
service(1):

        [0:0x0:0/(0,65535)->(0,65535)] flags:0 helper:auto

 

The interface-policy does not work as a normal firewall policy. In a normal firewall policy, traffic is matched based on the source/destination address, and a session gets created. If the traffic is initiated from the destination address, the traffic does not match the intended firewall policy.

 

In the case of interface-policy, traffic is matched in both directions (incoming and outgoing). When traffic is initiated from 10.20.0.0/24 subnet ('VLAN20_Subnet'), the interface policy gets matched. The usage of srcaddr and dstaddr in interface-policy is not as per se or used like a firewall policy.

 

Related document:

Interface policies

 

Contributors