Nat issue after 20211220 version

netblues

I have come up with a changed behaviour while upgrading to more recent snapshots

Upgrading in place from 20211220 to 20211226 (and maybe earlier that that) led to loss of connectivity for pfsense box to the internet.
No updates, no ssh.
But I could ping. I could ssh to local lan without issues.
After a lot of testing and regression I found the curlpit
The rule in yellow (now disabled)

Adding this rather generic nat rule, makes pfsense host not to be able to connect or get updates, or packages, reach the Internet in general.

Everything else works.
It only happens after 20211220 (circa)
Is it a bug? Is it a feature?
Fancy thing is that dns works, ping by name (and ip) works
outbound openvpn works (udp)
Its only tcp (or maybe udp.. didn't check) from console + updates that doesn't.

That was a nasty one to pinpoint.

Regards

@netblues, Why did he have this rule in the first place? what was he using it for?

netblues

@silence As a general outbound nat rule that could apply to any internal network.
Especially if there are many. It could also be aggregates and yes there are many workarounds, however this leads to unexpected results.
It was there in 2.5.2 and worked without issues up to 2.6.0 20211220

@netblues, Can you show me a scenario where this nat rule makes any sense?

version 2.60 is experimental why did this upgrade?

netblues

@silence This is the development snapshots section of the forum

Snapshot issues are reported and bug tickets are created so they can be fixed.

Instead of typing all internal network ranges, a catch all entry does the job.
In situations with lets say 10 internal networks it comes handy.

@netblues, I simply cannot understand that a rule says the following :::

WAN :: ALL :: ALL :: ALL :: WAN ADDRESS :: ALL :: ALL

It is a totally non-logical rule for me, but if it helps you, I recommend you use pfsense packet capture and verify where the traffic goes when you have this rule enabled.

Diagnostics > Packet Capture

netblues

@silence Are you aware how nat rules work?
nat is applied only when the packet reaches the interface.
So what the rule says is that when a packet reaches the internet (wan ) interface, it should be natted using the ip of the wan interface.

As a matter of fact this works nicely (apart from the issue mentioned)

@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