Peer to Peer (SSL/TLS) connection going into limbo
-
We have 8 separate site to site OpenVPN links between the HQ whitebox running pfsense+ 22.05 and a bunch of SG-1100s, based at various home offices across the UK, all now running pfsense+ 23.01.
These site2site links provide the home offices mainly with connectivity to the Avaya IP Office control unit for their desk IP phones. Not much other traffic goes through the tunnel.
Since the switch to the SSL/TLS method from the previously used shared key, I started noticing a problem with the server (HQ) end of the tunnel going into a limbo state, if the client end disconnects however briefly from internet.
When this occurs, the server end of the OpenVPN tunnel reports "Waiting for response from peer"
When this happens the IP phone on the client / home office end loses dial tone and if it gets rebooted, it does not finish the boot sequence properly.
This can only be resolved on the server end, by restarting the misbehaving OpenVPN service from the Status screen.
After the status will say "Adding routes to system" for a bit and then go to "Connected (Success)." This then allows the IP phone to be rebooted properly and continue functioning.
Suffice to say I have the Service Watchdog running on both ends of all separate tunnels. But it does not look like the service actually terminates. It just hangs.
-
Anyone? I'm sure we aren't the only ones experiencing it and I find it a serious enough problem to deserve a deep dive.
By the way, I'm sure this problem was present in a similar form even before I upgraded our HQ machine to pfsense+. The "Waiting for response from peer" would occasionaly show on the HQ side of various tunnels but the connection has never gone stale the way it does now.
It's definitely something to do with the TLS authentication mechanism, because it was never an issue with the preshared key tunnels.
-
Update:
It's happened again on the site2site link between the HQ and one of the SG-1100s
Towards the top of the log I restarted the OVPN service on the HQ side which had fixed it.
-
<rant>
This sad story of TLS auth problems is now reaching its conclusion in form of me abandoning OpenVPN site to site tunnels in favour of IPsec with mutual PSK. (After about five years of beutiful friendship
)Mind you when OpenVPN still officially supported the PSK method it worked absolutely fine.
The routing is now actually much simpler with IPsec and it requires almost no FW rule creation as it's done automatically.
I am just surprised and a little dismayed by the fact that this issue isn't affecting anybody else.
Was I the last person in the world using the site 2 site OpenVPN tunnels?
</rant>
-
@morgenstern looking at your OpenVPN logs and google searching â openvpn tls keys out of syncâ I see fixesâŚ.have you tried any of them?
Regardless imo I would stick with IPsec anyway because of the speed and simplicity of it. -
@michmoor Thanks, yeah I'l probably do that.
-
@morgenstern Only thing that worries me is if it's possible that the IPsec psk authentication will eventually get deprecated by Netgate the same way it has been done with OpenVPN?
-
@morgenstern This isnât a Netgate thing itâs how the package is maintained and developed. OpenVPN has deprecated shared keys.
IPsec psk is part of the standard and I have seen no RFC that hints at deprecation. -
@michmoor Cool, thanks for clarifying that
