Site to site tunnel with shared key drops under load and won't reconnect
-
Strangest problem here.
I have a 2 boxes running pfsense 2.1.5 and openvpn peer to peer with shared key between them. It works great for all my RDP traffic, my sql log shipping and pings, but as soon as I begin transferring large backup files (~2gb) the tunnel drops and the status shows "reconnecting ping-restart" but never does it reconnect. Bizarre, right? Get this! If I delete and readd the firewall rule permitting access from the WAN, only then will the tunnel reconnect.
It's interesting to note that I have additional openvpn servers on different WAN ports for my users to connect remotely which are all working great.
I seem to recall encountering a similar problem in the past but I believe it was with an IPSEC site to site configuration.
Any reading material or advice would be greatly appreciated.
Thank you all for helping support this fine product.
-
It's funny…
After spending hours banging my head against the keyboard and unsuccessfully searching for answers, I make a post out of frustration only to somehow manage to formulate a search that leads to a likely answer.
https://forum.pfsense.org/index.php?topic=76975.0
It looks good so far but I'll reply again to this thread if it remains throughout the nightly backup. Hopefully someone else can find value in this.
-
No luck.
It turns out snort was being triggered and blocking my second site. I simply disabled the offending rule, unblocked my IP and all seems well. What's strange is that it didn't fail until significant data started being transferred through the tunnel. That was very confusing. I noticed that my client connection wasn't found in the server firewall log and after verifying with packet capture that the client was indeed sending, it dawned on me that something was eating the request. Too many hours lost due to my own foolishness.
Found on snort alerts tab (I copied this after disabling the rule):
11/27/14
09:27:06 1 UDP Potential Corporate Privacy Violation <clientwanip>Icon Reverse Resolve with DNS Add this alert to the Suppress List and track by_src IP 13467 <serverwanip>Icon Reverse Resolve with DNS Add this alert to the Suppress List and track by_dst IP 1195 1:2003320
Add this alert to the Suppress List Rule is forced to a disabled state. Click to remove the force-disable action from this rule. ET P2P Edonkey Search ResultsBeware snort users.</serverwanip></clientwanip>