Regression #14268
closed
OpenVPN client fails to start when a tunnel network is specified
0%
Description
Tested on pfSense+ 23.01/23.05dev with and without DCO.
With non-DCO, the logs show that it fails to configure the interface:
Apr 10 16:08:53 openvpn 12048 FreeBSD ifconfig failed: external program exited with error status: 1 Apr 10 16:08:53 openvpn 12048 Exiting due to fatal error
This leads to OpenVPN clients not working after upgrading from 22.05 (where it previously worked).
Issue can be worked around by removing the tunnel network from the client configuration on the firewall.
Related issues
Updated by Jim Pingle about 1 year ago
- Status changed from New to Feedback
Are you certain that setup needs a tunnel network in the client? We have seen cases like #13350 where it was set improperly and that led to a different error, though it did work in the past.
You rarely if ever need a tunnel network on the client with SSL/TLS as it would pull the address from the server. I assume it's SSL/TLS since you mentioned DCO.
Using a TN on a client is primarily for shared key style setups where both sides are hardcoded to an address in a /30. That can still be done but it's also not compatible with DCO. OpenVPN is deprecating that, however, so it's possible it was broken upstream somehow.
Updated by Jim Pingle about 1 year ago
- Related to Regression #13350: SSL/TLS OpenVPN Client fails with ``ifconfig`` error when the IPv4 Tunnel Network is defined added
Updated by Marcos M about 1 year ago
I have not seen a case yet where the tunnel network needed to be specified. Regarding #13350, that's the error I get when using DCO. Feel free to modify the issue report(s) as needed.
Ultimately I don't think a tunnel network should be specified in these cases, but given that it's worked in the past, it warrants investigating in case there's a bug. At the very least, the upgrade should remove the tunnel network value if it's not meant to work.
Updated by Jim Pingle about 1 year ago
- Status changed from Feedback to Duplicate
We can count this one a duplicate since it appears to be the same root issue.
I still haven't seen a good way to know for sure when the address is unnecessary because it depends on the server, and we don't really know what the server wants until it connects.
I haven't dug into it that deeply yet, though.