OpenVPN
2.6.0: TLS key nego failure solved by waiting/trying again
Describe the bug I have a pfsense box that opens two (client) openvpn connections to a FreeBSD server, one over IPv4 and the other over IPv6. Frequently when rebooting I find one tunnel will fail to come up with repeated "TLS Error: TLS key negotiation failed to occur within 60 seconds" errors. The only resolution I've found is to stop openvpn on both sides for a few hours and retry. This usually works.
To Reproduce Here are the configs:
Expected behavior I think my config is ok given these tunnels stay up for weeks at a time and when I hit the failure mode I'm able to resolve it without changing any config. Here are some logs:
Version information (please complete the following information):
- OS: pfsense 23.01/14.0-CURRENT (client), FreeBSD 13.1-RELEASE-p7 (server)
- OpenVPN: 2.6.0_13 (client), version: 2.6.0 (server)
Additional context Turning verb up to 3 on the server side gives a clue:
GET INST BY VIRT: 10.9.0.5 [failed]
10.9.0.5 is the address of the client side of the tunnel. Which I assume is not reachable until the tunnel is actually up.
Can you provide a client log with higher verbosity?
GET INST BY VIRT: 10.9.0.5 [failed] is a red herring. We need to adjust that message but that is expected.
Feb 22 16:56:13 fun.example.net openvpn_xxx[5516]: Connection Attempt Reset packet from client, sending HMAC based reset challenge
The server is correctly sending a reply to the client's connection attempts. But the client log seems to be only at verb 1, so no idea what is going on there.
It might be also helpful to have a tcpdump on both sides when this failure is occuring to understand what is happening.
Yeah looks like pfsense defaults to verb 1.
(When I said the server was verb 3, it was probably actually 11.)
What would level would you like for the client? Is 3 high enough?
yes 3 or 4 are still okay for normal running. After that you get a lot of spam in your log.