Peer to Peer (SSL/TLS) - tap - LAN Bridge - Routing issue



  • Hi,

    I'm trying to setup a Peer to Peer (SSL/TLS) (tap) connection between two sites through the internet. The tunnel is connected and seems to operate from my point of view. Unfortunately the routes don't seem to operate at all. On both sites, the relevant OpenVPN interface is correctly bridged with the LAN interface. When I turn on the DHCP client for these interfaces, both get a valid IP from the corresponding site, which proves the tunnel is up and running accordingly. a ping from each pfSense shell also proves that the corresponding site is there and reachable. But this works only from pfSense locally - not from any host connected to it. Setting the IPv4 on each OpenVPN interface individually breaks it - only DHCP seems to work and setup at least the route to the pfSense on the other site.

    Site A (OpenVPN Peer to Peer Server):
    WAN: 192.168.49.100/24
    LAN: 192.168.50.1/24 (DHCP running for this net)

    Site B (OpenVPN Peer to Peer Client):
    WAN: 192.168.9.100/24
    LAN: 192.168.10.1/24 (DHCP running for this net)

    ================ Site A (Server) ================

    dev ovpns1
    verb 3
    dev-type tap
    dev-node /dev/tap1
    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-256-CBC
    auth RSA-SHA512
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 192.168.49.100
    engine cryptodev
    tls-server
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'DOMAIN_TO_SITE_A.TLD' 1"
    lport 1196
    management /var/etc/openvpn/server1.sock unix
    max-clients 2
    push "route 192.168.49.0 255.255.255.0"
    push "route 192.168.50.0 255.255.255.0"
    route 192.168.9.0 255.255.255.0
    route 192.168.10.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.4096
    crl-verify /var/etc/openvpn/server1.crl-verify 
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo adaptive
    persist-remote-ip
    float
    
    netstat -nr4
    Routing tables
    
    Internet:
    Destination        Gateway            Flags      Netif Expire
    default            192.168.49.1       UGS         xn1
    127.0.0.1          link#4             UH          lo0
    192.168.49.0/24    link#6             U           xn1
    192.168.49.1       f0:ba:f0:ba:f0:ba  UHS         xn1
    192.168.49.100     link#6             UHS         lo0
    192.168.50.0/24    link#7             U       bridge0
    192.168.50.1       link#7             UHS         lo0
    192.168.249.0/24   192.168.249.1      UGS      ovpns5
    192.168.249.1      link#8             UHS         lo0
    192.168.249.2      link#8             UH       ovpns
    

    ================ Site B (Client) ================

    dev ovpnc3
    verb 3
    dev-type tap
    dev-node /dev/tap3
    writepid /var/run/openvpn_client3.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-256-CBC
    auth RSA-SHA512
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 192.168.9.100
    engine cryptodev
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client3.sock unix
    remote DOMAIN_TO_SITE_A.TLD 1196
    auth-user-pass /var/etc/openvpn/client3.up
    ca /var/etc/openvpn/client3.ca 
    cert /var/etc/openvpn/client3.cert 
    key /var/etc/openvpn/client3.key 
    tls-auth /var/etc/openvpn/client3.tls-auth 1
    comp-lzo adaptive
    resolv-retry infinite
    auth-nocache
    pull
    ns-cert-type server
    
    netstat -nr4
    Routing tables
    
    Internet:
    Destination        Gateway            Flags      Netif Expire
    default            192.168.9.1        UGS         xn1
    127.0.0.1          link#4             UH          lo0
    192.168.9.0/24     link#6             U           xn1
    192.168.9.100      link#6             UHS         lo0
    192.168.10.0/24    link#7             U       bridge0
    192.168.10.1       link#7             UHS         lo0
    192.168.12.0/24    192.168.12.1       UGS      ovpns2
    192.168.12.1       link#9             UHS         lo0
    192.168.12.2       link#9             UH       ovpns2
    

    What am I missing, so both sites can communicate with each network behind it? I tried plenty of variations in my setup. To me it seems broken / like a bug somewhere. This is clearly not, how one expects a peer to peer connection.

    Best regards
    Leander



  • Any idea whether this might be a bug? Routes should be added accordingly by OpenVPN/pfSense. But it fails completely.


  • Rebel Alliance Developer Netgate

    Why are you bridging if the subnets are different?

    You have given the two sides no way to reach each other. There is no tunnel network on the VPN for them to use as a gateway, and they have no subnets in common. Routing requires both sides to have an address in a common subnet. It can't push nor use routes because there is nowhere for them to go.

    Usually in a bridge scenario the LANs are the same subnet.

    From the look of your network layout, you don't need nor want a bridge. You could use tap but there is no advantage in this scenario. Remove the bridge components and follow this to setup the VPN using SSL/TLS like you have started: https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_(SSL)