SDWAN on dialup VPN connection

[satz]

Hello community,

we have a situation where we like to use an add IPsec Tunnel for an SD-WAN Interface between branches and HQ. this IPsec is based on a DialUP VPN.

Does anybody know if there are limitations for dailup vpns. the main problem is i could not even sniff packets for perf sla from HQ to the Branch. While the Tunnel is up.

from branch to HQ the perf SLA works but the way back the SLA is not working. (in general the active configuration with std S2S tunnel is fine - also the FW policies are fine)

we are running 7.0.1 on our devices.

Best Sascha

[AlexC-FTNT]

May be helpful to see how you have configured performance SLA (at least the IPs), and what sniffer command you use to capture the traffic. Routing table may also help see the problem (if the SLA check traffic is sent on the correct interface): get router info routing-table detail x.x.x.x (use the IP used for SLA check)

[satz]

Perf SLA HQ site 

TRA-FW-01 (LO_TRA_SLA_TS) $ show
config health-check
edit "LO_TRA_SLA_TS"
set server "172.20.243.243"
set interval 2000
set probe-timeout 2000
set update-static-route disable
set members 21 22 29
config sla
edit 1
set latency-threshold 2000
set jitter-threshold 500
set packetloss-threshold 1

tunnel inf 172.20.243.78 on HQ site

Perf SLA on the Branch

edit "PING TRA"
set server "172.20.243.254"
set interval 2000
set probe-timeout 2000
set update-static-route disable
set members 1 6 8
config sla
edit 1
set latency-threshold 2000
set jitter-threshold 500
set packetloss-threshold 1

172.20.243.77 Tunnel IF on the Branch

sniffer command <depends on the site of cause>

dia sniffer packet any "host 172.20.243.254 and icmp" 4

routing table

172.20.243.243 no entry on the HQ  site (but is this nessecary?)

on the Branch site i see a routing information over ospf from HQ site for the loopback - but from the GRE interface

but again is it nessecary for the perf sla?

Best

[AlexC-FTNT]

Routing is necessary for any packet that needs to be sent out.
Routing = knowing where to send the packets

Simply put, if your output to:

TRA-FW-01# get router info routing-table detail 172.20.243.243 

shows nothing, it means the packet is dropped. Debug flow will show that (no route to host, or something similar)

[satz]

i got your point and i am totaly with you - but i do not have a route to the loopback from the branche even through the other two tunnel interfaces -

TRA-FW-01 $ get router info routing-table detail 172.20.243.243

Routing table for VRF=0
Routing entry for 172.20.243.243/32
Known via "static", distance 10, metric 0, best
* directly connected, TRA-TS-BACK2

I just now put a static route in but nothing changed - 

just for the baseline i have three tunnel interface and i like to make a SLA to the loopback of the fw of the other site.

how does this should look like. i mean this config here works some how but apart of the running system how should it be?

thx in advanced 

[Toshi_Esumi]

Looks odd. 172.20.243.243 is a loopback interface IP on the branch side, right? Then it's showing "Known via static (route)" at the HQ BEFORE you put a static route. The oddest is it also shows "directly connected, TRA-TS-BACK2", which is your tunnel interface.

Do you happened to have unused VIP config or something on the HQ FGT referring to this IP?

Maybe because this is a dialup IPSec.

Toshi

[satz]

FW-TS-01-Sec $ dia sniffer packet any "host 172.20.243.254 and icmp" 4
interfaces=[any]
filters=[host 172.20.243.254 and icmp]
1.611334 GRE-TS-TRA out 172.20.243.26 -> 172.20.243.254: icmp: echo request
1.611408 IPSEC-TRA-MAIN out 172.20.243.73 -> 172.20.243.254: icmp: echo request
1.611574 IPSEC-TRA-BACK2 out 172.20.243.77 -> 172.20.243.254: icmp: echo request
1.641697 GRE-TS-TRA in 172.20.243.254 -> 172.20.243.26: icmp: echo reply
2.421817 IPSEC-TRA-MAIN in 172.20.243.254 -> 172.20.243.73: icmp: echo reply
3.631471 GRE-TS-TRA out 172.20.243.26 -> 172.20.243.254: icmp: echo request
3.631545 IPSEC-TRA-MAIN out 172.20.243.73 -> 172.20.243.254: icmp: echo request
3.631645 IPSEC-TRA-BACK2 out 172.20.243.77 -> 172.20.243.254: icmp: echo request
3.683692 GRE-TS-TRA in 172.20.243.254 -> 172.20.243.26: icmp: echo reply
4.467752 IPSEC-TRA-MAIN in 172.20.243.254 -> 172.20.243.73: icmp: echo reply
5.632123 GRE-TS-TRA out 172.20.243.26 -> 172.20.243.254: icmp: echo request
5.632190 IPSEC-TRA-MAIN out 172.20.243.73 -> 172.20.243.254: icmp: echo request
5.632281 IPSEC-TRA-BACK2 out 172.20.243.77 -> 172.20.243.254: icmp: echo request
5.673412 GRE-TS-TRA in 172.20.243.254 -> 172.20.243.26: icmp: echo reply
6.460145 IPSEC-TRA-MAIN in 172.20.243.254 -> 172.20.243.73: icmp: echo reply

TRA-FW-01 $ dia sniffer packet any "host 172.20.243.243 and icmp" 4
interfaces=[any]
filters=[host 172.20.243.243 and icmp]
1.381407 GRE-TRA-TS out 172.20.243.25 -> 172.20.243.243: icmp: echo request
1.381499 TRA-TS-MAIN out 172.20.243.75 -> 172.20.243.243: icmp: echo request
1.410013 GRE-TRA-TS in 172.20.243.243 -> 172.20.243.25: icmp: echo reply
2.106526 TRA-TS-MAIN in 172.20.243.243 -> 172.20.243.75: icmp: echo reply
3.391431 GRE-TRA-TS out 172.20.243.25 -> 172.20.243.243: icmp: echo request
3.391537 TRA-TS-MAIN out 172.20.243.75 -> 172.20.243.243: icmp: echo request
3.414966 GRE-TRA-TS in 172.20.243.243 -> 172.20.243.25: icmp: echo reply
4.106583 TRA-TS-MAIN in 172.20.243.243 -> 172.20.243.75: icmp: echo reply
5.411364 GRE-TRA-TS out 172.20.243.25 -> 172.20.243.243: icmp: echo request
5.411458 TRA-TS-MAIN out 172.20.243.75 -> 172.20.243.243: icmp: echo request
5.432045 GRE-TRA-TS in 172.20.243.243 -> 172.20.243.25: icmp: echo reply

[fallbrandson8]

TRA-FW-01 $ dia sniffer packet any "host 172.20.243.243 and icmp" 4
interfaces=[any]
filters=[host 172.20.243.243 and icmp]
1.381407 GRE-TRA-TS out 172.20.243.25 -> 172.20.243.243: icmp: echo request
1.381499 TRA-TS-MAIN out 172.20.243.75 -> 172.20.243.243: icmp: echo request
1.410013 GRE-TRA-TS in 172.20.243.243 -> 172.20.243.25: icmp: echo reply
2.106526 TRA-TS-MAIN in 172.20.243.243 -> 172.20.243.75: icmp: echo reply
3.391431 GRE-TRA-TS out 172.20.243.25 -> 172.20.243.243: icmp: echo request
3.391537 TRA-TS-MAIN out 172.20.243.75 -> 172.20.243.243: icmp: echo request
3.414966 GRE-TRA-TS in 172.20.243.243 -> 172.20.243.25: icmp: echo reply
4.106583 TRA-TS-MAIN in 172.20.243.243 -> 172.20.243.75: icmp: echo reply
5.411364 GRE-TRA-TS out 172.20.243.25 -> 172.20.243.243: icmp: echo request
5.411458 TRA-TS-MAIN out 172.20.243.75 -> 172.20.243.243: icmp: echo request
5.432045 GRE-TRA-TS in 172.20.243.243 -> 172.20.243.25: icmp: echo reply fall guys

thanks for your share.

[satz]

Hello topic is possible solved - not final tested - but we are a step further.

the issuse is addressed in the new version 7.0.4 which will be published soon. i was in contact with the tec support.

we solved the issue be add addionialy specific phase2 configuration on the hq site (for the dailup connection) to address the local networks and the loopback on the remote site. after this the Perf SLA was coming up.

Best 

[carlvc]

any detail on the required phase 2 configuration? I'm struggling with the same issue all day, until I found this chain...