OpenVPN P2P (SSL/TLS), 1 server+n clients, improper routing

kmiel · Nov 15, 2019, 4:20 PM

Hello,

Having trouble to tie together 3 sites. This is done in a lab environment by means of a proof-of-concept. Utilized the guide that can be found on https://docs.netgate.com/pfsense/en/latest/book/openvpn/site-to-site-example-configuration-ssl-tls.html. Sites B & C connect fine to site A and there is some connectivity, but not the connectivity that is expected/desired. The third site (C) is to verify multiple clients connecting to a single OpenVPN server instance and doesn't have a client (yet).

Site information:

Site A (pfSense, OpenVPN server)

LAN = 172.16.98.0/24
Gateway IP = 172.16.98.1
Client IP = 172.16.98.10
Tunnel IP = 172.16.160.1

Site B (Fedora, OpenVPN client)

LAN = 172.16.50.0/24
Gateway IP = 172.16.50.1
Client IP = 172.16.50.2
Tunnel IP = 172.16.160.3

Site C (CentOS, OpenVPN Client)

LAN = 172.16.52.0/24
Gateway IP = 172.16.52.1
Tunnel IP = 172.16.160.2

IPv4 Tunnel Network = 172.16.160.0/24

The gateways in site B & C and the clients in sites A & B don't have local firewalls enabled.

This basically wraps up my testing:

Gateway in site A (172.16.98.1) can not ping gateway in site B (172.16.50.1).
Gateway in site A (172.16.98.1) can not ping gateway in site C (172.16.52.1).
Gateway in site B (172.16.50.1) can ping gateway in site A (172.16.98.1).
Gateway in site B (172.16.50.1) can not ping gateway in site C (172.16.52.1).
Gateway in site C (172.16.52.1) can ping gateway in site A (172.16.98.1).
Gateway in site C (172.16.52.1) can not ping gateway in site B (172.16.50.1).
Client in site A (172.16.98.10) can ping gateway in site A (172.16.98.1).
Client in site A (172.16.98.10) can not ping gateway in site B (172.16.50.1).
Client in site A (172.16.98.10) can not ping gateway in site C (172.16.52.1).
Client in site B (172.16.50.2) can not ping gateway in site A (172.16.98.1).
Client in site B (172.16.50.2) can ping gateway in site B (172.16.50.1).
Client in site B (172.16.50.2) can not ping gateway in site C (172.16.52.1).
Client in site A (172.16.98.10) can not ping client in site B (172.16.50.2).
Client in site B (172.16.50.2) can not ping client in site A (172.16.98.10).
Gateway in site A (172.16.98.1) can ping client in site A (172.16.98.10).
Gateway in site A (172.16.98.1) can not ping client in site B (172.16.50.2).
Gateway in site B (172.16.50.1) can ping client in site A (172.16.98.10).
Gateway in site B (172.16.50.1) can ping client in site B (172.16.50.2).
Gateway in site C (172.16.52.1) can ping client in site A (172.16.98.10).
Gateway in site C (172.16.52.1) can not ping client in site B (172.16.50.2).
Client in site A (172.16.98.10) can ping IPv4 Tunnel Network IP's; 172.16.160.1, 172.16.160.2 & 172.16.160.3
Client in site B (172.16.98.10) can ping IPv4 Tunnel Network IP 172.16.160.3, but not 172.16.160.1 & 172.16.160.2
Gateway in site A (172.16.98.1) can ping IPv4 Tunnel Network IP's; 172.16.160.1, 172.16.160.2 & 172.16.160.3
Gateway in site B (172.16.50.1) can ping IPv4 Tunnel Network IP's; 172.16.160.1, 172.16.160.2 & 172.16.160.3
Gateway in site C (172.16.52.1) can ping IPv4 Tunnel Network IP's; 172.16.160.1, 172.16.160.2 & 172.16.160.3

pfSense OpenVPN server screenshots

Snippet of OpenVPN server entry:

Snippets of client specific overrides entries:
Site B

Site C

Firewall rules:

Attached are the OpenVPN config files for sites B & C:
site-b.txt
site-c.txt

If any information lacks, please let me know. Looking forward to your expert responses.

Many thanks in advance.

kmiel · Nov 17, 2019, 12:15 PM

The Remote IPv4 networks were also defined in 2 other OpenVPN server definitions. While the tunnels not being active, it does seem to create routes for it. In the end this seems pretty logical, but was unexpected while doing the configuration. I was under the impression that the routes would only be set upon actual OpenVPN connection.

Changing the subnets, eliminating overlap (wether connected or not), did the trick.

"Duh".