Description
This article describes how to configure the FortiGate to avoid routing issues after a route change when SNAT session preservation is used.
Solution
There are situations when, multiple links are needed to reach different resources.
For example, a link used for all Internet traffic and another one for voice traffic.
In most common cases a firewall policy with NAT enabled is used to allow traffic from the local LAN towards the Internet.
By default, when SNAT is used, FortiGate preserves the existing session when a routing change occurs.
This might cause some traffic not to be routed as expected.
This article describes how to configure the FortiGate to avoid routing issues after a route change when SNAT session preservation is used.
Solution
There are situations when, multiple links are needed to reach different resources.
For example, a link used for all Internet traffic and another one for voice traffic.
In most common cases a firewall policy with NAT enabled is used to allow traffic from the local LAN towards the Internet.
By default, when SNAT is used, FortiGate preserves the existing session when a routing change occurs.
This might cause some traffic not to be routed as expected.
In this example, the Phone has the IP 10.122.3.153, and must reach the PBX at 192.0.2.1.
There is an IPSEC tunnel between the FortiGates and a BGP session over that tunnel.
There is an IPSEC tunnel between the FortiGates and a BGP session over that tunnel.
The Fortigate 51E advertises, via BGP, the prefix 192.0.2.1/30.
A new session is created and, according to the configured firewall policy, SNAT is applied.
FG180F-3 # get router info routing-table details 192.0.2.1When the PBX IP addressis pinged, the session below appears:
Routing table for VRF=0
Routing entry for 192.0.2.0/30
Known via "bgp", distance 200, metric 0, best
Last update 00:14:35 ago
* 172.16.0.2, via SITE_TO_SITE
session info: proto=1 proto_state=00 duration=58 expire=2 timeout=0 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3If, for any reason, the PBX subnet is not learnt anymore via BGP, the FortiGate will use the configured static default route to forward the traffic towards 192.0.2.1.
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=SITE_TO_SITE/ vlan_cos=0/255
state=may_dirty npu
statistic(bytes/packets/allow_err): org=120/2/1 reply=120/2/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=8->55/55->8 gwy=172.16.0.2/10.122.3.153
hook=pre dir=org act=noop 10.122.3.153:1->192.0.2.1:8(0.0.0.0:0)
hook=post dir=reply act=noop 192.0.2.1:1->10.122.3.153:0(0.0.0.0:0)
misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=0
serial=0001d0f2 tos=ff/ff app_list=0 app=0 url_cat=0
vwl_mbr_seq=0 vwl_service_id=0
rpdb_link_id=00000000 ngfwid=n/a
dd_type=0 dd_mode=0
npu_state=0x3000c00 ofld-O ofld-R
npu info: flag=0x82/0x81, offload=9/9, ips_offload=0/0, epid=3910/64, ipid=64/3942, vlan=0x0000/0x0000
vlifid=64/3942, vtag_in=0x0000/0x0000 in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=5/4
total session 1
FG180F-3 # get router info routing-table all
Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
S* 0.0.0.0/0 [10/0] via 10.109.31.254, port25
C 10.109.16.0/20 is directly connected, port25
C 10.109.48.0/20 is directly connected, mgmt1
C 10.122.0.0/20 is directly connected, port1
C 10.131.0.0/20 is directly connected, port9
C 172.16.0.0/30 is directly connected, SITE_TO_SITE
C 172.16.0.1/32 is directly connected, SITE_TO_SITE
A new session is created and, according to the configured firewall policy, SNAT is applied.
FG180F-3 # diagnose sys session listAfter the BGP peering is UP again, although the FortiGate has a better route to the PBX network, the host is still unable to reach the 192.0.2.1 IP as the session is still active.
session info: proto=1 proto_state=00 duration=33 expire=27 timeout=0 flags=00000000 sockflag=00000000 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/255
state=may_dirty npu
statistic(bytes/packets/allow_err): org=120/2/1 reply=384/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=8->32/32->8 gwy=10.109.31.254/10.122.3.153
hook=post dir=org act=snat 10.122.3.153:1->192.0.2.1:8(10.109.17.77:60417)
hook=pre dir=reply act=dnat 192.0.2.1:60417->10.109.17.77:0(10.122.3.153:1)
misc=0 policy_id=3 auth_info=0 chk_client_info=0 vd=0
serial=00020257 tos=ff/ff app_list=0 app=0 url_cat=0
vwl_mbr_seq=0 vwl_service_id=0
rpdb_link_id=00000000 ngfwid=n/a
dd_type=0 dd_mode=0
npu_state=0x000400 ofld-O
npu info: flag=0x81/0x00, offload=9/0, ips_offload=0/0, epid=88/0, ipid=64/0, vlan=0x0000/0x0000
vlifid=64/0, vtag_in=0x0000/0x0000 in_npu=1/0, out_npu=1/0, fwd_en=0/0, qid=5/0
no_ofld_reason:
total session 1
FG180F-3 # get router info routing-table allAfter the session is manually clear, a new one is created and the PC is able to ping the PBX IP 192.0.2.1.
Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
S* 0.0.0.0/0 [10/0] via 10.109.31.254, port25
C 10.109.16.0/20 is directly connected, port25
C 10.109.48.0/20 is directly connected, mgmt1
C 10.122.0.0/20 is directly connected, port1
C 10.131.0.0/20 is directly connected, port9
C 172.16.0.0/30 is directly connected, SITE_TO_SITE
C 172.16.0.1/32 is directly connected, SITE_TO_SITE
B 192.0.2.0/30 [200/0] via 172.16.0.2, SITE_TO_SITE, 00:00:04
FG180F-3 # diagnose sys session list
session info: proto=1 proto_state=00 duration=350 expire=51 timeout=0 flags=00000000 sockflag=00000000 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/255
state=may_dirty npu
statistic(bytes/packets/allow_err): org=120/2/1 reply=3552/37/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 10/0
orgin->sink: org pre->post, reply pre->post dev=8->32/32->8 gwy=10.109.31.254/10.122.3.153
hook=post dir=org act=snat 10.122.3.153:1->192.0.2.1:8(10.109.17.77:60417)
hook=pre dir=reply act=dnat 192.0.2.1:60417->10.109.17.77:0(10.122.3.153:1)
misc=0 policy_id=3 auth_info=0 chk_client_info=0 vd=0
serial=0002096d tos=ff/ff app_list=0 app=0 url_cat=0
vwl_mbr_seq=0 vwl_service_id=0
rpdb_link_id=00000000 ngfwid=n/a
dd_type=0 dd_mode=0
npu_state=0x000400 ofld-O
npu info: flag=0x81/0x00, offload=9/0, ips_offload=0/0, epid=88/0, ipid=64/0, vlan=0x0000/0x0000
vlifid=64/0, vtag_in=0x0000/0x0000 in_npu=1/0, out_npu=1/0, fwd_en=0/0, qid=5/0
no_ofld_reason:
total session 1
FG180F-3 # diagnose sys session listThis can be mitigated by configuring a blackole route to for the PBX network with a higher Administrative Distance.
session info: proto=1 proto_state=00 duration=10 expire=50 timeout=0 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=SITE_TO_SITE/ vlan_cos=0/255
state=may_dirty npu
statistic(bytes/packets/allow_err): org=120/2/1 reply=120/2/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=8->55/55->8 gwy=172.16.0.2/10.122.3.153
hook=pre dir=org act=noop 10.122.3.153:1->192.0.2.1:8(0.0.0.0:0)
hook=post dir=reply act=noop 192.0.2.1:1->10.122.3.153:0(0.0.0.0:0)
misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=0
serial=00021e5a tos=ff/ff app_list=0 app=0 url_cat=0
vwl_mbr_seq=0 vwl_service_id=0
rpdb_link_id=00000000 ngfwid=n/a
dd_type=0 dd_mode=0
npu_state=0x3000c00 ofld-O ofld-R
npu info: flag=0x82/0x81, offload=9/9, ips_offload=0/0, epid=3910/64, ipid=64/3942, vlan=0x0000/0x0000
vlifid=64/3942, vtag_in=0x0000/0x0000 in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=5/4
total session 1
This will ensure that, when the BGP peering is down, the traffic will be dropped and there will be no SNAT session created.
FG180F-3 # show router staticAfter the BGP peering is UP again, the route learnt via BGP will be used again to route the traffic.
edit 2
set dst 192.0.2.0 255.255.255.252
set distance 254
set blackhole enable
next
end
FG180F-3 # get router info routing-table database
Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
> - selected route, * - FIB route, p - stale info
S *> 0.0.0.0/0 [10/0] via 10.109.31.254, port25
C *> 10.109.16.0/20 is directly connected, port25
C *> 10.109.48.0/20 is directly connected, mgmt1
C *> 10.122.0.0/20 is directly connected, port1
C *> 10.131.0.0/20 is directly connected, port9
C *> 172.16.0.0/30 is directly connected, SITE_TO_SITE
C *> 172.16.0.1/32 is directly connected, SITE_TO_SITE
S 192.0.2.0/30 [254/0] is a summary, Null
B *> 192.0.2.0/30 [200/0] via 172.16.0.2, SITE_TO_SITE, 00:12:43
FG180F-3 # diagnose sys session list
total session 0
Related Articles
Troubleshooting Tip: Routing Changes and SNAT (snat-route-change)
