Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 1649 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos Firewall - Central Orchestration - SD-WAN SLA probe targets configuration

Chris Haydon

Hi

Ok so I might be rather dim (and I hope not as I am supposedly a certified SFOS Architect!) but we are deploying a 10 SD-WAN site to site mesh of XGS firewalls with multiple WAN links into each site for a customer using SD-WAN Central Orchestration/Connection Groups - that all works relatively well apart from one issue - setting SD WAN probe targets for the SD-WAN SLAs.

Here is the config screen in Central - you can specify a probe target for each firewall now reading the guidance on SD-WAN this needs to be the remote end of the tunnel - i.e. you want to monitor the SLAs to the destination. That is how you would set it up manually so say you had a SD-WAN profile for Office 365 you would want to maybe monitor the IP for outlook.office365.com as that would give you an indication of the link quality to the Microsoft Network... in the case of a set of VPN tunnels you would set it to a host on the remote network such as lets say the remote site XGS that is terminating the tunnel.

What it appear the Connection Group functionality allow you to do is specify single default destination probe host for each firewall and then specify overrides for individual ones.

So this is a screen shot from that firewall for site GW-W-C with LAN IP 172.19.80.1/24 for a SD-WAN Profile for links to site GW-B-S with LAN IP 172.19.10.1/24

What the Central Orchestration has provisioned on every single SD-WAN Profile it has setup is the probe target IP 172.19.80.1 - so the SLA is never going to fail, nor see any latency... its monitoring a ping to itself,

Now where have explicitly gone in like for site GW-K-N above in central and explicitly specified other details then it has setup the probe to 172.19.40.1 which is the remote end of the link and thus is showing some sensible SLA stats.

Now whilst this will work and is possible to do and we could set 9 remote probe destination IPs on 10 firewalls i.e. 90 to set this surely defeats the object of using Central Orchestration to deploy it automatically.

Am I missing something or is Central Orchestration just crazy? Surely if you are setting up and SD-WAN then the default probe destination IP you specify wants to then be what the remote end uses for tunnels build towards that firewall/site... so you tell it the default that in the setting for firewall/site W to use 80.1 so that sites B and K's firewalls etc then uses 80.1 as their their SD-WAN probe destination for tunnels to site W and in K you put 40.1 and every tunnel build towards that site then uses 40.1 as its probe destination so the W firewall is monitoring K and not itself.



This thread was automatically locked due to age.
Parents
  • 0

    There is one component missing right now to build "per site probe targets" which means, either way, the admin can do it themself or leave it as Google. 

    But building google means, you have to setup a firewall rule "VPN to Google DNS". 

    Google DNS still gives you valuable data (It is the Link to the peer + WAN to DNS instead of "Only link to peer"). But if you compare both, they have both the "Link to peer" data in it. 

    Keep in mind:   

    By the way: The host you setup is being probe through the tunnels and not Internet. 

    __________________________________________________________________________________________________________________

Reply
  • 0

    There is one component missing right now to build "per site probe targets" which means, either way, the admin can do it themself or leave it as Google. 

    But building google means, you have to setup a firewall rule "VPN to Google DNS". 

    Google DNS still gives you valuable data (It is the Link to the peer + WAN to DNS instead of "Only link to peer"). But if you compare both, they have both the "Link to peer" data in it. 

    Keep in mind:   

    By the way: The host you setup is being probe through the tunnels and not Internet. 

    __________________________________________________________________________________________________________________

Children
No Data
Unfiltered HTML