Endpoint-independent Outbound NAT (eimnat) rules
-
pfSense+ 25.11 (and 2.9.0) introduce Endpoint-independent Outbound NAT—aka Full Cone (related redmine #16517)
I'm waiting for this upstream commit to land in snapshots to be able to test it without causing a kernel panic on my 6100. In the meantime: does anyone have any examples of how an Outbound NAT rule should look when using this?
E.g.
- can or should "Static Port" be enabled at the same time as EIM?
- is
udp/*ok, or is it better to narrowly target only specific ports? - any other tips or guidance on this new feature?

-
When testing the PS5 and Switch 2 I did not need to check "Static Port". To achieve NAT Type 2/B I only checked EIM-NAT and configured UPnP.
-
@marcosm Thanks, I'm testing with 25.11.r.20251118.1708 now
-
@marcosm Is UPnP still needed though? I thought part of the appeal of EIM NAT was that we didn't need UPnP...
I enabled just eim, flushed my state table and ran a few online tests, but not sure it's working for me... all sites are reporting me as being behind a "Port Restricted Cone NAT"
eg https://natchecker.com or https://whatsmynat.com

I also tested with some commandline tools I found, e.g. stunner and nat-detect
With EIMNAT checkbox enabled
$ nat-detect nat_type: PortRestrictedCone public_addr: 70.18.xxx.xxx:26787Tested again without EIMNAT, and it reports symmetric:
$ nat-detect nat_type: Symmetric public_addr: 70.18.xxx.xxx:46689So it's definitely changing the behavior. Not sure if it should be possible to achieve
FullConehowever... -
I did the upgrade to the RC this morning, coming from 25.07.1. I then enabled Endpoint-independent Outbound NAT for my machine and pfSense crashed. And it crashed on every boot so I had to use the zfs-snapshot feature.
Dump header from device: /dev/gpt/swap1 Architecture: amd64 Architecture Version: 4 Dump Length: 381952 Blocksize: 512 Compression: none Dumptime: 2025-11-19 10:51:17 +0100 Hostname: pfSense.internal Magic: FreeBSD Text Dump Version String: FreeBSD 16.0-CURRENT #33 plus-RELENG_25_11-n256497-084b5f7b7bcd: Tue Nov 18 17:18:00 UTC 2025 root@pfsense-build-release-amd64-1.eng.atx.netgate.com:/var/jenkins/workspace/pfSense-Plus-s Panic String: page fault Dump Parity: 1574524171 Bounds: 0 Dump Status: goodI saved the dumps if they are of interest.
I will give 25.11 RC another chance without using this feature.
-
@Bob.Dig could you post a screenshot of how you configured your EIMNAT rule? Did you have Static Port checked? Seems like you're hitting the same bug I encountered before.
-
@luckman212 Yep, I had static port enabled too.
-
@Bob.Dig The crash can be uploaded here:
https://nc.netgate.com/nextcloud/s/FGaJJ3bHDTnTi5Q@luckman212 EIM may not be sufficient because as I understand it EIM only deals with the mapping. There is still the matter of allowing (e.g. inbound) connections through the filter which UPnP helps with. FWIW I didn't see the Switch 2 even try UPnP. With EIM (no port forwards, static port unchecked) it showed NAT Type B, without EIM it showed NAT Type D.
-
@marcosm said in Endpoint-independent Outbound NAT (eimnat) rules:
The crash can be uploaded here:
Done.
-
@Bob.Dig Thank you for being another person on the internet with this problem. I'm used to being the only one with weird edge case bugs.
-
@luckman212 I think you are one of the few early testers.
Besides this new NAT-feature, everything works fine so far.
-
@luckman212 @Bob.Dig If you can reproduce the issue on the RC, would you try again with the debug kernel? Hopefully that will contain additional useful info. See:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/debug-kernel.html -
@marcosm I just replicated the crash on the debug kernel and uploaded the dump to nextcloud. Hope it helps.
If this panic can't be fixed in kernel then at least Input Validation should block users from clicking both EIMNAT + Static Port...

-
That matches the crash we reproduced. It will be fixed in the release.
-
@marcosm That's good news. Glad you guys snagged this last minute!
-
@marcosm today was received update System25.11.r.20251126.1732. Is this issue was resolved?
-
The good thing, with 25.11.r.20251126 it is not crashing immediately. But does it do anything, I can't tell. None of the linked NAT-type-check-sites report any difference to not having it enabled.
-
@Bob.Dig Did you test with static ports or only nat? Because crashed was , if use together with static ports.
-
@Antibiotic I did test. It's no longer crashing with both "static port" and "eim nat" checked together. Not sure still what the behavioral differences are between running with just one vs both checked. This will hopefully get some more documentation and examples over time.
-
Endpoint-independent Port Restricted Cone Outbound NAT¶
This version includes partial experimental support for “Port Restricted Cone” endpoint-independent outbound NAT. This functionality must be manually enabled on a per-rule basis.“Port Restricted Cone” NAT mappings attempt to preserve port and external address mappings for clients when speaking to multiple remote hosts, but in a dynamic way that does not rely on static port NAT. This helps avoid issues with multiple local clients using the same source port to the same remote host. These rules enable a client communicating with multiple remote hosts using the same source port to receive the same external IP address and port on outbound connections to any destination. This behavior facilitates use cases such as online gaming, peer-to-peer connections, and VoIP.
Inbound communication from a remote host and port is only possible after a local client initiates first contact to that remote host and port. While this is more secure, it is not yet capable of “full cone” NAT which some use cases may require such as certain types of online gaming.
I dont unserstand , do this need to tick static ports as well, or not? to be able working properly