This is a quick post inspired by my new friend Andrew Su’s frustration with setting up a Sonicwall site-to-site VPN. Andrew was doing all the right things and he did actually get both of his Sonicwall’s properly configured but traffic wouldn’t “flow”. After beating his head against the wall he contacted me for help.
Andrew’s problem was a simple one – he decided that he would add a second Sonicwall firewall to his main office location and then use the second firewall as his VPN end point. This is all well and good BUT it introduces a second gateway into the network. And it was this second gateway that was causing Andrew all his grief!
In simplistic terms, the gateway on a network is the device that “knows” how to pass traffic to networks other than the local network. We are all familiar with gateways because most of us are sitting behind one; your home router, your office router, and so forth. As an example, when you are behind your home router and you want to go to Google, your local network (the LAN) “knows” that any destination that you want to get to that is NOT on the local LAN must be accessed through the LAN gateway. Therefore, Google must be somewhere on the other side of the gateway (which, of course, it is). DNS also comes into play but the basic concept is as described.
Your PC (or other connected device) knows what the gateway is because of your network settings. Running ipconfig on my local machine gives me this output:
So, on my network, any request for a destination that is NOT in the 192.168.18.0/24 subnet must be on the other side of the gateway and traffic therefore routes out outbound through the gateway at 192.168.18.254.
There is a little bit more to all of this and that is known as routing rules. On a simple network like mine there are basic routing rules in place that further refine the “search rules” that are followed to figure out where an IP address lives. Printing out the routes on my machine gives something like this:
There is nothing very fancy in here. Essentially what it is saying is that anything on the 192.168.18.0 network is on the LAN and 127.0.0.1 is the local machine (always set for each network device, 127.0.0.1 is “home”). Anything else you route through 192.168.18.254.
You may see where I am going with all of this. My machine only “knows” about one gateway. I could have another gateway on my network, let’s call it 192.168.18.253. And let’s say that it connects, somehow (via a VPN on a second firewall) to another network 192.168.30.0/24. If I tried to ping a device at 192.168.30.10 where would the ping go? Well, it would route out through 192.168.18.254 and would get “lost” as .254 is NOT the gateway that leads to the 192.168.30.0 network! My machine has no clue about the gateway that leads to 192.168.30.0.
Now, I could get “fancy” and create routing rules either on my PC or at my firewall (router) that “define” the gateway that should be used if I’m trying to send traffic to the 192.168.30.0 network. And if I had a “complex” network layout I might just do that.
However, getting back to Andrew’s issue the better answer is to remove that second firewall at the main office and simply bring up the site-to-site VPN on the main firewall. That way there is no “complex” routing rules required as the firewalls at either end of the site-to-site VPN “know” about the LAN at the other end of the VPN and will route traffic accordingly.
The old KISS (keep it simple, Simon) rule is supremely important. Don’t introduce any more complexity than you have to when you are building your VPN’s. Get the basics working, first, then tweak things incrementally. If a tweak breaks things it’s then easy to rollback.