How to Install, Configure and Troubleshoot Site to Site VPN on Sonicwall
Site to Site VPN between 2 Sonicwall routers is fairly easy to configure using the wizards on both routers. There are 100 guides out there how to do this but I found this one from the Dell site the most useful – HERE
BUT if you are inexperienced in configuring them then there is 1 big issue that might leave you tearing your hair out. I will explain below the issues (and SOLUTION) when I configured my Site to Site VPN on 2 Sonicwall routers.
Example Situation (I faced myself)
Site to Site VPN Sonicwall – Install, Configure, Troubleshooting
Situation is you have configured the VPN and you see the GREEN status on both routers.
Everything looks good, you go to the diagnostic menu on Site A router (192.168.1.1) and ping the router at Site B (192.168.2.1) and it replies it is Alive!
You do the same test on the router at Site B (192.168.2.1) and ping the router at Site A (192.168.1.1) and it is Alive!
Everything seems as simple as the 100 step by step guides say it should be, until…..
You are on Site A router (192.168.1.1) and you try to ping the server on Site B (192.168.2.101)…. ping fails… what the hell…
Now you think there must be a firewall rule blocking the ping on one of your routers (Site A or Site B). Checking them all it looks fine..
OK so how about a local ping… From Site B router (192.168.2.1) you ping the Site B Server (192.168.2.101) and it works!
You then ping locally from the Server at Site B (192.168.2.101) to the router at Site B (192.168.2.1) and it works!
Locally at Site B therefore everything looks fine.
You do the same tests on Site A between Server and router both ways and all works.
So your issue only happens when you pass through the Site to Site VPN tunnel.
Head hurting yet?? Dont worry the solution is simple.
What we didnt say much earlier, was that Site A Server (192.168.1.101) has 2 interfaces in it (eth0 local, eth1 public)
When we want to talk through the VPN from Site A to Site B we are trying to speak from 192.168.1.0 network to 192.168.2.0 network.
Site A Server has no idea where 192.168.2.0 network is, it knows about its public external ip from eth1, it also knows about its local network 192.168.1.0 from eth0, so we have to tell it how to get to 192.168.2.0.
To get to Site B we want to tell the server to use our local network (192.168.1.0) and push requests to our Site A router (192.168.1.1)
Create the following file /etc/sysconfig/network-scripts/route-eth0 and put in the following –
ADDRESS0=192.168.2.0
NETMASK0=255.255.255.0
GATEWAY0=192.168.1.1
That says for all traffic trying to get to 192.168.2.0 then send it to 192.168.1.1 (our local Site A router) then the VPN will work its magic and get to the remote end
After creating the file you need to restart the network –
service network restart
The key to this whole problem and solution was multiple network interfaces. It will not happen on a standard pc with only 1 interface as ALL traffic has no choice but to use the single interface. But on a multi-interface system then you need to tell it how to get there.
We can add 1 other element to the overall situation (should be becoming clearer now anyway), and that is you have multiple Site to Site VPNs.
If you had a Site C with router, server, pc the same just using 192.168.3.0 network, then in /etc/sysconfig/network-scripts/route-eth0 you would simply add another route to the file like this –
ADDRESS0=192.168.2.0
NETMASK0=255.255.255.0
GATEWAY0=192.168.1.1
ADDRESS1=192.168.3.0
NETMASK1=255.255.255.0
GATEWAY1=192.168.1.1
And restart your network to pick up the new route –
service network restart