Nat issue after 20211220 version
-
@netblues, Why did he have this rule in the first place? what was he using it for?
-
@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?
-
@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
-
@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"
-
@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.
-
@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. -
V viktor_g referenced this topic on
-
V viktor_g referenced this topic on
-
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
-
@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.
-
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
-
Redmine issue created:
https://redmine.pfsense.org/issues/12654 -
Should now be fixed in the current snapshots.
-
@stephenw10
Will check. Bug status remains open though. -
2.6.0.b.20220103.0600
I can confirm that with outbound nat "any", system can nat itself and reach the Internet.
Regards
