Unable to get bidirectional traffic on site to site VPN



  • Folks,

    I've been struggling for several days to establish a site to site VPN based on OpenVPN. I've only managed to get traffic from the LAN attached to the PFsense client-side to reach the LAN behind the PFSense Server-side, but no traffic initiated from the opposite end. I've tried several variations with no luck so far.

    Here's the setup:

    192.168.41.0/24 (LAN)–[PFsense Client]<–---------->[PFsense Server]–(LAN) 192.168.39.0/24

    PFSense Client-side
    LAN iface: 192.168.41.230
    OpenVPN iface: 192.168.110.6

    PFSense Server-side
    LAN iface: 192.168.39.230
    OpenVPN iface: 192.168.110.1

    The PFSense Server-side has a bunch of extra interfaces defined that are not being used for this test.

    Client1.conf

    
    [2.1-RELEASE][admin@pfsense.localdomain]/var/etc/openvpn(2): more client1.conf
    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 udp
    cipher BF-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 192.168.61.1
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote 192.168.60.1 1194
    ifconfig 192.168.110.2 192.168.110.1
    route 192.168.39.0 255.255.255.0
    ca /var/etc/openvpn/client1.ca 
    cert /var/etc/openvpn/client1.cert 
    key /var/etc/openvpn/client1.key 
    comp-lzo
    

    Server1.conf

    
    [2.1-RELEASE][admin@fwcer.localdomain]/var/etc/openvpn(2): more server1.conf
    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 udp
    cipher BF-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 192.168.60.1
    tls-server
    server 192.168.110.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc
    ifconfig 192.168.110.1 192.168.110.2
    tls-verify /var/etc/openvpn/server1.tls-verify.php
    lport 1194
    management /var/etc/openvpn/server1.sock unix
    max-clients 10
    push "route 192.168.39.0 255.255.255.0"
    route 192.168.41.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
    comp-lzo
    

    Attached goes the routing tables. I'm unable to detect inconsistencies in them.

    As I said, I do get traffic flow back and forth from a PC at the client-side LAN to another one on the server-side LAN, but not the other way around (i.e. traffic initiated from the server-side LAN does make it thru the openvpn interface but never reaches the openvpn interface at the client-side).

    I'm clueless right now because I don't get blocks/rejects at the firewall logs at any PFsense and at the OpenVPN logs client-side the only anomaly I detect is an "Error: FreeBSD route add command failed: external program exited with error status:1"

    Any hints will be more than welcome.

    Thanks





  • I've got some doubts about the server.conf and client.conf being generated by the php code.

    Server.conf:

    1. Why it does include```
      tun-ipv6
    
    2) The line```
    server 192.168.110.0 255.255.255.0
    ```is correctly generated? I've never seen it in former server.conf files I've had access to
    
    Client.conf:
    
    1) Why it does include```
    tun-ipv6
    ```if I specifically didn't enabled IPv6 in system->Advanced->Networking
    
    I've noticed that If I manually edit those files, changes are not persistent through power cycles. Is there a formal way to make manual adjustments persistent? OS scripting?
    
    thanks!


    • Probably stuck in there because of the new functionality in the OpenVPN v2.3.x releases.  Although, most likely ignored unless the expanded directives are added (devs can chime in)

    • Yes, that line is correct.  That (server 192.168.110.0 255.255.255.0) is added when you configure OpenVPN in server mode (Remote Access) and is defined on the "IPv4 Tunnel Network" line.  In your case, the server will take 192.168.110.1 for itself and the rest will be made available to clients.

    • Same as #1

    Your configs look ok, so I would try these if you haven't done them already:

    • add any/any firewall rules to both the LAN and OpenVPN tabs on both server and client

    • disable windows firewall to verify traffic is not getting dropped there

    • if you've been adding and deleting different routes and firewall rules a reboot of both sides sometimes fixes weird connectivity issues (you can also try resetting your states first)

    • make sure PFsense is the default gateway of the workstations/servers on both sides



  • @Marvosa: thanks for your suggestions and observations.

    In response to your suggestions:

    1. I already have in place any to any rules in all relevant interfaces in my testbed

    2. I'm not using windows at all, and yes, I have permissive host firewall rules in both desktops at each LAN

    3. I've tried rebooting several times (although not quite after each change/attempt)

    4. It is.

    The weirdest thing to me is the fact that when I ping a Client-side LANs desktop from a Server-side LAN desktop and capture traffic at the virtual interface from the PFSense that runs as OpenVPN server (opvpns1) I do see the packets passing through, but I don't see them coming to opvpnc1 (virtual interface from the PFSense that runs as OpenVPN client). It seems as those packets 'get lost' at the OpenVPN tunnel.

    And as I mentioned in previous posts, I don't spot any issues either with the traffic routes or with filtered out packets at the firewall log.

    Thanks once again though


Log in to reply