I have followed these two videos, “Basic Setup and Configuring pfsense Firewall Rules For Home” and " Tutorial: pfsense and pfBlockerNG Version 3", and have recently created an “internet-only” Wifi VLAN similar to the NSFW_LAN in the first video. The purpose of doing thing is to put some smart-devices on this wifi network so that they can access the internet, but nothing else. Everything seems to work fine so far, with one exception in pfBlockerNG.
In testing, I noticed that when a device in the internet-only VLAN accesses a web site, it will begin to generate firewall messages to the effect of “internet-only-lan Block access to Firewall Admin Ports from deviceIP to 10.10.10.1:443”. Now, 10.10.10.1 is the default pfBlocker virtual-ip for when it blocks a website. So, pfblocker is blocking things on the internet-only VLAN, which is fine, but the rule (from that first video) preventing that VLAN from accessing the firewall GUI is ending up blocking access to pfblocker’s “we blocked this site” page. I’m guessing that’s because that 10.10.10.1 virtual-ip ends up being the ip-address of the pfSense firewall. I’m at a loss of how to correct this.
Now, in setting up my pfSense, I have not changed the admin GUI’s ports as in the first video; that is, I left them at 80 and 443 (since there is no external access to pfSense). In the first video an alias, “Firewall_Service_Ports”, that I set to 80 and 443, because those are the only ports reaching the admin GUI (I don’t have SSH enabled on the pfSense firewall). So, part of me is thinking that in order to fix this I need to change the pfSense web GUI from 443 to something else? Or is there a better way?
Move the pfsense admin ports.
That clears things up, thanks!
For future reference, if I set up pfSense again for whatever reason, and I also add pfBlockerng to that, I should move the pfSense admin ports to avoid this conflict, or is it a wise thing to move the pfSense admin ports in general, even if it’s not accessible from the internet?
I always so because it avoids potential conflicts.
If I understand your issue correctly, then I think I may actually disagree with Tom on this one. Yes, moving the pfSense admin ports will work, but I think the real solution to this particular issue is changing the virtual IP address in pfBlocker/DNSBL.
If you log into your pfSense and go to “Firewall → pfBlockerNG”, and then click on the “DNSBL” tab, you should see a section called “DNSBL Webserver Configuration”. If you look at the “Virtual IP Address” setting, it specifies that the address should be in a range that IS NOT ALREADY USED IN THE NETWORK. While the example uses 10.10.10.1, it sounds like your pfSense has an interface with that IP address, so instead of DNSBL sending a fake IP address to blocked DNS queries, you are actually sending your pfSense’s IP address! That’s why it’s important for this virtual IP to be in a subnet that doesn’t exist on your network.
In this case, 10.10.10.1 is fine for pfBlocker to use, because that network is not in use anywhere else in my network (I use 192.168.x.x only). So, when I installed pfBlockerNG, that was fine. What I think is happening, is that pfSense is smart enough to know that 10.10.10.1 is actually a virtual IP pointing to the LAN, so when I added the “block admin ports” rule, it started tripping off whenever pfBlocker tried to send someone to its DNSBL notification page. Pretty much, if I tried changing pfBlocker’s setting without moving pfSense’ admin port, it would end up doing the same thing. That is, no matter what address I put into pfBlocker, say, 10.10.10.10, it would be a virtual IP pointing back to pfSense’s ip, port 443. Which would now be blocked by that “block admin port”. Thus, the only real way to fix it is to move the pfSense port!
Yes, it’s not about the IP, it’s about port binding and not having the WEB UI bound to the 443 port.