SD-WAN VS Site-to-Site VPN
MvV
Newbie ✭
Hi,
I'm completly new to SD-WAN with Sonicwall, so please bear with me, and forgive my "stupid" question.
We have multiple offices, which are now connected to the mainoffice, for some intranet services. (Almost) all sites are connected with two different ISPs, like shown in this picture.
All sites have an active Site-to-Site VPN configured, for the zone WAN. I'd like to be able to control traffic over the VPN, to select the best path, so I thought of SD-WAN.
In Sonicwall I can select the WAN interfaces as an SD-WAN group, or a tunnel interface. We switched to Site-to-Site VPN, because of the binding to "Zone WAN", instead of a named interface (like X1).
What should I do to get SD-WAN working with all sites, so all sites can mix the routes from the WAN connections on both sides of the sites. So I get routed like this:
Or is Site-to-Site VPN my best option?
Thanks in advance!
MvV
Answers
Or do you want to discuss dis/advantages of using either Multi-WAN+S2S or SDWAN+Tunnel Interfaces? Have you considered Policy Based Routing options at all?
The best option is the option that meets your needs.
Hi TKWITS,
Thank you for your reply. I've noticed this article, but the thing that doesn't make sense to me (or I'm not smart enough to get how it works) is the following:
What if X1 fails on site A, and X2 fails on site B? Then both Tunnelinterfaces are down, but there is a WAN connection on both sites online, so there is a way to route the traffic, but there is no Tunnel interface for this route.
How should I create the most failsave scenario?
@MvV , what @TKWITS is referring to is like the below and is definitely the best way to go,
I've recently set this up with a customer using the Tunnel Interface with Policy based routing (not VPN Tunnel Interface), for the two Internet connections you will need 4 policies for complete redundancy, like the example below, you would need to name them accordingly so they make sense e.g. Policy 1 you could name Local( site name ) X1 to Remote ( site name ) X1,
you would then need to set up 4 routes in the routing you can do this individually or use the Multipath routing. (you will need to replicate this on all the sites in the same order) this example below is just for 1 local site to the remote site using both the WAN Interfaces,
ideally you need to write it all down so you don't get confused as in your example you are going to need X4 policies on each remote site and then for the site ASC you will need to create X24 policies to cover the individual site to site VPN with their failovers
Policy 1 :X1 to X1 - Primary Route (this policy will be used if X1 on both the local and the remote side are available)
Policy 2 :X1 to X2 - if X1 on the remote network goes down it fails to this route (Policy 2)
Policy 3: X2 to X1 - if X1 on the Local device goes down it fails to this Secondary Route (Policy 3)
Policy 4: X2 to X2 - if X1 on the local device is down and also X1 is down on the remote device it fails to this (Policy 4)
https://www.sonicwall.com/support/knowledge-base/how-can-i-configure-a-tunnel-interface-vpn-route-based-vpn/170505633799556/
For the sake of your own sanity you need the VPN policies to have descriptive names, eg:
siteA-X2toX1
would be associated with a VPN policy at the other end called
siteB-X1toX2
etc.
And yes, put it all in a spreadsheet.
Hi All,
Thank you for your pointers, and help.
I've created a complex setup (my Sonicwall TS also called me crazy). But the thing I'm building now:
per site 4 Tunneld VPNs (like you suggested with PolicyBasedRouting), but then I leave the policy @ SD-WAN policies, so I can enumerate the SD-WAN path selection criteria like Lowest Jitter/Loss/Latency.
Only concern now: Am I making it to complex, to manage, or am I building a super resilliant HA solution.
Thinking about testing above scenario with 1 location, before I procede with the other sites :)
If all fails / succeeds I'll let you know. For now, first a moment of contemplating, trying to figure out what is the best solution for me ;)
"Only concern now: Am I making it to complex, to manage, or am I building a super resilliant HA solution."
As long as it's properly documented and understood than complexity shouldn't be concerning, but sometimes the simplest solution is the best.
I rarely have to do anything as complex as what @preston described. Most businesses I work with barely consider a redundant connection at all, and 99% who do are satisfied with simple S2S VPNs with two ISPs for fail over between locations. Personally I hardly consider any ISP connection in a metropolitan area to be that concerning when considering latency, jitter, etc. (unless your going bargain basement with your ISPs). IMO SD-WAN would have been relevant when DSL and Cable were neck and neck and fiber was out of the question.
There are plenty of sites out there in the latter category TWKITS and that is where we get the most benefit from SD-WAN.
Most of our customers have 1x high-quality fibre WAN + a 4G backup, in which case SD-WAN isn't worth the hassle because it's very obvious which path should be used at any time, and it's just not necessary to load-balance the traffic to extract maximum performance.
But if they are 100 miles from the middle of nowhere with 2x slow ADSLs + a low-speed 2/3/4G then having multiple paths that can be used simultaneously brings the best performance. And requires a great big heap of VPN tunnels...
@Arkwright : I noticed that you mentioned: "hen having multiple paths that can be used simultaneously brings the best performance."
From my understanding the Sonicwalls SD-WAN just uses one WAN-connection it does not combine them, does it?
If you have multiple tunnels in an SD-WAN group, then any that are "Qualified" per the link quality parameters you set, will be used. I am not sure how the firewall chooses which link to put any given flow down.
ok, but it chooses one connection, not both can be used parallel. so if i have 2x50 mbit/s i cant make it a 100mbit/s sd-wan line
per-flow, yes. One flow can only ever go down one tunnel. But there will always be more than one flow, right?
You can see this for yourself in "SD-WAN Connection Log". The Iface columns do not show actual VPN tunnel interface name, but they do show the physical interface the tunnel is bound to.
ah i will have a look at this, thanks