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 floatnetstat -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 servernetstat -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 ovpns2What 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.
-
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)
