Technical Tip: iprope policies group

Description

This article describes commands to check the iprope table, which is an internal representation of the firewall policies defined by the administrators.

Scope

FortiGate.

Solution

The iprope serves as an internal lookup table that orchestrates how packets navigate various processing switches. Acting as a functional translation of the administrator's firewall policies, it determines whether a packet is forwarded to an external destination, redirected to internal FortiGate services, or discarded entirely.

All entries are organized in groups of different functions. Entries in the group are inspected from top to bottom- when an entry from a group is matched, the listing's action is applied, and no more entries from the group are checked. Each entry has different matching criteria based on source/destination IP addresses, ports, and protocol.

Example:

diagnose firewall iprope list 100002 <-----This will list static SNAT policies.

diagnose firewall iprope list 100000 <----- This will list VIP firewall policies.

diagnose firewall iprope list 100004 <----- This will list normal firewall policy, forward policies.

diagnose firewall iprope list 10000e <----- This will list all implicit policies as listed in the GUI. 

diagnose firewall iprope list 100015 <----- This will list all Traffic Shaping policies as listed in the GUI.

diagnose firewall iprope list 100017 <----- This will list all simple ZTNA policies as listed in the GUI.

One example is:

Policy Group 00100004     -----------------------------> Forward policy.

policy index=1 uuid_idx=14 action=accept

flag (8050108): redir nat master use_src pol_stats

flag2 (4000): resolve_sso

flag3 (20): schedule(always)

cos_fwd=255 cos_rev=255

group=00100004 av=00004e20 au=00000000 split=00000000

host=0 chk_client_info=0x0 app_list=0 ips_view=0

misc=0 dd_type=0 dd_mode=0

zone(1): 3 -> zone(1): 6

source(1): 10.0.1.0-10.0.1.255, uuid_idx=12,

dest(1): 192.0.2.0-192.0.2.255, uuid_idx=13,

service(1):

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

FGT # diagnose firewall iprope list 100000  ------------------------------------> VIP policy.

policy index=1901 uuid_idx=1901 action=accept
flag (8000104): f_p nat pol_stats
schedule()
cos_fwd=0 cos_rev=0
group=00100000 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=0
misc=0
zone(1): 0 -> zone(1): 0
source(1): 0.0.0.0-255.255.255.255, uuid_idx=0,
dest(1): 5.5.5.5-5.5.5.5, uuid_idx=1901,
service(1):
[0:0x0:0/(0,0)->(0,0)] flags:0 helper:auto
nat(1): flag=0 base=5.5.5.5:0 10.10.10.10-10.10.10.10(0:0)

For each entry, in case of a match, there is an action:

• Drop the packet (action=drop).
• Redirect the packet to some processing logic (action=redirect).
• Accept the packet (action=accept).

There are no ‘implicit’ iprope entries, unlike the implicit deny firewall policy.

Both entries and groups have identifiers: the group has a group number, and all entries are called policies and have an index.

The following table shows iprope groups sorted by group number.

Default entries may be provided if the group exists with default values, with a factory reset configuration. 

Not every packet undergoes a full iprope table lookup. When a packet arrives, the kernel generates a hash based on its 5-tuple (source/destination IP, source/destination port, and protocol) and checks it against the existing session table. If a match is found, the FortiGate leverages the instructions already stored from the initial packet, bypassing the iprope table entirely to accelerate processing.

Related document:

Local-in and local-out traffic matching