NAT Outbound not working between VLANs

johnpoz

@idan37s yeah if you can find something that can be duplicated, we for sure should put in a bug report..

Happy to try and duplicated here.. But I currently have pfblocker enabled and creating aliases, etc. and not having any issues. But I just don't see what it could be doing that would have any effect other than if you were having it create actual firewall rules maybe??

idan37s

@johnpoz
The Geo IP and the IP block part in pfBlockerNG creates Floating FW Rules for me on the WAN interface,
Logically it shouldn't be the cause of the issue:

johnpoz

@idan37s yeah nothing on wan should have anything to do with your outbound nat on your iot vlan, etc.

But even that last reject rule there that has your lan and iot vlan in it.. Not sure how that would effect a nat, nats are looked at before rules, even in floating.. But you were still able to access - just not being natted..

Very strange indeed..

idan37s

@johnpoz
It's not the Floating rules, I disabled them and saw no change.
It seems like this is happened to a few others and not a new issue,
And like me, when they disabled and enabled PfBlockerNG everything start to work.

https://www.reddit.com/r/PFSENSE/comments/iiexur/nat_reflection_stopped_working_after_updating_to/

johnpoz

@idan37s I wonder if its just pfblocker keeping or causing an issue with the reload of the rules..

So for example if I look in the raw rules jsut my nats when I create that outbound I see it

[22.01-RELEASE][admin@sg4860.local.lan]/root: pfctl -sn
no nat proto carp all
nat-anchor "natearly/*" all
nat-anchor "natrules/*" all
nat on igb3 inet proto icmp from 192.168.9.100 to 192.168.3.32 -> 192.168.3.253 port 1024:65535

idan37s

@johnpoz
After testing it seems that when PfBlockerNG is enabled this list (from your command) is being updated only after you disable PfBlockerNG.

Can we open a bug on it somehow?

johnpoz

@idan37s said in NAT Outbound not working between VLANs:

when PfBlockerNG is enabled

When what exactly is enabled - like I said I am using it and not having the problem.

Are you using DNSBL? I am not.. You have it doing permit firewall rules? On floating?

idan37s

@johnpoz

I have DNSBL (unbound mode), GeoIP block (inbound) and IP block (inbound and outbound) all enabled in PfBlockerNG.
The GeoIP and IP Block are creating Floating Rules in the FW on the WAN interface (as seen in one of the screenshot above).

When PfBlockerNG itself is enabled, then new rules I add in NAT Outbound do not show up in the list I get from the command "pfctl -sn", and those new rules don't work.
Once I disable PfBlockerNG (and doing only that, nothing else) the new NAT Outbound rules I added now show up in the list form the command, and they do work.
I can now re-enable PfBlockerNG and the new rules will still be in the list from the command and everything will work as expected.

So as you said, it seems like PfBlockerNG is preventing an update on those rules list or something like that.

johnpoz

@idan37s turn off just the dnsbl stuff and or the firewall aspect, and leave pfblocker enabled.

idan37s

@johnpoz

I tried that,
I disabled DNSBL, IP Block, Disabled all the FW Floating Rules,
But the NAT Outbound rules still didn't work.

Only disabling the PfBlockerNG itself made it work.

johnpoz

@idan37s said in NAT Outbound not working between VLANs:

Disabled all the FW Floating Rules,

You did that here?

idan37s

@johnpoz
Not exactly,

Under the "DNSBL Configuration" the option "Permit Firewall Rules" was always disabled (not checked), it was never enabled even before this issue, during or after.

The "Floating Rules" was always Enabled (checked), and I meant that I just disabled the auto-generated floating rules manually one by one under the Firewall Rules UI.

johnpoz

@idan37s said in NAT Outbound not working between VLANs:

just disabled the auto-generated floating rules manually one by one under the Firewall Rules UI.

That has little to do with say a pfblocker process running that might hold of the change in the rules. I would disable that feature of pfblocker but keep pfblocker itself enabled and see if you have the problem. I do not let pfblocker do anything with firewall rules and just use it to create and update aliases that I manually use in my rules.

If you could validate that specific thing is holding up the nat rules - then we could file a bug saying.. Turn this on outbound nats do not update, turn this off and they do, etc.

idan37s

@johnpoz
So just to make sure I understand,
I need to disable both of the options you send above ("Floating Rules", "Permit Firewall Rules") in PfBlockerNG and then test if the NAT Outbound is working as expected or not?

johnpoz

@idan37s yeah leave pfblocker enabled - just make sure its not doing any firewall rules anything.. If works then we can enable the one you had and see if stops it.. If so we have great details for actual bug because I will try and duplicate it.

I just don't see how pfblocker just doing aliases would have anything to do with it, and I am currently doing that and not having the issue your seeing.

idan37s

@johnpoz
Sure, I will test and update with the details.

BTW, what do you mean by "just doing aliases"?
All the Actions in your PfBlockerNG are set to "disabled" and you just use the created aliases in your own FW rules?

johnpoz

@idan37s exactly I don't let it do anything but aliases - which I then put in my own manual rules.

idan37s

@johnpoz
Ok,
So after tons of testing I think I can say it's the GeoIP causing the issue,
Not sure why, and it's not consistent 100% of the time,
But when Floating rules are enabled (and the interfaces are selected in inbound and outbound) and GeoIP is enabled as Deny Inbound, the issue exist.
I wasn't able to reproduce the issue when Floating Rules was disabled.

Sometimes even if Floating Rules was enabled and GeoIp was enabled then it worked (for example when changing the Floating Rules from disable to enable while GeoIp was enabled, it worked sometimes and no issue existed.

Only if i disabled all GeoIp, forced PfBlocker to reload all rules (under Update), Enabled GeoIp, forced reload again then the issue happened I think every time.

It also seems like for me, while I live in Israel (which is part of Asia Alias), Europe GeoIp caused more for the issue to happen, even if only one country from that filter was selected.

I know it's not 100% step by step on how to re-produce the bug but that's what I managed to gather so far, hope it's enough.