|
When FortiGate runs in Policy-Based NGFW mode, there are two types of policies defined: Security Policy and Firewall Policy (SSL Inspection & Authentication).
Traffic is being evaluated by the Firewall Policy first, and then by the Security Policy.
The session table looks like this:
session info: proto=6 proto_state=11 duration=12875 expire=3597 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=6 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=5 shaping_policy_id=5 ha_id=0 policy_dir=0 tunnel=/ helper=20 vlan_cos=5/255
state=redir log local may_dirty npd nlb app_valid
statistic(bytes/packets/allow_err): org=61836/997/1 reply=41760/591/1 tuples=2
tx speed(Bps/kbps): 7/0 rx speed(Bps/kbps): 5/0
orgin->sink: org pre->post, reply pre->post dev=29->38/38->29 gwy=10.0.0.1/10.51.12.21
hook=pre dir=org act=noop 10.51.149.60:52107->10.51.29.194:2000(0.0.0.0:0)
hook=post dir=reply act=noop 10.51.29.194:2000->10.51.149.60:52107(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
src_mac=84:b5:17:f1:5b:c2 dst_mac=ee:38:73:06:38:00
misc=0 policy_id=7 pol_uuid_idx=678 auth_info=0 chk_client_info=0 vd=0
serial=00431bfd tos=6e/6e app_list=0 app=23759 url_cat=0
sdwan_mbr_seq=4 sdwan_service_id=1
rpdb_link_id=ff000001 ngfwid=17
npu_state=0x1141008
no_ofld_reason: redir-to-av offload-denied helper non-npu-intf
Where policy_id represents the Firewall Policy (SSL Inspection & Authentication) and ngfwid represents the Security Policy.
When there is a route change, for example, the SD-WAN zone changes, the existing Security Policy should be declared "dirty" and reevaluated according to the new routing. However, this does not happen.
Due to the current limitation, routing changes (including SD-WAN) do not currently trigger Security Policy reevaluation.
The following example/scenario should explain it in more detail:
- Configuration Setup:
config system sdwan
set status enable
config zone
edit "virtual-wan-link"
next
edit "DC_SPOKE4G"
next
end
config members
edit 1
set interface "wan2"
set gateway 10.10.10.1
set cost 10
next
edit 2
set interface "ISP_II"
set zone "DC_SPOKE4G"
set gateway 10.10.20.1
set cost 30
next
end
config service
edit 1
set name "Internet"
set dst "all"
set src "all"
set priority-members 2 1
set priority-zone "DC_SPOKE4G" "virtual-wan-link"
next
end
- Routing Table (Default route via both SD-WAN zones):
config router static
edit 1
set distance 1
set sdwan-zone "virtual-wan-link"
next
edit 2
set distance 1
set sdwan-zone "DC_SPOKE4G"
next
end
- Security Policy and Firewall Policy (SSL Inspection and Authentication):
.
config firewall security-policy <----- Note that only traffic via the 'virtual-wan-link' SD-WAN zone is allowed
edit 1
set uuid 40e29f62-483d-51ef-8ee9-27e70e8203db
set name "Windows_Internet"
set srcintf "Windows"
set dstintf "virtual-wan-link"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
next
end
config firewall policy
edit 1
set name "Default"
set uuid 7a399780-483c-51ef-f506-59ebffb2c82e
set srcintf "any"
set dstintf "any"
set srcaddr "all"
set dstaddr "all"
set srcaddr6 "all"
set dstaddr6 "all"
set service "ALL"
set ssl-ssh-profile "certificate-inspection"
next
end
- Initially, the traffic is flowing through the 'virtual-wan-link' SD-WAN zone matching the Security Policy ID 1 and Firewall Policy ID 1:
FortiGate-61F # diagnose sys sdwan service
Service(1): Address Mode(IPV4) flags=0x200 use-shortcut-sla
Tie break: cfg
Gen(1), TOS(0x0/0x0), Protocol(0: 1->65535), Mode(manual)
Members(2):
1: Seq_num(1 wan2), alive, selected
2: Seq_num(2 ISP_II), alive, selected
Src address(1):
0.0.0.0-255.255.255.255
Dst address(1):
0.0.0.0-255.255.255.255
session info: proto=6 proto_state=11 duration=6079 expire=1120 timeout=3600 flags=00000000 socktype=0 sockport=0 a
v_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0
state=dirty may_dirty ndr npu app_valid
statistic(bytes/packets/allow_err): org=3440/7/1 reply=214/4/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=28->27/27->28 gwy=0.0.0.0/0.0.0.0
hook=pre dir=org act=noop 10.10.100.2:55503->10.10.50.2:22(0.0.0.0:0)
hook=post dir=reply act=noop 10.10.50.2:22->10.10.100.2:55503(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
src_mac=00:64:65:6c:28:01
misc=0 policy_id=1 pol_uuid_idx=558 auth_info=0 chk_client_info=0 vd=0
serial=00311178 tos=ff/ff app_list=0 app=16060 url_cat=0
sdwan_mbr_seq=2 sdwan_service_id=1
rpdb_link_id=ff000001 ngfwid=1
npu_state=0x003c94 ips_offload ofld-O ofld-R
npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000
vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0
no_ofld_reason:
total session 1
- When the routing changes, a new SD-WAN zone is preferred. Since no Security Policy rule allows traffic over the 'secondary"'SD-WAN zone, the session table should be reevaluated and traffic denied by the implicit deny policy. However, due to the current limitation explained above, this does not happen:
FortiGate-61F # diagnose sys sdwan service
Service(1): Address Mode(IPV4) flags=0x200 use-shortcut-sla
Tie break: cfg
Gen(1), TOS(0x0/0x0), Protocol(0: 1->65535), Mode(manual)
Members(2):
1: Seq_num(2 ISP_II), alive, selected
2: Seq_num(1 wan2), alive, selected
Src address(1):
0.0.0.0-255.255.255.255
Dst address(1):
0.0.0.0-255.255.255.255
- Security Policy remains the same and traffic is allowed:
session info: proto=6 proto_state=11 duration=61 expire=3538 timeout=3600 flags=00000000 socktype=0 sockport=0 av_
idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0
state=dirty may_dirty ndr npu app_valid
statistic(bytes/packets/allow_err): org=92/2/1 reply=52/1/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=28->6/6->28 gwy=0.0.0.0/0.0.0.0
hook=pre dir=org act=noop 10.10.100.2:55557->10.10.50.2:22(0.0.0.0:0)
hook=post dir=reply act=noop 10.10.50.2:22->10.10.100.2:55557(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
src_mac=00:64:65:6c:28:01
misc=0 policy_id=1 pol_uuid_idx=558 auth_info=0 chk_client_info=0 vd=0
serial=00315196 tos=ff/ff app_list=0 app=16060 url_cat=0
sdwan_mbr_seq=1 sdwan_service_id=1
rpdb_link_id=ff000001 ngfwid=1
npu_state=0x003c94 ips_offload ofld-O ofld-R
npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000
vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0
no_ofld_reason:
total session 1
All new traffic, not belonging to the existing session will be denied.
Workaround:
Clearing the existing Session table entries for specific traffic would also make FortiGate deny any subsequent packets.
Technical Tip: Using filters to clear sessions on a FortiGate
If such a scenario/design, as described above exists, the recommendation is to use FortiGate in Profile-Based NGFW mode (default one) and avoid using Policy-Based NGFW mode.
|
