pfblocker not working over OpenVPN
-
Hi all,
I have a successfully operating OpenVPN server running on my pfsense, as well as a successfully operating pfBlockerNG package. My issue is that pfBlocker does not work for traffic conencted via the VPN (confirmed via dig/nslookup). The auto-generated floating rule is assigned to the OpenVPN interface, so I would expect it to work. Any ideas what might be happening?
Thank you! :)
-
@theskelly I ended up solving this myself. The source of the issue is the use of the auto-generated floating rules. By unchecking the 'floating rules' option in the IP config page of pfblocker, rules are generated for each interface individually, and now work as expected.
-
Sorry to kind of hijack your post, but really appreciate if you can help me on this one...
I just got my OpenVPN setup and found that the GeoIP within pfblockerNG is blocking the incoming UDP traffic to port 1194 (OpenVPN).
Did you come across this issue before? And how to solve it, please?I tried to create an "allow" rule and placed it at the top of Floating rules still doesn't do the trick.
192.168.0.254 is the WAN IP of my pfSense box, I have a router (192.168.0.1) connecting to my ISP above it on subnet 192.168.0.0/24, and 192.168.1.0/24 is the NATed subnet for my pfSense's WAN network, but I dun think that has any effects to the issue here.
-
This post is deleted! -
Your WAN interface : does it have a RFC1918 like 192.168.10.0/24 ?
Rephrased : do you have a router in front of your pfSense, or a modem ?@chrisling said in pfblocker not working over OpenVPN:
OpenVPN setup
I don't know what you mean by that.
I presume you talk about an OpenVPN server - or is it an OpenVPN client setup ?More general : its useless to have all these "Floating" pfBlocker rules that will apply to the WAN, as the unique and only default WAN firewall rule is : block everything.
and you don't what to here the Internet background noise, so you do want to log this rule.So you un check : Status > System Logs > Settings
Its useless to have make a firewall block entry in the logs mentionning some "Asian" guy (that is : probably Asian, GeoIP is BS these days) tried to access your pfSense. There a billions of them ? Your log will explode every day. Just have all these these Floating pfBlocker rules removed.
You should have a first OpenVPN server firewall pass rule at the top. Make it log will you're in the OpenVPN debugging phase.
And while your at it, make your own final (bottom), explicit "block all" rule - do not make it log.
Like :
the red-barred rules are needed because I have some Internet based servers that should access local LAN based devices. These are part of my NAT rules.
This example shows the first line, and the last line. Nothing more is needed on WAN.
"Asian" devices will hit the wall. Theirs, their "PC comity firewall", or my pfSense block all rule. -
@gertjan Thanks for your reply.
I have the following setup:
ISP modem --> Netgear wifi router R7000 --> pfSense WAN --> LAN (homelab) | OPT1 (home wireless network)The top layer R7000 is taking the (mostly static) public IP address assigned by my ISP, and then the pfSense WAN is on a RFC1918 compliance network space, i.e. 192.168.0.0/24, same local network with R7000.
I am running some web services demos from time to time on my homelab (pfSense LAN) so I do need to open some ports like 80, 8080, 443, etc. on LAN subnet.
I learned about pfBlockerNG from Lawrence Systems Tutorial: pfsense and pfBlockerNG Version 3, and just followed the floating rules configuration.
I don't know much about how effective GeoIP is these days, as I'm also new to the game and just trying things out.
From what you are saying, GeoIP effectiveness aside, shall I do what @TheSkelly did above, i.e. unchecking the floating rules, so that they will be on both my LAN and OPT1 networks such that I can block all and just have the top and bottom line rules on WAN?
-
@chrisling said in pfblocker not working over OpenVPN:
I have the following setup:
ISP modem --> Netgear wifi router R7000 --> pfSense WAN --> LAN (homelab) | OPT1 (home wireless network)
The top layer R7000 is taking the (mostly static) public IP address assigned by my ISP, and then the pfSense WAN is on a RFC1918 compliance network space, i.e. 192.168.0.0/24, same local network with R7000.
I am running some web services demos from time to time on my homelab (pfSense LAN) so I do need to open some ports like 80, 8080, 443, etc. on LAN subnet.You have a router after router set-up.
Tis means that NAT rules on pfSense have to be repeated on the upstream Netgate router.
Doing so will permit you to add as many routers as you want before your pfSense, but you have sync the NAT rules on all the routers.I'm sure Lawrence (I'll ask) did said somewhere :
For home setups, by far, prefer a "something" as a modem device connected to your pfSense. Do not keep a router after router setup ** It works, but is tedious to maintain. And you have to understand that you have to build the chain of NAT rules in all your outer devices. Pretty ok if you want to amuse yourself. Not if you can't make these NAT rules "with your eyes closed".Also : you have a router before your router, so incoming WAN traffic on pfSense can only be traffic that is using ports 80 and any port you've NATted on your upstream Netgear. if you don't want that "Asian" IP's visit your site, you could use the pfBlockerNG blocking rules on your WAN interface (or on the floating tab, and make them work on WAN).
In that case, put your web server NAT rules and your VPN rule after the WAN floating rules .... (but I don't know if floating rules take precedence here.... to be checked).
@chrisling said in pfblocker not working over OpenVPN:
I don't know much about how effective GeoIP is these days, as I'm also new to the game and just trying things out.
I won't say its worthless. it might work.
False positives might exist. Can't tell.I have a dedicated server somewhere in France, in a big data centre.
It's a simple setup : a power cord, a mother board with the usal stuff, a hard disk, and a Ethernet connector. No screen, no keyboard - I never saw my own server as I don't have physical access to it (you pay but have no visit rights ...).
I use a classic OS : Debian. A classic web server : Apache2. 6 IPv4 and a couple of domains. Some web sites (company and private). A mail server for my domains. The classic DNS domain name server bind. As said : as vanilla as it gets.
No firewall.
Everybody on planet earth can visit my server.
This works just fine since last century (21 years now ...).Important to know is that my server is being (physically) maintained, 24/24 and 7/7.
And the data centre owner, one of the biggest in the world, uses special routers that can detect and negate DDOS hassle. Something you can never do @home. Worse ; you host a server @home and you get DOSSsed ? Your ISP pulls the plug - or throws YOU out.My dedicated web server has a 1 Gbyte / sec connection guaranteed, so for a couple of simple Wordpress sites it's doing close to nothing. If needed, it can do much more.
And it's protected for the - what i think - the real dangers.
"Asian" IP's are not the real danger (IMHO). I tend to say :"they" made you believe that.
Russian ? => lol. They are not interested in me. I've no valuable data on my server, like loads of mail addresses, or credit card info, or forums loaded with Kevins and other trolools.
Start Youtube, and do some, as they call it now : fact checking. Take an afternoon to see who hacks who with what, and what the hacker did to the victim when he found out - the hacker was using what ? Never use one Youtube video as the truth : see it as a person's opinion. Add them all up, divide by the number of them and try to found the common central point. Now you're aligned to a point that might be true. Now apply the what if phase, and keep this phase up until the end (take this literally).
Stay away from the adds. They make you think you can buy security. You can't. You have to make it yourself. Its more a state of mind, I guess.Example :
You and I are today capable of writing a FY letter, and put it in an envelop, addresses it, put a stamp on it and send it by old fashioned mail to some guy.
The guy receives your letter and can not see where it came from.
Even if he calls in a boat load of laboratories and experts. It's as simple as that.
So : yes, Europeans and Amercans will say that the hackers are Russian, Chinese or Tjech. They - the last 3 - are saying its us. And later - if you find out - that is was the son of the jealous neighbour with some stupid hack-script (the kid learned how to type 'make').
Remember the movie from the eighties where the kid typed : "can you play a game" on a terminal ?
Years later, the reality was worse. NORAD wasn't playing - it was a 'ordinary' training simulation. But the missile launch facility agents (in the US) went into isolation mode, opened their red books, and prepared themselves for the final phase.
Because some one (at NORAD ?) forgot to shut down the simulation.What I want to say, in short : It's the human factor. Its the fault of everybody,start by me (you, etc).
@chrisling said in pfblocker not working over OpenVPN:
i.e. unchecking the floating rules, so that they will be on both my LAN and OPT1 networks such that I can block all and just have the top and bottom line rules on WAN?
Yep. This will populate more rules pfB over all your interfaces, but helps you somewhat to get a nice overview. You can see what happens where when. As soon as everything is set up and tested on your pfSense, you can take advantage of the real strong point of pfSense : let it running by itself so you can do other things ;)
(but keep in mind : pfSense is a giant baby : keep an eye on it, as it is maintained by this stupid guy, like me - and now you ^^).edit : .... wow, sorry, being to the point doesn't always work out for me.
But hey, I'm only human ;)
