pfBlockerNG-devel v3.1.0_9 / v3.1.0_15
-
@smoke_a_j said in pfBlockerNG-devel v3.1.0_9 / v3.1.0_15:
When using an Action setting of 'Permit Inbound or Permit Both', you must configure at least one of 'Advanced Inbound Custom Port/Destination' settings
There was a different thread about this a few weeks ago. If you allow all inbound traffic to your WAN IP on all ports then the IPs specified can access pfSense via SSH, HTTPS (web GUI), DNS, etc. Meaning, attackers can continually guess passwords until they get in.
The warning is so you don't allow that.
If you really wanted to open your pfSense to the Internet you could create these as Alias Native which only creates the alias, and then create your own rules on the WAN interface using that alias.
-
@steveits That is understood, that's why I have an alias set for Mirosoft ports for certain specific work apps and xbox live logins as well as a separate alias set for my wifi calling ports, same recommendations existed in pf 21.05 and the firewall rules as well as the IPv4 tab used to compile all of this just fine. These alias' have no http, https, DNS, or ssh ports listed in them and further verified with having WAN de-selected and had this Custom Port option enabled and alias name typed out correctly each time. Appears to me more of a PHP or XML coding issue in 22.7 config versions, and I found came about recently when repos got set to temporarily showing that pfSense 23.01 stable was available but since https://firmware.netgate.com/pkg/ was not updated at the same time to coincide, my repos config became corrupt from it landing both of my boxes in non-fixable certificate errors at boot needing to start from scratch. This is now verified on 2 different devices, one is a NG 5100, and both are freshly setup once again days ago from flash. Obviously having "all" ports open is a common sense no no to any networking hence the entire reason of having a "custom port" option for an alias. The point of this post is these errors are persistent with the correct entries filled and applied. Basically from what you are saying is that "inbound permit both" simply is not an option and therefore would not exist with these "custom options" to configure, but in reality these configuration option realistically are there and there for a reason and used to function for that reason. This exact situation is occurring on one of my boxes that does not even have a "WAN" interface configured to even select, LAN only serving only DNS as a parental locked pi-hole basically, all of which is still working fine. Also noting that each time attempting to edit or create a new IP whitelist, once each of these custom options are specified on Advanced Inbound Firewall Rule Settings and then try to save, once these errors are displayed when the page loads, scrolling back to the custom options the enable tic box does remain ticked but the fields to enter the port alias/IP alias name in becomes emptied and grayed out with the red circle with a line through it as I hover over the entry field until I un-tick the enable option and then re-select it and then the entry field becomes available to enter the alias name into again; I'm leaning toward PHP since no other pfSense configurations or functions seem to be affected, just editing or creating from the gui on the pfblockerng_category_edit.php pageregardless if its IPv4 or IPv6 whitelists
-
@smoke_a_j I missed that you set a port alias. Does it work with one port number instead of an alias?
If it is a bug, then creating the pfB alias and manually creating your own rule ought to work around it.
-
@steveits Even just one listed in an alias does the same. pfB alias permit is a working feasible workaround with "permit both" broken, auto rule function is/was nice and safer to configure with those warnings accurately working to make sure the custom fields are in fact filled out but somehow the validation of that fact looks to be clearing the data entered instead of reading it, maybe one letter off in the code like a "W" instead of an "R"
-
This post is deleted! -
@sensei-two
@xpxp2002
Something that may help you with the above to make sure everything is hitting the firewalls right:
for NAT port forwardsand
for Outbound NAT -
Found my fix:
BBcan177BBcan177 MODERATOR 12 days ago
@bob-dig @cjbujoldSee the patch here and report back pls.
From the Shell or pfSense GUI > Diagnostics > Command Prompt > Execute Shell Command, run this command to download the patch.
curl -o /usr/local/www/pfblockerng/pfblockerng_category_edit.php "https://gist.githubusercontent.com/BBcan177/1a33c42d0a61f3ddd9c2f1b1d514ed83/raw"
"Experience is something you don't get until just after you need it."Website: http://pfBlockerNG.com
Twitter: @BBcan177 #pfBlockerNG
Reddit: https://www.reddit.com/r/pfBlockerNG/new/ -
When enabling IPv6 DNSBL I get the error "There were error(s) loading the rules: no IP address found for <My_IPv6_Prefix>::1017171 - The line in question reads [n]
As you can see I run the DNSBL webserver on a non default IP (default IPv4 is 10.10.10.1, and default IPv6 is ::10.10.10.1)
So its looking for <My_IPv6_Prefix>::1017171 , but I think this should be <My_IPv6_Prefix>::10.17.17.1 instead
I have the floating auto firewall rules and the DNSBL aliases correct.
Is this a bug? I am running version 3.1.0_9
Kr, Matthijs
-
This post is deleted! -
@matthijs I'm on the same version on 22.05. It did seem to update my alias entry as well as my IPv6 on the Firewall->Virtual IPs tab to ::10.17.17.1 when I changed my DNSBL webserver IP to 10.17.17.1 after first disabling pfBlockerNG and saving on the General tab first, adjust webserver IP setting, then re-enable on General tab and then Update tab->Force reload ALL. Any adjustments you make in pfBlocker aside from clicking to whitelist an IP or domain from the alerts tab which can effectively live load on a running config once a minutes or so, it is always best otherwise for all other settings adjustments to #1 disable pfBlocker first, #2 adjust, #3 re-enable, and then #4 force reload. Otherwise, erratic unexpected behavior will be expected, as applies with nearly any firewall/router. ANY one letter and/or number/setting variance applied to any order of rules/IP addresses/domains will shift an entire stack of one group of all of this info one row different than its original placement against the next stack/table of information the other stack is pointing to originally all in alignment now staggered. You may have to disable it, restore pfBlocker default settings to start at a fresh config sheet schematic and make this adjustment before enabling pfBlocker which in turn writes those states table/firewall entries at that point.
-
@smoke_a_j
Thanks for the information, I will try this and give feedback here if this method will fix the issue
-
@smoke_aJ
I did exactly as you descibed but the issue is still there.
I also updated to version to 3.1.0_11, but also with this version I got the same problem.I got the weberver interface on a different physical interface then LAN. (I got it on interface DMZ1). Maybe this is the issue. ?
"Select the interface which DNSBL Web Server will Listen on.
Default: Localhost (ports 80/443) - Selected Interface should be a Local Interface only." -
@matthijs try to use "localhost" as that is the default setting
-
@bbcan177 I will try, but then why is the option to select an interface there? I will test, and report back the result
Kr,
Matthijs
-
Upgraded to this version: 3.1.0_11 and everything is working for me, thanks for your hard work BBcan177, awesome tool.
-
@BBcan177
@smoke_aJI again applied the steps as smoke_aJ suggested after a reboot. I do not see the error message for 45 minutes. It lookes like its solved now. I will keep you informed if the error message is coming back.
Thanks for the help and informationKr,
Matthijs
-
Unfortunalty the error came back after a filter reload.
Filter Reload
There were error(s) loading the rules: no IP address found for <IPv6_Prefix>::1017171 - The line in question reads [3781]: @ 2023-01-21 20:30:30I will try to change the webserver interface to localhost, to be continued...
-
@BBcan177 , @smoke_aj, Good news, I assigned the DNSBL webserver to localhost instead of the DMZ1 interface. Now everything is working and I am not seeing the error message again. Also after a filter reload the error stays away. So I guess as soon as you chose a physical interface (in my case LAN or DMZ1 or DMZ2) instead of localhost for the webserver, and in my case also a non default port number (8080 8443) and enabling Ipv6 the bug manifests itself. Can you replicate this behaviour ?
-
B BBcan177 unpinned this topic on