I have two sites connected with a layer 2 EPL that allows me to treat the remote site as if I plugged in a 500 mile ethernet cable into my core switch.
I had an event where our fiber line was cut, so the EPL went down between sites. Our cable modem services were working.
I setup a site to site VPN tunnel using my SonicWALL but I could not pass traffic either direction to the remote site. How would I go about setting up a failover for this so that when the EPL is unavailable, the site to site VPN would be used as backup?
My clients all look at the core switch for layer 2 and VLANs for site A and B reside on both core switches, and have an all zero route that sends traffic to the SonicWALL for internet traffic.
Client A Site IP’s: 192.168.0.x GW: 192.168.0.2Core switch IP Route 0.0.0.0 192.168.0.30
Core switch site A IP 192.168.0.2 SonicWALL Firewall IP 192.168.0.30
Client B Site IP’s: 192.168.1.x GW: 192.168.1.1 IP Route 0.0.0.0 192.168.1.30
Core switch site B IP 192.168.1.1SonicWALL Firewall IP 192.168.1.30
Ideally you’d run BGP over both the L2VPN and the IPSec VPN and prefer the EPL.
I’m not super familiar with BGP, is there any approach I could take leveraging the SonicWALL? If not, I can familiarize myself with BGP and use this approach if that’s the best way to handle this from the switch
This might be a good learning situation to re-evalute your WAN. Instead of spanning layer2 at the WAN perhaps introduce layer3 capabilities and dynamic routing. Obviously you would still use the EPL and have layer2, but inside that layer tywo, just a single /30 or the like with routing between the sites. Then, after that is in place, you could augment the WAN with DIA backup circuits also providing routed access using a less preferred priority.
Ideally you want to be running bgp for automatic failover, but you can also hack it through with weighted static routes if your network isn’t huge. Not recommended though as statics become massively a pith as they grow.
I know that this isn’t the question you’re asking, but why are you running a flat network which is going to give you potential headaches like this? A more recent approach would be to use something like SDWAN which would manage the security across the network as well as primary and secondary carriage.
Appreciate the feedback guys!
The EPL uptime is pretty solid, so failover hasn’t been much of a concern. Over the past 5 years, it’s gone down for 6 hours which was caused due to the underground fiber being cut by a contractor. Our COAX was available, so site to site VPN could have been an option, I just couldn’t get traffic to pass over it. I’m investigating options to see what’s possible, and if it’s worth the network configuration changes.
We have a relatively small network but we do have several VLANs to help separate traffic for us logically and give us a few more IP’s to pull from. We have kept it flat for simplicity, we are under 500 total IP’d devices and don’t consume a ton of bandwidth at these remote sites. The EPL WAN gave us speed/reliability that my old site to site VPN’s over Fiber or COAX couldn’t provide. We had redundancy managed by a router, but at the cost of speed and response time.
At the time when we decided to span layer 2 to our remote site, we wanted to treat it the same as if it were a building at our corporate office that was 300ft or greater away connected via fiber. That has worked well for us, but with these kind of drawbacks for sure.
It sounds like to get the type of routing I’m looking for, I’ll need to introduce BGP at the core switch at each location to pick a gateway based on the IP range it’s looking for, if that’s even how that works.
Unless you’ve got web servers, MX records, user VPN configs, or anything else that depends on a static public IP address, BGP is probably overkill based on the internal IP architecture you provided. The only real problem will be the change in the user experience going from an uninterrupted & isolated EPL point-to-point high speed circuit to a mid-range firewall based site-to-site VPN tunnel using up years of device-life from encrypting and decrypting endlessly over the public wire. As long as you are able to manage user expectations if and when it is needed, then you might consider a non-BGP solution that you can test on a regular basis yourself. One of your responses conceptually described basic aspects for a non-BGP solution, as did a couple of Comments. I would look there first, but don’t make the mistake of figuring it out on your own. That’s what you pay your ISP vendor to help you do.
I would suggest not using 192.168.anything. Untold millions of home network routers default to the same class C subnets, and looking ahead it will cause you a lifetime of troubleshooting only to discover the subnets on both sides of a remote userbase VPN are fundamentally the same, with the routing equally likely to keep a packet on the office 192.168.0.0/24 & 192.168.1.0/24 or send it back to the VPN user’s home subnet of 192.168.0.0/24 or 192.168.1.0/24 .
You will likely need need two firewalls designed to work with either two independent ISP vendor circuits or one ISP and two different class of circuits. Assuming both circuits are Comcrap or a reasonable facsimile thereof, then we know the EPL is a specialized business class circuit and the coax is not. Work with your ISP account rep and ask them directly. They didn’t understand things like this 15 years ago but they do now. With your obvious curiosity and desire to make it work, with your ISP’s in-house solutions architects doing exactly this same thing for other customers just like you, with some internal DHCP & static routes & priority tweaks, and lastly a liberal does of good luck, I think this is very much within your capabilities to solve in a cost effective and secure manner. Might not be the fastest backup WAN & Internet failover in the neighborhood, but you’ll be connected and sometimes that is all you need.
I don’t have any public facing web servers or user VPN configs - it’s a fairly simple network. At least, I tried to keep it that way until business requirements dictate otherwise. The site to site VPN tunnel would be backup, used in worse case disaster scenarios.
Appreciate the feedback on my private IP ranges, I do have different IP ranges I just provided a simplified view of my network for my post here.
It sounds like either approach requires me to make some adjustments on my core switches on each end to consider the SonicWALL as a route when layer 2 is unavailable.
I think I have enough information now to start designing a solution and do some testing. Thanks everyone!
It would be helpful in the future if you would click reply on the comment you are trying to reply to. Your comments are just kinda randomly sprinkled into the thread with no continuity.
It would be setup more like the following:
1)Core switches have direct peering over EPL link
2)Core switches peer to each sonicwall at the site
3)if you can convert your ipsec connection to also exchange routing over BGP now you automatically have your weighted path due to a longer BGP as-path seen from the perspective of your core switches