Site to Site Open VPN behind Sonicwall
I am setting up an VPN from our main office to a remote office. The main office is behind a sonicwall. I have setup NAT and done port forwarding. I am attempting to use a shared key setup to do this. The two servers can see each other however they cannot establish a connection. On the remote (client) side I am getting the following error:
openvpn: Inactivity timeout (–ping-restart), restarting
On the main office side I am getting:
openvpn: Host is down (code=64)
I know more information is needed to diagnose this. Please let me know what information would be helpful in looking at this.
So I now have to server side showing the connection is up however under bytes sent it shows 0. It is however showing bytes received. This tells me something is not allowing the server to pass the packets back. Any help would be wonderful! Thank you!
After looking at other posts this looks like information that would help. This is the Client side conf file:
dev ovpnc1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local XX.XXX.140.218 lport 0 management /var/etc/openvpn/client1.sock unix remote XXX.XXX.55.201 1194 ifconfig 10.0.8.2 10.0.8.1 route 192.168.0.0 255.255.0.0 secret /var/etc/openvpn/client1.secret
This is the client side routing table:
default XX.XXX.140.217 UGS 0 351863 1500 bge0 10.0.8.1 link#9 UH 0 0 1500 ovpnc1 10.0.8.2 link#9 UHS 0 0 16384 lo0 XX.XXX.140.216/30 link#2 U 0 2248 1500 bge0 XX.XXX.140.218 link#2 UHS 0 0 16384 lo0 127.0.0.1 link#6 UH 0 111 16384 lo0 192.168.0.0/16 link#1 U 0 337393 1500 em0 192.168.1.254 link#1 UHS 0 0 16384 lo0
This is my server side conf file:
dev ovpns1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 10.1.1.253 ifconfig 10.0.8.1 10.0.8.2 lport 1194 management /var/etc/openvpn/server1.sock unix push "route 10.0.0.0 255.0.0.0" route 192.168.0.0 255.255.0.0 secret /var/etc/openvpn/server1.secret server1.conf: unmodified: line 1
This is my server side routing table:
0.0.0.0/1 link#1 U 0 11116 1500 em0 => default 10.1.1.254 UGS 0 64 1500 em0 10.0.8.0/30 10.1.1.254 UGS 0 0 1500 em0 10.0.8.1 link#7 UHS 0 0 16384 lo0 10.0.8.2 link#7 UH 0 0 1500 ovpns1 10.1.1.253 link#1 UHS 0 0 16384 lo0 127.0.0.1 link#5 UH 0 54 16384 lo0 192.168.0.0/16 10.0.8.2 UGS 0 0 1500 ovpns1 IPv6
Any help would be great!
phil.davis last edited by
It seems that:
Client end LAN 192.168.0.0/16
Server end LAN 10.1.1.0/24 (or 10.1.0/16 or ?)
The client conf has:
route 192.168.0.0 255.255.0.0
That is telling the client that 192.168.0.0/16 is across the VPN, but actually it is local.
Check what you have entered in local and remote networks at each end.
If more help is needed, post a network map and OpenVPN setting screenshots.
This is the screenshot from my server.
This is the client side config screenshot:
This is a basic network map of the connection. Changing the client side to have the remote network be 10.0.0.0/8 is allowing the server side to show the connection is up and is sending and receiving data. The client side is reconnecting due to ping. Please let me know if you need any further information. Any help is greatly appreciated.
phil.davis last edited by
Sonicwall is using 10.0.0.0/8 for its LAN network. That conflicts with the tunnel network that you have chosen. So the server pfSense will be confused about where 10.0.8.0/30 actually is.
- I can't believe that your main office needs 10.0.0.0/8 for a LAN. If it just uses address like 10.1.1.* then make it 10.1.1.0/24 or even 10.1.0.0/16 - but that might be rather difficult for you to implement.
- Choose a tunnel network in different private IP space - for some reason you have already used the whole of 192.168.0.0/16 as the client end LAN? 172.16 is still possible, makeup a tunnel subnet like 172.16.42.0/30
At main office, Sonicwall will need a route to 192.168.0.0/16 through pfSense LAN IP 10.1.1.253 - this will allow systems on main office LAN to send packets to your client end using their default gateway (Sonicwall) which will redirect them to pfSense.