|
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 acts as the source device and it will take the IPsec VPN outgoing interface (WAN) interface IP as a source if no IP address is set up on the tunnel interface, this is by design.
There are instances where a tunnel could traverse traffic out via an IP that has no relation to the config like a DMZ interface which has nothing connected.
In this case source and destination address will not match the phase2 selector and the ping request will get dropped at FortiGate.
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 show '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 violations are quite normal on links 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
The solution is to increase the probe-timeout from CLI (Only a CLI option).
config system virtual-wan-link
config health-check
edit <name>
set probe-timeout 2000
- V6.4, v7.0, v7.2, v7.4 and v7.6.
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
Related article:
Technical Tip: Probe-timeout option for virtual-wan-link health-check and system link-monitor
|
