Site to site VPN setup puzzling me



  • Hello,

    I'm trying to get a basic site to site VPN working. The client connects fine, but the trouble comes when pinging across the tunnel.

    10.1.5.X LAN <–-> pfsense VPN client on 10.1.5.24
                                                  /
                                                  |
                                                  |
                                                  /
                                  VPN tunnel 10.0.8.X
                                                  /
                                                  |
                                                  |
                                                  /
    192.168.1.X LAN<---> pfsense VPN server on [WANIP]

    From the pfsense client, I am able to ping a machine on the 192.168.1.X LAN. In reverse, I can also ping from that same machine on the server LAN back to the tunnel IF of the client pfsense box.

    However, what I can't do is ping all the way from a machine on the 10.1.5.X LAN to a machine on the 192.168.1.X LAN. Using tcpdump, I can see packets arriving on the LAN side of the pfsense client, moving across to the tunnel IF, but then there is no sign of them when running tcpdump on the server at the other side of the tunnel.

    I also can't ping from the pfsense server to a machine on the 10.1.5.X LAN, so there isn't a symmetry to what works and what doesn't.

    Server config:

    
    dev ovpns1
    dev-type tun
    tun-ipv6
    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 tcp-server
    cipher AES-128-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local [WANIP]
    tls-server
    server 10.0.8.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc
    ifconfig 10.0.8.1 10.0.8.2
    tls-verify /var/etc/openvpn/server1.tls-verify.php
    lport [WANPORT]
    management /var/etc/openvpn/server1.sock unix
    max-clients 10
    route 10.1.5.0 255.255.255.0
    ca /var/etc/openvpn/server1.ca 
    cert /var/etc/openvpn/server1.cert 
    key /var/etc/openvpn/server1.key 
    dh /etc/dh-parameters.1024
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo
    
    

    Client config:

    
    dev ovpnc1
    dev-type tun
    tun-ipv6
    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 tcp-client
    cipher AES-128-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 10.1.5.24
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote [WANIP] [WANPORT]
    ifconfig 10.0.8.2 10.0.8.1
    route 192.168.1.0 255.255.255.0
    ca /var/etc/openvpn/client1.ca 
    cert /var/etc/openvpn/client1.cert 
    key /var/etc/openvpn/client1.key 
    tls-auth /var/etc/openvpn/client1.tls-auth 1
    comp-lzo
    
    

    Client connection log:

    
    15:19:04	openvpn[54313]: SIGUSR1[soft,connection-reset] received, process restarting
    15:19:09	openvpn[54313]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
    15:19:09	openvpn[54313]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    15:19:09	openvpn[54313]: Attempting to establish TCP connection with [AF_INET][WANIP]:[WANPORT] [nonblock]
    15:19:10	openvpn[54313]: TCP connection established with [AF_INET][WANIP]:[WANPORT]
    15:19:10	openvpn[54313]: TCPv4_CLIENT link local (bound): [AF_INET]10.1.5.24
    15:19:10	openvpn[54313]: TCPv4_CLIENT link remote: [AF_INET][WANIP]:[WANPORT]
    15:19:11	openvpn[54313]: [vpnuser] Peer Connection Initiated with [AF_INET][WANIP]:[WANPORT]
    15:19:13	openvpn[54313]: Preserving previous TUN/TAP instance: ovpnc1
    15:19:13	openvpn[54313]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
    15:19:13	openvpn[54313]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1560 10.0.8.6 10.0.8.5 init
    15:19:14	openvpn[54313]: TUN/TAP device ovpnc1 exists previously, keep at program end
    15:19:14	openvpn[54313]: TUN/TAP device /dev/tun1 opened
    15:19:14	openvpn[54313]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
    15:19:14	openvpn[54313]: /sbin/ifconfig ovpnc1 10.0.8.6 10.0.8.5 mtu 1500 netmask 255.255.255.255 up
    15:19:14	openvpn[54313]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1560 10.0.8.6 10.0.8.5 init
    15:19:14	openvpn[54313]: Initialization Sequence Completed
    
    

    Other notes:

    • I have 'allow all' rules set up for the OpenVPN IF on both sides of the connection.
    • Both pfsense boxes are running in VMs
    • I have another VPN server defined on the server pfsense box for remote access. This has been working fine for a while.

    Any pointers would be much appreciated.



  • What version of pfsense are you running?

    Your config files look basically correct, the only thing I would watch for is the need for an "iroute 10.1.5.0 255.255.255.0" statement in your Client Specific Configuration for the client on your server.

    Make sure that the Common Name in the CSC section matches exactly with then name that comes from the client certificate.  I usually watch the server's OpenVPN log file to make sure I've got the correct one (been bitten a few times from that one).

    The other thing to watch for is blocked traffic due to other firewall rules.  Check to firewall logs at both ends right after attempting a ping from one side to the other.  Sometimes you can see the blocked message at one side or the other.

    The OpenVPN setups are fairly easy and very reliable, once you get past a few little nit picky details….



  • Fantastic! That allows machines on the 10.1.5.X LAN to ping those on the 192.168.1.X LAN. I never knew about the CSC. As you say, lots of nit picking to get things set, so many thanks for your help in getting me over that hurdle.

    The only trouble is that the same path doesn't work in reverse (i.e. machines on the 192.168.1.X LAN can't ping those on the 10.1.5.X LAN). Is there some kind of similar trick needed on the other side of the connection?

    Regarding the firewall blocking things, I was under the impression that tcpdump shows packets 'on the wire', i.e. before firewall filtering?

    I'm using 2.1.3-RELEASE (amd64) on both sides.



  • I solved the 'one way ping' problem. Typically, it was a firewall issue (it seems the Windows firewall drops pings that come from other subnets by default).

    Thanks once again.



  • No problem  ;)

    I don't know how many times I've spent hours trying to solve a "pfsense" problem that was something else's fault…

    I find the OpenVPN site-site very effective and definitely worth the learning curve to get it running.  :)



  • The other common snafu is that the hosts in the target network are using a default gateway that doesn't know the route back to the source network over the VPN tunnel. This can happen if the destination end of the VPN tunnel is not on the router that is the default gateway but on a separate host on the target network.



  • @kpa:

    This can happen if the destination end of the VPN tunnel is not on the router that is the default gateway but on a separate host on the target network.

    That is exactly the setup in my situation, but I managed to work out the solution to that one for myself. Easy mistake to make, though. :)



  • Hello again,

    I'm now trying to extend the above network to include 'road warrior' clients using a 'Remote Access (SSL/TLS + User Auth)' OpenVPN server on the same box (a VM, as it happens) as the site to site server.

    My network setup now looks like this:

    10.1.5.X LAN <–-> pfsense VPN client on 10.1.5.24
                                                  /
                                                  |
                                                  |
                                                  /
                                  VPN tunnel 10.0.8.X
                                                  /
                                                  |
                                                  |
                                                  /
    192.168.1.X LAN<---> pfsense VPN server on [WANIP] (Site to site)
                                      pfsense VPN server on [WANIP] (Remote access, tun)
                                                  /
                                                  |
                                                  |
                                                  /
                                  VPN tunnel 192.168.2.X
                                                  /
                                                  |
                                                  |
                                                  /
                    Windows 7 'road warrior' with OpenVPN client on 192.168.2.10

    The Windows 7 'road warrior' can ping PCs on the 192.168.1.X LAN fine. On to the problem:

    The pings from a PC on the 10.1.5.X LAN get to the 192.168.2.10 PC and it responds. But, the return pings never get to pfsense on the other side of the RA tunnel (see attached wireshark screenshot from the Windows 7 PC). I've verified this using the packet capture in pfsense (it shows the request ping going from 10.1.5.18, but no reply back from 192.168.2.10).

    Prior to adding a route on the Windows 7 PC of: 'route add 10.1.5.0 MASK 255.255.255.0 192.168.2.9' (where 192.168.2.9 is the OpenVPN gateway, not the IF itself), the Windows 7 PC didn't even 'echo reply' to the pings (it just made an ARP request for 10.1.5.18 - I think).

    Am I missing something obvious?

    Is it something to do with iroute again? I've skimmed https://community.openvpn.net/openvpn/wiki/RoutedLans, but I'm not quite sure whether/how to alter my setup as a result.




  • Anyone?

    This has to be some bit of magic I'm missing :'(



  • I think I may have solved this with help from Zack__ on IRC. I'll update this when confirmed.