Description
This article describes how to check policy matching for Policy-based operation mode.
Scope
FortiGate.
Solution
In Policy-based mode, the firewall policy will be split into 2 sections.
|
Native policy
|
Application control policy
|
FOS version
|
|
SSL Inspection & Authentication.
CLI : config firewall policy
|
Security Policy.
CLI : config firewall security-policy.
|
7.0 & 6.4.
|
|
SSL Inspection & Authentication.
CLI : config firewall consolidated policy.
|
Security Policy.
CLI : config firewall security-policy.
|
6.2.3 above.
|
|
Firewall Policy
CLI : config firewall consolidated policy.
|
Security Policy.
CLI : config firewall security-policy.
|
6.2.3 below.
|
As the policy is split into 2 sections, when performing troubleshooting to check which policy traffic is hitting on which policy by using debug flow (refer to FD30038 for detailed command), it will only be able to show it hitting the policy defined in the native policy. To debug the Security Policy, which is handled by IPS, it is necessary to use the below debug.
To start debugging:
Obtain the information about Application Definitions and security-policies:
diagnose ips pme policy def_port
diagnose autoupdate versions | grep -A2 "Application Definitions"
Enable the following debug and collect the debug logs when the issue happens for Telnet and Postgres:
diagnose ips debug enable packet_detail
diagnose ips debug enable log
diagnose ips pme debug enable
diagnose ips pme detail all
diagnose debug console time enable
diagnose debug enable
To stop debugging:
diagnose debug disable
diagnose ips pmw debug disble
diagnose debug reset
CLI output of IPS pme debug shows a matching policy with source and destination IP addresses.
PME[197/0] matching policy "Internet"
PME[197/0] ...matching apps
PME[197/0] ...explicit match
PME[197/0] ...matching actions
PME[197/0] [EXPLICIT PASS] Internet : url=-1
PME[197/0] ...trigger policy 1 Internet
PME[197/0] [DECISION MADE] PASS view=3 policy=1 features={p:0x4 s:0}
PME[197/0] policy=1 action=0 log_traffic=0 isdb_src/dst=0/0
PME[198/0] auth query not needed
PME[198/0] current {
PME[198/0] SRC intf= 5 tuple=192.168.1.2:56101 ----> Source IP.
PME[198/0] DST intf= 3 tuple=x.x.x.x:443 ----> Destination IP.
PME[198/0] vdom=0 vrf=0 proto=6 time=137738 serial=00098f7e
PME[198/0] user=0 groups-count=0 groups=[]
PME[198/0] }
PME[198/0] static {
PME[198/0] policy: id=1 "Internet" intf={src_ids: { 5 }, dst_ids: { 3 }} flags=180
PME[198/0] }
PME[198/0] policy 1: static match passed
PME[198/0] session was created
Note.
BPF filter for the PME debugs for specific traffic:
diagnose ips filter set "host 10.10.1.1 and port 443"
It is also advised to run these debugs with extra caution, preferably during low traffic
Also, it is recommended to run sniffers on the incoming interface and outgoing interface traffic:
SSH1:
diagnose sniffer packet "source_interface" "protocol and port_number" 6 0 l
SSH2:
diagnose sniffer packet "destination_interface" "protocol and port_number" 6 0 l
For example, for TCP port 22 (SSH application), where the incoming interface for traffic is port1 and the outgoing interface is port2:
diagnose sniffer packet "port1" "tcp and port 22" 6 0 l
diagnose sniffer packet "port2" "tcp and port 22" 6 0 l
Above debugging only requires deeper investigation as to why it is not hitting the correct policy; using the session list can provide a quick view on which policy it is hitting.
The example below shows SSH traffic coming from host 10.101.0.2 to destination 10.56.255.7, as visible highlighted in RED color, indicating a matching policy for firewall policy 2 (policy_id) and security policy 2 (ngfwid).
diagnose sys session filter dst 10.56.255.7
diagnose sys session filter src 10.101.0.2
diagnose sys session list
session info: proto=6 proto_state=11 duration=3 expire=29 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=may_dirty nb ndr npu
statistic(bytes/packets/allow_err): org=160/3/1 reply=131/2/1 tuples=3
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=9->16/16->9 gwy=10.56.243.254/10.101.0.2
hook=post dir=org act=snat 10.101.0.2:50338->10.56.255.7:22(10.56.242.52:50338)
hook=pre dir=reply act=dnat 10.56.255.7:22->10.56.242.52:50338(10.101.0.2:50338)
hook=post dir=reply act=noop 10.56.255.7:22->10.101.0.2:50338(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=2 auth_info=0 chk_client_info=0 vd=0
serial=00001540 tos=ff/ff app_list=0 app=0 url_cat=0
sdwan_mbr_seq=0 sdwan_service_id=0
rpdb_link_id=00000000 rpdb_svc_id=0 ngfwid=2
npu_state=0x003c08
npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=75/75, ipid=132/146, vlan=0x0000/0x0000
vlifid=132/146, vtag_in=0x0000/0x0000 in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=10/11
no_ofld_reason: block-by-ips redir-to-ips
The above session indicates traffic has been dropped by IPS, as indicated in the last line.
