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[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!



  • 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!



  • 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.




  • 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:

    1. 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.
    2. 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.


Log in to reply