I believe so yes. There's a "serial" version of the OPNSense image for exactly this purpose I believe, so you can set it up without ever having to attach a monitor.
** The pfSense Users Thread **
- Thread starter Oh Ed not again.
- Start date
I believe so yes. There's a "serial" version of the OPNSense image for exactly this purpose I believe, so you can set it up without ever having to attach a monitor.
Following on from the Netgate WireGuard fiasco, OPNSense have released their latest version which includes wireguard-kmod. This now gives them in-kernel WireGuard for the best speed and security, and they're keen to stress that the module is the one written by Jason Donenfeld, not the Netgate one... 
Some brief details here.
Some brief details here.Got a weird issue setting up this new Qotom box and not sure if it's pfSense, the hardware or even my machine but thought I'd start here.
Just playing around right now so just have the LAN interface on the pfSense box connected to my local network with valid fixed IP (192.168.0.250/24).
This works fine and I can get to the web interface and play around.
However I just tried connecting it directly to my PC.
Gave my PC a fixed IP on the same subnet (as there's no DHCP server running on pfSense yet).
When I do this, I can ping the pfSense IP of 192.168.0.250 but only very briefly after plugging the patch cable in.
I plug it in, run the ping straight away and I'll get one or maybe two replied then it goes dead. The web interface is the same, will start loading assets then timeout.
What on earth?! I'm baffled by this.
I've obviously tried different patch cables. I even thought perhaps there was an incompatibility issue between my PC's NIC and the Qotom box so I stuck a switch in between them - exactly the same result.
Anyone got any ideas? Never seen anything like it.
Just playing around right now so just have the LAN interface on the pfSense box connected to my local network with valid fixed IP (192.168.0.250/24).
This works fine and I can get to the web interface and play around.
However I just tried connecting it directly to my PC.
Gave my PC a fixed IP on the same subnet (as there's no DHCP server running on pfSense yet).
When I do this, I can ping the pfSense IP of 192.168.0.250 but only very briefly after plugging the patch cable in.
I plug it in, run the ping straight away and I'll get one or maybe two replied then it goes dead. The web interface is the same, will start loading assets then timeout.
What on earth?! I'm baffled by this.
I've obviously tried different patch cables. I even thought perhaps there was an incompatibility issue between my PC's NIC and the Qotom box so I stuck a switch in between them - exactly the same result.
Anyone got any ideas? Never seen anything like it.
Apparently the 3rd hardware revision will fix it... like apparently the 2nd version was supposed to.
Can anyone offer advice on the best way of configuring pfBlocker GeoIP on inbound connections?
I see their recommendation not to "block the world", by which I assume they mean permit the locations you do want rather than blocking all those you don't.
So I'd assume, if I want to only allow inbound traffic from the UK, in the Europe section I'd only select the UK and set the action to "Permit Inbound", correct?
If so then how would I deal with those continents/sections that I want to block entirely - should I also set these to "Permit Inbound" but then not select any countries from the list?
Any advice appreciated as I've not used pfBlocker before.
I see their recommendation not to "block the world", by which I assume they mean permit the locations you do want rather than blocking all those you don't.
So I'd assume, if I want to only allow inbound traffic from the UK, in the Europe section I'd only select the UK and set the action to "Permit Inbound", correct?
If so then how would I deal with those continents/sections that I want to block entirely - should I also set these to "Permit Inbound" but then not select any countries from the list?
Any advice appreciated as I've not used pfBlocker before.
Associate
As Caged says, unless you have some inbound services exposed or a torrent client/other application using UPNP (which should be off anyway really) - then geo blocking isn't much use. That said, I block China, Russia, Japan, Ukraine, Brazil, Poland, Vietnam, Argentina, Columbia, Mexico and Chile - rest are unblocked.
It's a good job we live in a world where criminals are so incompetent that they haven't worked out how to create thousands of fraudulent VPN accounts per day using stolen card data or rent servers/use compromised boxes in parts of the world you don't block as a proxy. I mean can you imagine if the people doing this kind of thing for a living, who have a vested interest in not being caught/discovered had even the most basic grasp of how the internet worked? Yea... it's literally that effective that your average teenager has a long enough attention span to work out how to defeat a geo-blocking policy.
Geo-blocking, is largely pointless at this stage, it's also not unheard of for an ISP to purchase a block from other parts of the world and forget to update the database throwing default language/location data out for it's customers and then take years (and counting) to fix it as they just DGAF, we've had several threads about just that happening over the years.
Geo-blocking, is largely pointless at this stage, it's also not unheard of for an ISP to purchase a block from other parts of the world and forget to update the database throwing default language/location data out for it's customers and then take years (and counting) to fix it as they just DGAF, we've had several threads about just that happening over the years.
I do have a few inbound services, some only for my own use but others, such as my Plex server, are accessible by select others.
I'm thus looking at the GeoIP blocking to restrict access to only the countries where those others reside.
Just wondering what the best way to go about it is, in terms of actual configuration.
I can still see the value in it. You're right that in the case of a targeted attack people can work around something trivial like that, and it shouldn't be seen as a way of exposing RDP ports to the world and considering them safe, but if you have staff based in countries that you know about and you still use client VPN for remote access to certain things, then it's not the worst idea to only allow those connections to come in from the countries that you're actually operating in.
Until everything can be a SaaS application working off a zero-trust model there's going to be a place for the less than ideal stop-gap solutions.
Associate
1. Sign up for a free maxmind key and record it.
2. Install pfBlockerNG plugin in pfsense GUI
3. Goto firewall > pfBlockerNG and enter maxmind key halfway down.
4. Make sure inbound is set to WAN, outbound to LAN (or more), click Save at the bottom.
5. Click GeoIP > Top 20. Select whatever suits you, click Save at the bottom.
6. Click Update > set to reload and click Run underneath the box will fill with text as it updates.
7. Add pfBlockerNG widget to pfsense home screen.
Use your internet connection as normal, just watch out for anything that wont connect etc and check the firewall logs etc.
That example and facts in play are on pretty opposite ends of the spectrum. User is running Plex behind a Quotom box from China with near zero hardware support, it seems unlikely - though not impossible - that they have a diverse range of remote VPN users that they need to geo-restrict, but even if they did, while its not the worst idea ever, thats a long way from being a good one.
Last edited:
Ok still trying to work out the best way of configuring GeoIP stuff. Trying to do it the recommended way of whitelisting where you want rather than blocking everywhere you don't.
I've created a custom alias called "MyCountries" which contains only the GeoIP countries I want to accept traffic from to my exposed ports/services.
What I can't figure out is how I use that in conjunction with my NAT forwarding rules.
Take Plex as an example and say I already have a NAT forwarding rule configured to forward inbound traffic on port 32400 to my Plex server. (In reality I don't, I use a different external port to further obfuscate).
This NAT rule creates an associated WAN rule to allow the traffic.
I can easily create a new WAN rule that allows inbound traffic to port 32400 with the Source as "pfB_MyCountries_v4" which will match any source in my whitelist of countries.
The issue is that this is pointless as, when it fails to match traffic from non-whitelisted countries, the NAT-created rule will match the traffic anyway and allow it through.
I initially thought that maybe I needed to add the "pfB_MyCountries_v4" alias to the generated NAT rule to further restrict permitted traffic by location but this isn't allowed as the rule is managed by the NAT forwarding, which makes sense.
What am I missing here?
Is the solution to "invert" the WAN rule I've created so it blocks all traffic that doesn't match my whitelist? That's the only real option I can see.
I've created a custom alias called "MyCountries" which contains only the GeoIP countries I want to accept traffic from to my exposed ports/services.
What I can't figure out is how I use that in conjunction with my NAT forwarding rules.
Take Plex as an example and say I already have a NAT forwarding rule configured to forward inbound traffic on port 32400 to my Plex server. (In reality I don't, I use a different external port to further obfuscate).
This NAT rule creates an associated WAN rule to allow the traffic.
I can easily create a new WAN rule that allows inbound traffic to port 32400 with the Source as "pfB_MyCountries_v4" which will match any source in my whitelist of countries.
The issue is that this is pointless as, when it fails to match traffic from non-whitelisted countries, the NAT-created rule will match the traffic anyway and allow it through.
I initially thought that maybe I needed to add the "pfB_MyCountries_v4" alias to the generated NAT rule to further restrict permitted traffic by location but this isn't allowed as the rule is managed by the NAT forwarding, which makes sense.
What am I missing here?
Is the solution to "invert" the WAN rule I've created so it blocks all traffic that doesn't match my whitelist? That's the only real option I can see.
I always split rules up so that NAT and firewall rules are handled separately - coming from big firewalls it has always made more sense to me to do things this way, to the extent that it can take me quite a while to get my head around the concept of 'port forwarding' as presented by the average home router.
Do you mean NOT allowing pfSense to automatically create the associated WAN rule when configuring NAT (which I presume is possible by setting "Filter rule association" to None) and then creating the WAN rules manually yourself?
If so then yes I can see the value of that.
Think I've sussed it now. As @Caged says, stop it creating the associated WAN rule automatically then create it manually, where I can then add my country whitelist alias to the source side of it.
This way I'm whitelisting the few GeoIP locations I want to accept, rather than "blocking the world" as they put it, and only on the few ports that I'm allowing through which should avoid any unnecessary processing.
Don't know if it actually works yet as I'm not running the firewall live just yet
This way I'm whitelisting the few GeoIP locations I want to accept, rather than "blocking the world" as they put it, and only on the few ports that I'm allowing through which should avoid any unnecessary processing.
Don't know if it actually works yet as I'm not running the firewall live just yet
Yes I get full 10gig speed on file transfers between PC and server on Iperf3 and file transfer (assuming the files are on my SSD array, otherwise my spinning storage is the bottleneck).
I'm not sure what you mean regarding NAT though or if that applies to my setup??
Nice to hear you're getting good throughput. While I'm not Cyber-Mav, Network Address Translation (NAT) is highly likely something you're using (in *Sense or anything else). Unless you have a public IP for every machine on your network, you're doing NAT. There's Source NAT (SNAT) and Destination NAT (DNAT). As the names might imply, SNAT changes the source of an IP packet and DNAT changes the destination. For example, SNAT allows your private IP range to connect to the wider Internet behind a single public IP. Conversely, DNAT is more commonly known due to 'port forwarding' - that is, changing the destination of a packet from your public WAN IP to a private IP inside the LAN that's actually running the server. This costs overhead, and once you get to muti-gig (especially 20/40/100 Gbps) NAT is a huge bottleneck.
Last edited:
Well my new box is live as of yesterday and looking good.
I think I've sussed the pfBlocker stuff as described above. Have created an alias with only the countries I want to allow access and have set that as the source on each of my WAN rules.
That way the ports I've opened for access are restricted to only the countries I want.
Whilst I could have added a single rule at the top of my WAN list to block all connections from countries other than my allowed list, this would then be processed for every single inbound connection which is an undesirable overhead. Doing it this way means it only bothers with GeoIP checking for traffic directed to the few ports I have opened.
One little side-effect I've noticed with Plex is that the Remote Access page in settings says that it's unavailable, even though it actually works. I'm assuming this is because they're testing from a US-based server which my firewall won't allow
I think I've sussed the pfBlocker stuff as described above. Have created an alias with only the countries I want to allow access and have set that as the source on each of my WAN rules.
That way the ports I've opened for access are restricted to only the countries I want.
Whilst I could have added a single rule at the top of my WAN list to block all connections from countries other than my allowed list, this would then be processed for every single inbound connection which is an undesirable overhead. Doing it this way means it only bothers with GeoIP checking for traffic directed to the few ports I have opened.
One little side-effect I've noticed with Plex is that the Remote Access page in settings says that it's unavailable, even though it actually works. I'm assuming this is because they're testing from a US-based server which my firewall won't allow