How to drop traffic when client VPN is down?
-
Hi, I've configured pfSense as a vpn client and am using pf policy routing to route traffic from certain LAN clients through the VPN. However, in case of VPN connection issues the clients are automatically routed through the WAN connection. I don't want this. I want to drop traffic if the VPN is unavailable. How do I achieve this?
-
Use negate rules, which is the same rule that allows the traffic but rejecting it and you change its gateway so if the gateway is not available (i.e; the tunnel) then then the traffic would match the negate rule that has no gateway and rejects/blocks the traffic.
You also have to change a couple of settings for them to work, the use autonegate rules or something like that and automatic gateway switching, if I'm not mistaken. Good luck! :)
I forgot to mention, don't apply the changes until you reorder the rules correctly or you might end up locked out. If you do, in console press the 8 number key for the shell and type "pfctl -d" which turns off temporarily the firewall, undo the changes and it'll turn itself back on the first save, or type "pfctl -e" (-d for disable, -e for enable, pf as in pfSense--or packet filter, and ctl as in control, as a mnemonic).
-
I tried following your tips but couldn't figure it out.
Then I found this page (https://www.infotechwerx.com/blog/Prevent-Any-Traffic-VPN-Hosts-Egressing-WAN) recommending to use tagging and setting a floating rule on WAN blocking all outgoing traffic with a specific tag. That did the trick.
-
I'm sorry, I should've sent a picture from the beginning, I suck at explaining things.
It looks like this:
Exact same rule as the above, except that it rejects and has no gateway selected.When the firewall is evaluating the traffic since the tunnel would be down and hence it doesn't match anymore, then the traffic would fall on the next rule, and, the next rules says sorry you can't pass.
In the picture, it's a catch all rule, which is very dangerous because it can lock you out, so you need to add yet more rules for services in the firewall (or to other local networks):
Here, rules are:- is automatically generated, it's disabled on the settings but I keep forgetting. :)
- is automatic as well, created by pfBlockerNG
- is my actual first rule, it bypasses the firewall completely. It catches all traffic from the alias def_fullchoya.
- allows traffic going to internal IP ranges (RFC1918: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16) since the interface address is 10.0.0.1, it therefore allows access to anything on the firewall and other local networks. Shouldn't be that broad though.
- allows internal DNS servers to get DNS outside of the tunnel (because it's above the tunnel rule) but in an ordered fashion, i.e; it's a gateway group that goes one by one checking what's [interface] up so DNS queries are region-matched.
- blocks all other DNS so clients are forced to get it from the servers specified though DHCP.
- allows certain hosts (alias def_fullthrottle) to use the local exit to the Internet at full speed but still use internal DNS (covered by rule 4)
- allows servers known to phone home, i.e; Microsoft products (alias bad_kiddies) to get internal DNS and communicate internally with other local hosts (covered by rule 4) but blocks them from actually communicating out.
- every other traffic goes through tunnel
- safeguard (negate) rule: if tunnel drops, traffic matches this rule rejecting traffic everywhere out. That would include local traffic if it wasn't covered by rule 4.
The way you did it is good too but that I think that would create problems if you're hosting servers as it would block or create asymmetric routing from a remote client's perspective as most VPN services don't let you do port forwarding. In other less confusing words: when you add a rule on an interface, the firewall creates on the background a temporary pass rule for the return traffic on whatever the other interface for as long as the state lives even if there's a rule that blocks the traffic. In my case rule 8.
In all honesty I'm not a hundred on if the floating rule would catch autogenerated rules passing traffic from blocking rule 8 but that's exactly what floating rules are for. They're for complex scenarios and should be avoided at all costs if you're not completely sure what you're doing -- that applies to me, at least. Filtering on the outbound also catches traffic from the firewall itself (complex scenarios) and could get you into a frustrating situation where your tunnel drops and the firewall can't get DNS to bring it up again if you didn't set it correctly.
I made this a few days ago, maybe it can help: https://forum.netgate.com/topic/146714/tunneled-isp-cheat-sheet
:)
