Can't reach client-side LAN from OpenVPN TLS peer-to-peer

TTBruce

I've been banging my head against the wall with this. I've been using shared key tunnels for years and trying to set up some new TLS site-to-site VPNs, following this guide: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html

The setup is very simple. Shouldn't be much different from the example, which I've been over about 10 times now. I realize it should be very simple, but I just can't get it working, and if I don't soon I will have to resort to more shared key tunnels.

The tunnel is successfully being created and passing traffic. I am able to ping from the client LAN to a device in the server LAN.

The issue: I am unable to ping from the OpenVPN network to any device on the client network. This includes from any device on the server LAN, from the server, or from the client pfsense itself, using the OpenVPN interface:

The same ping goes through if the OpenVPN connection is stopped:

The layout:
2 brand new, factory reset Netgate SG-1100. Both have their WAN port connected to my home lab router.

OpenVPN Endpoint Settings - Site A - Server

WAN Address
10.1.0.77

LAN Subnet
192.168.1.0/24

LAN Address
192.168.1.1

CA Name
S2SCA

Cert CN
serverA

Tunnel Net
10.0.8.0/24


OpenVPN Endpoint Settings - Site B - Client

Cert CN
clientB

WAN Address
10.1.0.69

LAN Subnet
172.16.2.0/24

LAN Address
172.16.2.1

The configuration: I will include just what I think is relevant, but I can provide more info as needed. I don't think the authentication settings are important since I can confirm the client specific overrides are being properly matched by CN.

Server side - OpenVPN Server:

Server side - Client Specific Override:

Server side - OpenVPN Firewall rule:

Client side - OpenVPN Client: Tunnel settings all left blank, provided through server/overrides

Client side - OpenVPN Firewall rule: Identical to the one on the server

Client side routes (Note I changed the server-side LAN to 10.20.0.0/24 at this point to avoid potential conflicts):

Server side routes:

Server side OpenVPN status/routes:

I'm running out of ideas here... can anyone help me? I was originally running into this problem while configuring the devices using our production SG-3100 as the server, running into the same issue, so I decided to set it up from scratch on my home lab. Same result. Hoping someone can point out where I went wrong.

Thanks!

TTBruce

I'm also seeing this from time to time as I work through different settings. It looks like maybe the routing is somehow getting caught in a loop between interfaces:

PING 172.16.2.90 (172.16.2.90) from 10.0.8.2: 56 data bytes
92 bytes from 10.0.8.1: Redirect Host(New addr: 10.0.8.2)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 12e0   0 0000  3f  01 a85d 10.0.8.2  172.16.2.90 

92 bytes from 10.0.8.1: Redirect Host(New addr: 10.0.8.2)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 12e0   0 0000  3d  01 aa5d 10.0.8.2  172.16.2.90 

92 bytes from 10.0.8.1: Redirect Host(New addr: 10.0.8.2)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 12e0   0 0000  3b  01 ac5d 10.0.8.2  172.16.2.90 

92 bytes from 10.0.8.1: Redirect Host(New addr: 10.0.8.2)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 12e0   0 0000  39  01 ae5d 10.0.8.2  172.16.2.90 
...

viragomann

@TTBruce
You have the client sides LAN 172.16.2.0/24 added to the "Local networks" on the server.
This is not gonna to work.

TTBruce

@viragomann This is what I thought as well and I did try removing it, with the same result. If you look at the guide, this is exactly what they suggest you do.

viragomann

@TTBruce
The guide describes a multi purpose server. In this setup this is needed to push the s2s clients LAN to other clients.

Does your clients LAN device even respond to access from outside of their subnet?
By default computers blocks this access.

TTBruce

@viragomann I am just trying to configure a single client now with the intention of adding more later. That said, the primary purpose is to be able to access client-side LAN devices from the server.

In order to isolate the issue, I've removed that route from the local networks and am still seeing the exact same results.

To confirm that I am able to ping from another subnet, I just set up a new shared key tunnel between the pfSense devices, and I was in fact able to ping 172.16.2.90 across the tunnel, from a different subnet.

UPDATE: I seem to have connection now. Still testing to make sure everything is working as expected, but setting the client IPv4 Tunnel network to match the server's IPv4 tunnel network seems to have resolved it. Will try adding another client pfsense to see how this works with multiple clients.