Site to Site Open VPN behind Sonicwall

Jester199

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[27025]: Inactivity timeout (–ping-restart), restarting

On the main office side I am getting:

openvpn[60023]: 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.

Thanks!

Jester199

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!

Jester199

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

Jester199

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

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.

Jester199

This is the screenshot from my server.

Server.jpg_thumb

Jester199

This is the client side config screenshot:

client1.jpg_thumb

client2.jpg_thumb

Jester199

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.

Network.jpg_thumb

phil.davis

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.
Either:

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.