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.
ssahu_tac
Staff
Staff
Article Id 217089
Description This article describes that, when interfaces or IPSEC VPN members are added to SD-WAN and have issues with performance, SLA being down.
Scope FortiOS 6.2/6.4/7.0/7.2
Solution

Routing:

 

With IPSEC when tunnels are added to SD-WAN, IP addresses are configured between HQ and branches for dynamic routing protocols such as BGP .

 

Add FortiGate local interface IP as source ip for VPN in SD-WAN.

 

# config system virtual-wan-link

# config members

    edit <id>

        set source x.x.x.x  <----- Lan interface IP.

        set gateway x.x.x.x <----- Remote interface. IP.    

    next

end

 

Avoid using the IPSEC tunnel interface IP as the gateway when configuring IPSEC tunnels with SD-WAN, the gateway should either be the remote end of the tunnel or unset .

This will cause a loop on the FortiGate routing table and probes would not be able to exit out the correct interface.

 

Traffic Selectors:

 

- With Specific phase2 configured.

 

FortiGate itself act as the source device and it will take the IPsec VPN outgoing interface (WAN) interface IP as source if no IP address is setup on the tunnel interface, this is by design.

 

There are instances where a tunnel could traverse traffic out via an IP which has no relation to config like a DMZ interface which has nothing connected.

In which case source and destination address will not match the phase2 selector and ping request will get dropped at FortiGate itself.

 

# dia vpn tunnel list

name=HO_port1_2 ver=1 serial=1 10.40.16.57:0->10.40.16.20:0

bound_if=3 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/0

proxyid_num=1 child_num=0 refcnt=20 ilast=0 olast=0 ad=/0

stat: rxp=352 txp=453 rxb=42240 txb=27180

dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=5

natt: mode=none draft=0 interval=0 remote_port=0

proxyid=HO_port1_2 proto=0 sa=1 ref=2 serial=2

  src: 0:172.31.192.0/255.255.240.0:0

  dst: 0:172.31.128.0/255.255.240.0:0

  SA:  ref=3 options=10226 type=00 soft=0 mtu=1438 expire=42225/0B replaywin=2048

       seqno=1c6 esn=0 replaywin_lastseq=00000161 itn=0

  life: type=01 bytes=0/0 timeout=42901/43200

  dec: spi=e04e9478 esp=aes key=16 73cb7c9658e2b3bf3f9eddbf3e966514

       ah=sha1 key=20 1c990b12c0ef9df9721f550924cc69e2ceadcbcc

  enc: spi=276713b0 esp=aes key=16 83199cc34061a388045e59a157827281

       ah=sha1 key=20 6ebe8070d5f7105ec4a70da6eb4e1e467a701463

  dec:pkts/bytes=352/21120, enc:pkts/bytes=453/54360

 

# dia sniffer packet any "host 172.31.128.20 and icmp" 4

interfaces=[any]

filters=[host 172.31.128.20 and icmp]

0.630359 HO_port1_2 out 10.40.16.57 -> 172.31.128.20: icmp: echo request

0.630388 HO_port2_3 out 10.40.16.57 -> 172.31.128.20: icmp: echo request

1.640399 HO_port1_2 out 10.40.16.57 -> 172.31.128.20: icmp: echo request

1.640444 HO_port2_3 out 10.40.16.57 -> 172.31.128.20: icmp: echo request

 

Flow filter logs shows 'No matching IPsec selector, drop'.

 

id=20085 trace_id=3 func=print_pkt_detail line=5517 msg="vd-root:0 received a packet(proto=1, 10.40.16.57:257->172.31.128.20:2048) from local. type=8, code=0, id=257, seq=50."

id=20085 trace_id=3 func=resolve_ip_tuple_fast line=5597 msg="Find an existing session, id-00001308, original direction"

id=20085 trace_id=3 func=ipsecdev_hard_start_xmit line=692 msg="enter IPsec interface-HO_port1_2"

id=20085 trace_id=3 func=ipsec_common_output4 line=804 msg="No matching IPsec selector, drop" <-----

 

- With open phase2 configured : (0.0.0.0/0.0.0.0).

 

In this instance the selector would not affect the routing, since it is controlled by static routes or firewall policies.

Things to validate would be the gateway config, SD-WAN rules and IPv4 policies .

 

High Latency:

 

SLA's violations are quite normal on link with high latency, in such instances SLA link monitoring flaps intermittently.

By default, the probe-timeout has the value of 500 ms, therefore if the link has a higher latency the probe will fail.

 

# diagnose sys sdwan health-check

Health Check:

Seq(1 port1): state(dead), packet-loss(100.000%) sla_map=0x0

 

By default, the probe-timeout has the value of 500 ms, therefore if the link has a higher latency the probe will fail.

 

The solution is to increase the probe-timeout from CLI (Only a CLI option).

 

FortiOS 6.2.

 

# config system virtual-wan-link

# config health-check

    edit <name>

        set probe-timeout 2000

                               

FortiOS 6.4, 7.0 and 7.2.

 

# conf system sdwan

# config health-check

 edit <name>

        set probe-timeout 2000  

        set probe-timeout   <----- Time to wait before a probe packet is considered lost (500 - 3600000 msec, default = 500).

 

Result.

 

# diagnose sys sdwan health-check

Health Check

Seq(1 port1): state(alive), packet-loss(0.000%) latency(941.158), jitter(27.486) sla_map=0x0