pfBlockerNG-devel v3.1.0_9 / v3.1.0_15
-
@sensei-two said in pfBlockerNG-devel v3.1.0_9 / v3.1.0_15:
maybe the browser is being redirect to port 53 if DoH queries can't be resolved because of the new pf_rules I added.
Any thought?If you are talking about Browsers using DoH - there normally should be fallback to a system's DNS setting if no DoH can be established for exactly that case. AFAIR Firefox etc. have a setting to disallow that to "avoid" being redirected to a "bad/controlled DNS" but in a home/company setting that's exactly what you want because otherwise many internal domains/services are unavailable (as they are often non-public DNS entries). But that discussion has become way out of scope of that post here, where the topic is about the new version and problems/bugs that may happen with it. Please put posts about usage/config problems of a feature in a separate post (as that feature wasn't introduced in version 3.1.0_9 / _15) for better visibility :)
Cheers
\jens -
@jegr
I might be wrong, but it is exactly what seems to have happened with Firefox too: it switched to my system DNS.
Anyway, as you say, I'll post about the issue elsewhere, to dive deeper into it possibly.
Thanks -
I am copying this over another user noticed in 3.1.0_1 that I am seeing still currently present in 3.1.0_9. I have IPv4 whitelists that carried over from pfSense 21.05 my box shipped with, used to be able to edit and add IPs when I needed. Now I find that unless I am whitelisting IPs via the alerts tab itself, if I try to edit any of these custom lists manually I am facing this same "Warning: When using an Action setting of 'Permit Inbound or Permit Both', you must configure at least one of 'Advanced Inbound Custom Port/Destination' settings." as well as a "Improper Permit rules on the WAN can catastrophically impact the security of your network!" error detected. This is also verified when trying to create a new rule from scratch, even with attempting to set IPv4 main screen interface rules config for inbound rules to LAN instead of WAN as it was and should be:
Tueurdragon wrote on https://forum.netgate.com/topic/176439/error-on-permit-inbound-rule-ipv4-part :
Error on Permit Inbound rule IPv4 part
pfBlockerNG 1 2 192
TTueurdragon Dec 13, 2022, 11:19 AM
Error on Permit Inbound rule IPv4 partHi there,
I have a problem creating a Permit Inbound rule in the PFBlockerNG-devel module IPv4 part.
Indeed, I want to create a Whitelist before all the GEOIP blocking rules.
SETTING part
Here are the things that I provide:
Action: Permit Inbound
Update Frequency: never
Weekly: Monday
Auto-Sort Header field: Enable auto-sort
Enable logging: Enabled
States Removal: EnabledPart Advanced Inbound Firewall Rules Settings
Custom DST Port: checkbox check , in the input field I enter an alias
Custom Destination: checkbox check, in the input field I enter an alias
Custom Protocol: TCP
Custom Gateway: I choose my gatewaygroup because I have several WANs in failoverUnfortunately I always get this error
The following input errors were detected:
Warning: When using an Action setting of 'Permit Inbound or Permit Both', you must configure at least one of 'Advanced Inbound Custom Port/Destination' settings.
===> WARNING <===
Improper Permit rules on the WAN can catastrophically impact the security of your network!
And the Custom DST Port and Custom Destination input fields are cleared.Can you help me?
Thanks in advance,0
TTueurdragon 28 days ago
Small clarification,I have another PFSENSE firewall with the PFBlocker-NG module in version 3.1.0_1 and it works but obviously it no longer works on the PFBlocker-NG version 3.1.0_7
-
@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...
