2.0-RC2 broke p2p_tls OpenVPN?
-
I have a p2p_tls OpenVPN configured between two boxes running pfsense. The server has been gradually upgraded from -BETA4 all the way to -RC1; the client has been at -BETA4 for longer but just upgraded to -RC2. Everything still works fine.
We copied the configuration to a new server running -RC2, and it refused to allow the /30 network with the p2p_tls vpn; it said that it requires at least a /29. When we tried with the /29, the server seemed to think that it was .1 and the client was .2, but then when it pushed the route and configuration to the client, the client got .3 and thought the server was .4, so the routing did not work: the client added a route to .4, which the server just routed right back to the tunnel because it was inside the /29.
What was the purpose of this change? It broke a long-working configuration for me.
If it can't be reverted, can we get another p2p_tls_actually_p2p configuration that doesn't add the "server" line to the config file so we can go back to using the /30?
Alternately, is there any documentation on why the /29 is required, and how to get OpenVPN to push addresses and routes properly when using a /29 for tls_p2p?
Thanks,
Bill -
Can you please paste the old openvpn config and point to the issues with it so it can be easily visible what you mean here?
-
Just dropping a note here that we have been discussing this on the ticket system:
http://redmine.pfsense.org/issues/1417 -
I made a commit that will be in the next snapshot that tries to be a little more intelligent about this. If the subnet mask for the tunnel network is 30+, it will not add the server/client-config-dir directives, which should restore the old behavior for people expecting the "old" behavior from before the commit that fixed the issues others had.
