@Bob.Dig Same thing is still occurring on 2.9.0 CE stable. [image: 1788808149551-31fb7c10-f0b3-47d4-86c3-8607468c74f7-image.png] Rolled back to 2.8.1 and all is working fine. [image: 1788808225213-e222f8f5-d26e-429a-b396-6337eb8933a7-image.png] I use UPNP to block port 3074 to obtain open nat for multiple PCs for Call of Duty. It's not working on 2.9.0

Maybe my helper tool github.com/luckman212/stv could be useful for peeking at those IPSec related states in a filtered way? something like stv 'ipsec|esp|:500 '

@luckman212 I prefer port-specific NAT rules to minimize attack surfacea, and since it will only be about 5 with a CIDR block, it won't add much complexity.

@Bob.Dig said in 26.07-RELEASE: Port Forward is missing pass: Is there an easy way to incorporate these changes into pfSense Plus today? Copy paste the entire (bottom of the page) : diff --git a/src/etc/inc/globals.inc b/src/etc/inc/globals.inc index bf46112b5fc5159c23406e3216b68a83e848264e..38ee5813856ad3b81e8a1733af819d48820a77f3 100644 --- a/src/etc/inc/globals.inc +++ b/src/etc/inc/globals.inc @@ -92,7 +92,7 @@ $g = [ 'disablehelpicon' => false, 'disablecrashreporter' => false, ..... + +// Association action type. +// 'associated-rule-id': Used for existing NAT rules with a linked filter rule. +// 'filter-rule-association': Used for new or existing NAT rules with no linked rules. $section->addInput(new Form_Select( - $rule_association, + $has_linked_filter_rule ? 'associated-rule-id' : 'filter-rule-association', 'Filter rule association', $pconfig['associated-rule-id'], $rulelist Produces a no-go : [image: 1787301221142-9992d749-0957-419c-9aac-19b87f8f76e3-image.png] But ... when you change just this : [image: 1787301253819-97d52bb1-4e42-4c34-86ac-629e1cf32a55-image.png] to 'latest_config' => '24.6', as the current pfSense Plus 26.03 config version is 24.6, you have a go : [image: 1787301383216-14468707-a4d7-46f0-95dd-2cee8a62e4b1-image.png] That's something you could consider, but a green light from @jimp seems appropriate here, as changing that line to "24.8" might have 'consequences'. Clear is that the patch was based upon a config version we don't have yet, 24.7, something that lies beyond the 26.07 Release.

@HawaiianHopeOrg well I thought I pasted a link...see https://docs.netgate.com/pfsense/en/latest/releases/2-9-0.html#rules-nat:~:text=Same%20port%20forward%20on%20multiple%20WANs ? Doesn't seem like it breaks things if I read it right yesterday...?

@SteveITS I have 102 lines 3 /24 1 /16 2 /27 1 /28 2 /29 The rest are /32 Not a lot. It was all working until the reboot. Then all the lines we set to /32 I updated the incorrect records. It seems the lines with anything but a /32 were working.

@rutherforda a route is not a nat - unless your natting at your switch, which maybe you are? Did you setup routes in pfsense to these downstream networks hanging off your switch? What rule do you have on the lan network - is it only the lan subnet as source? For you to do multiple networks on your L3 switch, you would either be routing or natting. If your natting on your switch - then yeah its a double nat. Either way unless you have like 10ge between your segments on your switch, why would you not just route at pfsense so you could actually firewall between your segments.

Mmm, that would be good to know. It does make me wonder what what it does with those config rules if they are not created as expected. If you're able to it would be good to check the actual running ruleset with pfctl -sr and pfctl -sn.

@uncleasbestos said in Super strange NAT problem that occurred for no reason at random: I double checked the aliases and they were correct So it looks like the firewall using rules with aliases, doesn't match these alases. First, a less know secret : a firewall doesn't work or understand hosts names or aliases. A firewall can only work with IP addresses, when it concerns a source or destination. Have a look at this file : /tmp/rules.debug. This is the actual file, a list woth rules instructions, loaded into 'pf' the pfSense firewall. Search for BCM_SIP. You should find this : .... table <BCM_SIP> { a.b.c.d ...... } BCM_SIP= "<BCM_SIP>" .... The a.b.c.d is (are) the IP addresses that were resolved from teh alias, if the alias contained a host name. When I create a alias called : [image: 1781854107799-534f6509-ba44-4387-80f3-3150b67e542e-image.png] Note : you saw : FQDN hostnames are periodically re-resolved and updated. If multiple IPs are returned by a DNS query, all are used and use it in a WAN firewall rule like : [image: 1781854133969-31aff0a2-3bda-4dd8-b36d-73d7234ef5b0-image.png] I can find this in my /tmp/rules.debug : .... table <BCM_SIP> { 1.2.3.4 } BCM_SIP = "<BCM_SIP>" .... if the "BCM_SIP" was a FQDN, or something like "www.whatever-fqdn.tld" then this hos name is resolved every 5 minutes or so (see system settings for the frequency) and the resolved IP is entered into the firewall rule table. Read : Alias Features and Limitations as it mentions important info. There are still people out there that make an alias with 'www.facebook.com' and then find out it doesn't work as intended Anyway, now you have even more tools to check.

Unclear how those devices are connected. Are those subnets all /24? If so then both devices have 3 interfaces with one in each subnet. If you have firewall rules to allow it then each should be able to ping between them on any interface Where is the gateway? Where are you testing from? What NAT are you adding?

I'd skip that tip, as it might cause routing issues. Instead, just set up some firewall rules to block any unwanted traffic leaks. Keep it simple!

@Uglybrian Thanks for the reply. Sorry it took so long for me to reply. Again, I have no idea how or why, but sometime after I found the issue, either the firewall, the xBox or both got things working again on its/their own. I haven't had any problems since, other than it has seemed like loading games is taking quite a bit longer. I can live with that.

Make sure you've read through this article, Troubleshooting NAT Port Forwards, from the official docs. Specifically the pfSense software is not the border/edge router and Return Routing subsections may be of particular relevance.

So I found this option, which solves all my problems: [image: 1777887852722-screenshot-2026-05-04-at-10.43.31-resized.png]

For those appreciating closure: This problem is almost certainly caused by the Ricoh MP C3003 stack being unable to parse the rport parameter in the Via header of a SIP 401 Unauthorized response: Via: SIP/2.0/UDP 172.17.5.1;received=81.172.xxx.xxx;rport=2529;branch=z9hG4bKUns1ysLZx*LuI Transport: UDP Sent-by Address: 172.17.5.1 Received: 81.172.xxx.xxx RPort: 2529 Branch: z9hG4bKUns1ysLZx*LuI Note that this parameter is present in the dump of the failing connection with the cloud provider, but absent in the succeeding connection to my local Asterisk test server. A necessary remark here is that the latter was using chan_sip, which never includes this parameter, whereas the first was using pjsip. In the mean time, I have installed FreePBX on a Raspberry Pi 5 and I'm using that as a PABX in my house and as a proxy for this fax. It failed to this server is a very similar way and the solution turns out to be simple: In the fax extenstion's advanced settings, Force rport needs to be set to No for the registration to succeed and Rewrite Contact needs to be set to No for the options to be accepted.

Thanks here. I was really trying to avoid breaking something so making sure I understood how it works. Thanks for the confirmation.

@Gertjan Thanks for your suggestions

@Ross-Garmoe If the NAT rules were using a host alias with FQDN, pfSense resolves the FQDN every few minutes to create/update the pf alias. It's not really a NAT issue but if the table was empty it wouldn't create. I would have expected an error about an empty table/invalid alias though...at least that's the case for firewall rules. Assuming it was an internal domain name FQDN, another option would have been to set a domain override, so any DNS query hitting pfSense for the internal domain would get forwarded to the AD DNS server(s). Sounds like disabling pfSense DNS got pfSense to use AD DNS and resolve the FQDN? Anyway, glad it's working.