cant prep 2.6.0 pfsense openvpn for 2.7.0
-
p2p ssl/tls has a toplogy drop down, p2p mode is not in it,
p2p psk has NO topology drop downwhats in your p2p ssl/tls topology drop down? do you have one?
-
the client override section talks about how these work but im am not sure what were using with psk since theres no option
override settings:
Tunnel Settings
IPv4 Tunnel Network
The virtual IPv4 network or network type alias with a single entry used for private communications between this client and the server expressed using CIDR (e.g. 10.0.8.5/24).
With subnet topology, enter the client IP address and the subnet mask must match the IPv4 Tunnel Network on the server.
With net30 topology, the first network address of the /30 is assumed to be the server address and the second network address will be assigned to the client. -
it appears in 2.6.0 p2p psk mode has no topology defined at all
cat /var/etc/openvpn/client1/config.ovpn | grep top
returns nothing -
Ah, OK. Re-reading here I see what you mean.
In P2P SSL/TLS mode both subnet and /30 topology can be used. I would only choose to use subnet there.
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.
If you choose a larger subnet you need a Client Specific Override to reach any subnets behind a connected client. Adding that creates the iroutes OpenVPN needs to route that traffic to the correct client.
Steve
-
i mentioned before the gateway monitor for open vpn never updates the ip it always assumes .2 which is down with subnet mode, so you are saying id create a custom override to assign a specific ip to the client to resolve this?
-
https://community.openvpn.net/openvpn/wiki/Topology
"subnet The recommended topology for modern servers. Note that this is not the current default. Addressing is done by IP & netmask. "what is the default for p2p in openvpn2.5.4? cause i cannot get p2p ssl/tls to route traffic with dot30 or subet defined
p2p psk works fine with no topology defined
-
@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
-
changing the
setting topology to subnet and
IPv4 Tunnel Network to a /30 instead of the /24
resolved the problem thank you! -
There isn't now (nor has there been) a drop-down choice for
p2pin 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 inp2pmode. 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.
-
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
-
@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
-
No you have that backward. They are removing the
p2pstyle that uses /30 style subnets.Use /24 (or something larger than /30 at least) plus the overrides.
-
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 iptraffic 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
-
You should only need the remote networks in the CSO. The same local networks can be passed to all clients.
-
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.
-
@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!
-
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.
-
@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 .2The 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.
