cant prep 2.6.0 pfsense openvpn for 2.7.0

jsone

@stephenw10 said in cant prep 2.6.0 pfsense openvpn for 2.7.0:

If you choose subnet and then set a subnet size of /30 there can be only one client so all traffic is routed to it in the same way P2P PSK is configured.

gotcha

jsone

changing the
setting topology to subnet and
IPv4 Tunnel Network to a /30 instead of the /24
resolved the problem thank you!

jimp

There isn't now (nor has there been) a drop-down choice for p2p in topology, it determines that automatically based on the tunnel network size. If you use /30 for the tunnel network it uses configuration options which end up triggering OpenVPN to behave in p2p mode. It's all described in the docs (https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configure-server-tunnel.html#ipv4-ipv6-tunnel-network)

That said, that also isn't a good migration path as OpenVPN is also doing away with that mode. We found out when working on DCO and hitting issues with that style of connection that OpenVPN upstream has pretty much abandoned that code path and it's likely to go away when they remove static key.

tl;dr: If you want to ensure forward compatibility, follow the recipe I linked and use a full SSL/TLS server setup with overrides and so on, don't deviate from that. Even if you only have one client.

stephenw10

In subnet mode the server always shows .2 as gateway. Even if there's a client at .2.

That is used only to route traffic to the OpenVPN daemon. Once there it uses the iroutes to send traffic to the correct client.

In P2P PSK mode there can be only one client so it's doesn't need a topology set. All traffic is always sent to that client.

Steve

jsone

@jimp said in cant prep 2.6.0 pfsense openvpn for 2.7.0:

That said, that also isn't a good migration path as OpenVPN is also doing away with that mode. We found out when working on DCO and hitting issues with that style of connection that OpenVPN upstream has pretty much abandoned that code path and it's likely to go away when they remove static key.

completely agree, the right answer is changing our /24 subnets from yester-year with no topology, to /30 with subnet topology mode

jimp

No you have that backward. They are removing the p2p style that uses /30 style subnets.

Use /24 (or something larger than /30 at least) plus the overrides.

jsone

ok i think im following, while /30 works now it wont once they drop p2p mode

i changed the server to subnet mode with a local network of .0/24
i then added a client specific override for IPv4 Tunnel Network to .2/24 and it gets .2 for a client ip

traffic would not flow until i also copied over/duplicated both IPv4 Local Network/s and IPv4 Remote Network/s to the client override from the server IPv4 Local Network/s and IPv4 Remote Network/s

stephenw10

You should only need the remote networks in the CSO. The same local networks can be passed to all clients.

jimp

You don't need to manually assign a tunnel network in the overrides, too. It can all work completely dynamic so long as you have the correct local and remote networks filled in.

jsone

@jimp said in cant prep 2.6.0 pfsense openvpn for 2.7.0:

You don't need to manually assign a tunnel network in the overrides

for some bizar reason, it was (sometimes) assigning the client .5 or .6 so i had to use the tunnel network in the client override to force it to .2

looks like everything is working great now, thanks for getting me sorted out!

stephenw10

Nice!

If you want the client to always be .2 (or any specific IP) you can assign it there. But you should be able to leave it all dynamic. Since you only have one client I would expect it to always be .2 but it should work as any IP in the subnet as long as the server knows which it is.

jimp

@jsone said in cant prep 2.6.0 pfsense openvpn for 2.7.0:

@jimp said in cant prep 2.6.0 pfsense openvpn for 2.7.0:

You don't need to manually assign a tunnel network in the overrides
for some bizar reason, it was (sometimes) assigning the client .5 or .6 so i had to use the tunnel network in the client override to force it to .2

The beauty of keeping the CSO entries generic is you don't have to know or care what address clients get. It doesn't matter. The server knows the client by its cert CN/username and will route things appropriately.