pfBlockerNG-Devel bypassing local IP NAT
-
I have a spam filter on a private LAN IP (10.0.0.2).
I have pfBlockerNG-Devel blocking counties but I don't want 10.0.0.2 to partake in said country blocks.
I tried making a floating rule to allow the WAN the bypass but then upon further reading, PFSense processes NAT rules first. This is why pfBlocker-NG-Devel continues blocking countries and other things on the block lists.
So, I tried to reorder the process under Firewall > pfBlockerNG > IP > in this drop down section here:
The problem then becomes, I can't manually, the way I want, re-order the list with putting the allowed items at the top of the list and others below what's blocked.
It automatically re-orders the list annoyingly after a cron and moves my stuff.
How can I make this list do what I want to do? In the DNSBL section there's a policy section but that only works for DNSBL and not the IP tab, if it works I should say, I haven't tested it. It seems experimental, IDK.
Any help here would be appreciated. I just want to put 10.0.0.2 in front of any block rules.
Thanks.
-
@wolfsden3 said in pfBlockerNG-Devel bypassing local IP NAT:
I have a spam filter on a private LAN IP (10.0.0.2).
What does this even mean?
I tried making a floating rule to allow the WAN the bypass but then upon further reading, PFSense processes NAT rules first. This is why pfBlocker-NG-Devel continues blocking countries and other things on the block lists.
No. Usually pfBlocker has only firewall-rules, not NAT-rules. Here is how I did it, if I want something not to be blocked by pfBlocker.
I let pfBlocker create its rules on WAN (not floating). I am creating an extra WAN-rule on floating for my exception. If you have a problem with that rule, show it.
-
Or you change the pfBlockerNG Firewall 'Auto' Rule Order.
-
@Bob-Dig Spam filter on private LAN = a NAT port forward from public > private. So, yes, the spam filter is on the private LAN. It's pretty basic network stuff.
I'll try the other guys auto rule and fart around with that.
Thanks.
-
@wolfsden3 said in pfBlockerNG-Devel bypassing local IP NAT:
but then upon further reading, PFSense processes NAT rules first.
You can most certainly order the rules the way you want.
Please read the Note in Red on the screen you have attached. The sort order selection here only applies to "Auto" rules.
Nothing says you have to use Auto types, consider using Alias types and building your own rules. then you can place them in any order you want in any section (Floating/WAN/LAN)I have several NATs (on WAN and LAN) and those just become defaults or a catch all if the rules I've built in Floating above them fail to process or redirect the traffic because the IP's are not in the pfBlocker generated "Alias list"
I only have one Auto rule and it will always be placed at the top of the rules list. If you have more than one AUTO this is where the "Default Order" selection would come into play. (you can tell the system to place the AUTO rule in Floating, but you don't have to)
Below my single Auto are some "manual (alias)" rules that allow or deny traffic from specific Alias lists
one example might be a "good mailer" on the allow list, even if that would be from say an ip in a blocked country, their mail will get through. rules are processed in order from top down.
Another example might be a specific rule (even down to a specific internal device if you want) that is allowed to talk or just needs to be blocked from talking to anything outside.
at the bottom of the floats are my GeoIP blocks
So if the traffic isn't specifically blocked or allowed before getting to my Geo rules it will be handled by that rule located at the bottom of the rules
Rules apply as the traffic comes into the interface and once all the floating rules are dealt with any rules in WAN or LAN (depending) will be handled. You don't have to use floating, Sometimes simply for visualizing the rule processing order floating rules are convenient.
Personally I have a mix of floating and WAN / LAN based rules depending what I want to accomplish.
I have no issue both allowing certain mailers (for example) even if
a) they would be blocked by other rules, Geo perhaps) or
b) they aren't specifically processed by a previous rule and fall through to the NAT generated rule.This will be the section you want to pay attention to the wording on.
Here is a snippet of the log showing (specifically for only mail)
you will see,
GoodMail, rule is ABOVE Geo IP in float (allow)Bad Mailers, rule is BELOW good mail, and above Geo in float. This allows me to specifically block anyone not covered by Geo (or other rules), if I want to. (log doesn't show any recent entries here so including that as a separate capture myMailBL )
Geo IP, Blocked, rule is at bottom of Float rules
NAT SNMP - these haven't been processed by any pf the 3 specific rules (so in other words, undetermined by other rules) - this is "NAT SMTP" is on my WAN Rules.
This screen capture also shows 1 that got blocked by the single Auto Rule, PRI1 AR -
You will also notice that anything inbound mail related that is being blocked or allowed is based on WAN rules. - is your 10.0.0.2 a mail server? you would want to block the traffic from getting there from the outside, so WAN rule.
-
I used this solution for another purpose but, I think, it solves the same problem. My problem is Streaming TV pollutes pfBlockerNG block logs so that it is hard to see addresses that may need further investigation. This solution continues blocking but takes it completely out of pfBlockerNG. Or so it appears. I did this and I still see address blocking but pfBlockerNG ignores them entirely.
Floating rules don't enter the picture. I did everything plain vanilla.
The solution:
- Identify the polluting dns addresses and put them in an alias
- Create a LAN rule that blocks the addresses in the alias from ever leaving the network
- Whitelist the offenders in pfBlockerNG so the LAN rule gets them instead.
Blocking still works very well and pfBlockerNG is bypassed entirely for those addresses.
This all being said, I don't think you can put an entire country in an alias. But this will work great for a list you can manage in an alias.
Also - very important - reload pfBlockerNG DNSBL rules after making the changes. Otherwise they will remain invisible.
-
This post is deleted! -
@coffeecup25 We put countries in Alias Native aliases all the time. Once MaxMind is set up there is a GeoIP format/type choice on the IPv4 (6) tab when editing a source definition, which will autocomplete the country code.
For OP, Per the above post Alias (Native) just creates an alias so one can create rules as desired.
-
@coffeecup25 was actually applying the concept here for a DNS sinkhole
https://forum.netgate.com/topic/182752/can-pfblocker-sinkhole-an-address-domain-overrides/16
in addition to the mail sample provided, I do similar for other specific traffic as well (like DNS)
