Nat issue after 20211220 version

@netblues, all seems to be fine until you put any in source

Please consider doing the above test or just use a wider netmask to specify your "Source" range.

Example: Source = 192.168.0.0/16

@netblues said in Nat issue after 20211220 version:

@silence Are you aware how nat rules work?

in the past I never had any problem using Nat on pfsense or other firewalls.

you just have to create rules with logic.

and always try to avoid using "Any"

netblues

@silence I have already said that aggregates could also work.
But this is not the issue.

I'm not looking for a solution, there are many workarounds now that I know what the curlpit is.
The question is what changed in the builds that created this corner situation.
Many things change between snapshots, and some times changes create regression issues.
Devs should be notified when this happens

@netblues to know what change, I asked you to do the packet capture in both version 2.60 and 2.52

this way you can find the change yourself and publish it.

It would be a great help.

netblues

@silence nope.
2.5.2 is on freebsd 12.2
2.6.0 changed to freebsd 12.3
Many things can be different.

Please, give some time to the devs to acknowledge the issue.
When the issue can be replicated, a redmine ticket will be created.

stephenw10

Mmm, generally speaking your should not have a rule like that because it will cause pfSense to NAT all it's own traffic. That breaks some things completely, like IPSec.

However most traffic should continue to work.

We are tracking a similar issue internally for traffic from localhost which seems likely related. Traffic must be NAT'd in that case.

Steve

netblues

@stephenw10
Yes, I agree that this rule is a bit ugly
I have no ipsec configured.
openvpn client worked however (udp)

It was quite difficult to pinpoint though.

stephenw10

Indeed, we are still pinning it down. It was not shown immediately after the Dec 20th changes because it only affects edge cases. Most pfSense installs never NAT their own traffic.
I'm confident the localhost case will match this also. A redmine entry should be up soon.

Steve

viktor_g

Redmine issue created:
https://redmine.pfsense.org/issues/12654

stephenw10

Should now be fixed in the current snapshots.

netblues

@stephenw10
Will check. Bug status remains open though.

netblues

2.6.0.b.20220103.0600

I can confirm that with outbound nat "any", system can nat itself and reach the Internet.

Regards