VPN Group + a Kill Switch
For the last few months I've been using a pfSense custom machine.
Everything worked well until recently when I decided that using a VPN without a "Kill Switch" is almost useless.
So, I searched this forum and online and created few Floating Firewall-Rules.
It worked fine for a few days/weeks but then connectivity problems started to occur.
All I want to achieve is a VPN (gateway group of 4 VPN servers) connection, a DNS connection for VPN requests + pfSense needs and time syncs etc. + a "Kill Switch" for when the VPN is down. That's it, simple as that.
Currently it works but it's buggy.
On the rules that policy route traffic to the group of openvpn clients also set a tag.
Reject any traffic with that tag outbound on all WANs that has that tag set using outbound floating rules on the WAN interfaces. Good application for an interface group.
It works fine. Not buggy at all.
@Derelict I'm sorry but I'm new to pfSense (liking it very much). I'll try to explain my setup:
- I have set up an OpenVPN group of 4 servers. With a suggestion from NordVPN guys I unchecked "Don't pull routes".
- Marked them as Gateway Group.
- Made my entire LAN to go through this Gateway instead of the default WAN.
- Did all the neccessary outbound/General setup->Gateways/DNS Resolver stuff.
- Used Cloudflare's DNSs 126.96.36.199, 188.8.131.52 in the General Setup section.
- Created 4 Floating Rules to achieve the "Kill Switch":
(A) Allow WAN ICMP connection to my WAN-PPPOE/ISP - the dpinger went crazy in the firewall logs.
(B) Allow UDP connections to the 4 NordVPN servers I'm using (first tried 'out' direction, then 'any').
(C) Allow DNS connections (first for 'This Firewall (self)', then to 'any').
(D) Block everything else (Interface WAN, Address Family 'IPv4+6', protocol+direction+source+destination - 'any')
Q#1: Where do I find the policy route you were talking about?
Q#2: Sorry, but I don't understand what you want me to reject - My VPN group or any other WAN activity?
[Update]: After I changed Cloudflare's DNSs to NordVPN's, it seems like everything works again. Could it be that their Data Center servers deployment near me or their 184.108.40.206 DNS ing general, block requests from NordVPN servers?
I'm willing to pay just to get this thing solved lol.
I'm willing to pay just to get this thing solved lol.
I wrote all of this up a while ago here:
I decided that using a VPN without a "Kill Switch" is almost useless.
So you shrunk your tinfoil hat in the washer so it got tighter? ;)
Make sure to use cold water, if it shrinks too much you will be living in a cave off the grid tracking when the satellites are not overhead with your abacus... So you know when its safe to go outside ;)
@johnpoz Hahaha good one! Liked the sarcasm, as childish as it is. We'll tell jokes on a beer one day. Right now I need this thing solved (Networking projects, no caves around).
Configure it properly and it will work fine.
@Derelict You sound like a serious guy and your reputation here proceeds you, sir!
I've read your posts here before and used some of the ideas. Anyway...I just read what you wrote on www.infotechwerx.com and I already did most of that a while ago except for the tagging option (also, put the entire LAN net to go through the VPN Gateway).
I'll try it and write back, but why would not tagging create such DNS resolving issues? Now the issue is back even with NordVPN's DNSs, which are way slower compared to Cloudflare's BTW.
I appreciate the patience.
@Derelict Ok...I did what you said. So you wanna tell me that the only floating rule I'll need is this "Block outbound traffic marked as NO_WAN_EGRESS"? I can now delete all the other unnecessary Floating Pass rules, since the new Block rule would only block the communication coming out of the interface that meant to use only the VPN while all the other traffic would work as usual as if there was no VPN or any Block rules (including pfSense needs, time syncs etc.)?
If all of the traffic that is supposed to go out the VPN is marked, then, yes, all you have to do is block traffic with that mark out the outbound WAN.
@Derelict VERY simple! Can't believe I even bothered NordVPN support guys with this and more than that - can't believe none of them knew the answer lol. But they're awesome and very nice people.
So just to be clear and 100% sure - I marked NO_WAN_EGRESS under "Tag" in the LAN Firewall rule and the same under "Tagged" in the Floating Firewall rule. Also, deleted all the other Floating rules. That's how it should be right?
No idea from that description. It's all in that blog post.
@johnpoz You see my friend? This is how you answer the new guy (see entry: Derelict)!
Also, to address your mocking answer - Yes! As someone who served in the Intelligence Forces/Agencies I can tell you that in the future (and present) A-L-L Networks around the world (Home or Enterprise) should (and sometimes even MUST) work like that!
- Many companies and countries use cyber attacks against each other every day.
- Hackers get more and more sophisticated.
- You probably have no idea about the usages of even the simplest data collection.
Sometimes even a junior agent/soldier get access to a civilian data and even the stupidest most naive online
searches like: "Marihuana", "What is the Dark Web", "Donald Trump Speeches", "Edward Snowden", your bank accounts, your political views, taste in music and your entire online activity/life as naive and/or curious as it would be, can be used against you or even just for fun creating false flags about you, your neighbours, your political opponents etc. Even if it was an innocent online search/activity or was searched by someone else (your friends, family members etc.) with access to your mobile phone, pc, laptop etc.
Trust me, I've seen and heard it all, sometimes from a first source.
Never underestimate your privacy and security! Never! The stupidest things you never took seriously or thought about, can be used against you one day with little to no adjustments and/or fake data/human or machine interpretation mixed with your real data.
The cliche of "I have nothing to hide" that makes people unaware and not thinking about security much, well...is useless, irrelevant and even damaging these days and especially in the future.
And that, my friend, is why many people and businesses around the world ask for such a protection and hence why
I, a programmer, am also learning CCNA, Networking, VPN (OpenVPN), pfSense, "Kill Switches" etc.
@Derelict I'll try again - I gave the LAN net firewall rule the TAG NO_WAN_EGRESS and then "told" the Floating rule to block all the packets (on the WAN interface) that are TAGGED as such (NO_WAN_EGRESS). Seems ok to me I just want your final approval please :).
I don't "approve" descriptions of what you think you have done. Screen shots or /tmp/rules.debug
Does it test ok? Only you can be responsible for your own network.
Please have a look and confirm it's ok. I wanna go to sleep knowing this solution is EXACTLY what you meant lol.
mcury last edited by
You could set a NO NAT rule, from LAN to WAN, as a kill switch... or tag.. not sure what's easier
@mcury I see. Well...I don't mind what would be easier for me as much as what's "the best practice" or "most readable" or the fastest for the pfSense Firewall to execute.
Thanks for the input,
Don't "block" traffic with things like no NAT rules.
Block traffic with firewall rules that block the traffic you don't want to pass.
@Derelict Is this an answer to my last question of what's the "best practice" or are we still talking about the Kill Switch? lol. Btw, the Kill Switch(es) work like a charm! Thanks a lot!
It applies to anything. If you want to block traffic, block it. Don't use exclusions to policy routing, exclusions to NAT, or passing to everything except
!something. If you want it blocked, block it.
@Derelict If you could also answer my other (new) question here: https://forum.netgate.com/topic/147323/openvpn-the-clash-of-gateways
Thank you very much,