Endpoint-independent Outbound NAT (eimnat) rules

luckman212

@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

d0ff601f-2ead-4000-82b6-9891ed9c8b6e-screenshot_wZ6bwauZ.png

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:26787

Tested again without EIMNAT, and it reports symmetric:

$ nat-detect
   nat_type: Symmetric
public_addr: 70.18.xxx.xxx:46689

So it's definitely changing the behavior. Not sure if it should be possible to achieve FullCone however...

Bob.Dig

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: good

I saved the dumps if they are of interest.

I will give 25.11 RC another chance without using this feature.

luckman212

@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.

Bob.Dig

@luckman212 Yep, I had static port enabled too.

marcosm

@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.

Bob.Dig

@marcosm said in Endpoint-independent Outbound NAT (eimnat) rules:

The crash can be uploaded here:

Done.

luckman212

@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.

Bob.Dig

@luckman212 I think you are one of the few early testers.

Besides this new NAT-feature, everything works fine so far.

marcosm

@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

luckman212

@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...

marcosm

That matches the crash we reproduced. It will be fixed in the release.

luckman212

@marcosm That's good news. Glad you guys snagged this last minute!