Punching a hole for 1194 (OpenVPN) with floating rules causes VPN packet errors
-
Hi, I've had my pfSense operational for over 5 years and I recently started utilizing PIA, and then yesterday tried to set up an OpenVPN server for remote access to home. I'll get to the meat of my problem here - Before spinning up the OpenVPN server, I was utilizing 2 floating rules - 1) to allow traffic out that goes to the PIA server and 2) A kill switch that deny's all other outbound traffic not going on port 25000. When I set up OpenVPN server for remote access, I had to let 1194 in and out in addition to the PIA port 25000 traffic. The issue is that this doesn't work, punching inbound/outbound holes for 1194 causes OpenVPN errors and nobody can even authenticate via VPN:
"Authenticate/Decrypt packet error: bad packet ID (may be a replay)" and "TLS Error: incoming packet authentication failed from [AF_INET]"
Now for the kicker - if I simply disable the last 3 floating rules (1194 in, 1194 out, and kill switch) everything works just fine!! Why are floating rules causing OpenVPN packet/TLS errors? What other info would be useful for troubleshooting? I'll post a screenshot of the floating rules.
Thank you for any help!
-Justin
-
Why are you setting gateways there? Don't do that.
Floating rule screen shots are pretty worthless without knowing what interface and direction the rules are on.
-
That was just a test to see if it made a difference. It does not, no matter what I do, I still get the same errors over and over. Any other ideas?
Thanks!
-
Why are you trying to block traffic both in and out of an interface… Seems pointless.. If you allow it in, by the very nature of the state it will be allowed back out.
Why are you using floating?? How many interfaces/vlans do you have?
-
Why are you trying to block traffic both in and out of an interface… Seems pointless.. If you allow it in, by the very nature of the state it will be allowed back out.
Why are you using floating?? How many interfaces/vlans do you have?
Maybe the inbound/outbound specification is redundant, but nevertheless, I still need to figure out why it is causing packet errors.
As for floating rule usage - I have to put it here because floating rules take precedence. If I don't allow 1194 before blocking all other traffic, the VPN traffic doesn't even make it in the door. And I have floating rules in the first place b/c it was the only way to implement a kill switch.
And interfaces - 3 - WAN/LAN/PIA virtual interface
-
"I have to put it here because floating rules take precedence."
huh?? precedence over what?? Why would you just not put on your wan interface to allow 1194.. You have 1 lan.. Your kill switch as you call it is just remove the default allow and put in your allow to go out the vpn gateway you setup..
There really should be nothing in your floating tab, and have ZERO reason to block on outbound on an interface..
You have your 1 rule on lan for going out your vpn, you have 1 rule on your wan to allow your 1194 inbound = done!!
-
huh?? precedence over what?? Why would you just not put on your wan interface to allow 1194.. You have 1 lan..
Per the pfsense docs on floating rules : "Floating Rules are parsed before rules on other interfaces. Thus, if a packet matches a floating rule and the Quick option is active on that rule, pfSense will not attempt to filter that packet against any rule on any other group or interface tab"
Hence my statement. And of course I want to block outbound traffic on an interface, how else would I prevent my traffic from accidentally going out over anything besides the PIA provider?
All of this conjecture is still completely orthogonal to the problem at hand - why are rules causing TLS/packet issues??
-
Ok, so I get the feeling that the kill switch functionality is being misunderstood here. The problem is that if you specify a rule that forces all traffic over the VPN interface, and that interface (VPN) goes down, pfSense will automatically find a new route despite explicit instructions to use the VPN. The pfSense documentation does say this:
"By default, when a rule has a specific gateway set and this gateway is down, a rule is created and traffic is sent to the default gateway." So the suggestion to simply create rules on the WAN is insufficient if you want to make sure that there are no traffic leaks.The good news is there is a way to make the firewall rules do what you intend ==> In System: Advanced: Miscellaneous, check Skip rules when gateway is down. That provides backup protection against leaks to WAN if the VPN connection goes down. That let me get rid of the floating rule kill switch.
The bad news is that no explanation was ever given for why the floating rules were causing VPN packet errors, but hey, I'll take what I can get. Maybe someone else can chime in on that front.
-
"And of course I want to block outbound traffic on an interface, how else would I prevent my traffic from accidentally going out over anything besides the PIA provider?"
You clearly don't understand how the rules are evaluated.
Rules are evaluated top down, first rule to trigger wins - no other rules are evaluated. On the interface that traffic enters pfsense on!!
You have a rule that sends data out your VPN, an allow statement on your lan.. If the vpn is down.. What happens?? Nothing - there is no other allow rule… So traffic killed. Why would you think you need this on the floating tab?? Just 1 rule on your lan is all you need!!
Then to allow your vpn users in, 1 rule on your WAN.. This is where the traffic first enters pfsense. So here is rule on interface that clients get out on.. Ie lan.. So traffic hits pfsense on interface - any any allowed out the VPN!! if vpn is down... What allows the traffic?? Nothing - so killed!!
There is no other allow rule, the rule says go out the vpn! If can not go out the vpn traffic is stopped there with the default deny.
-
Except that there is a feature that eliminates the gateway from rules if the gateway is down.
Much better than floating rules, in my opinion, is using the tag/tagged feature.
Search this forum for "NO_WAN_EGRESS"
-
"Except that there is a feature that eliminates the gateway from rules if the gateway is down."
So? There is no rule under it to allow anything.. If he had the default allow rule under it then sure that could be an issue.. But if your forcing everything out the vpn, then an any rule under it is pointless..
-
The point is if that feature is not disabled and the gateway is detected as down, the rule still exists but without the policy routing applied so all that VPN traffic goes to the routing table and out WAN in-the-clear. This is the default behavior.
By default, when a rule has a gateway specified and this gateway is down, the rule is created omitting the gateway. This option overrides that behavior by omitting the entire rule instead.
tagging/tagged is the best way to ensure traffic that should go over the VPN does not go out WAN.
- If it should go over the VPN tag it.
- Do not let anything out WAN with that tag.
