pfSense NAT-PMP Failures

Tailscale version: 1.24.2
Your operating system & version: Ubuntu Server 22.04, Fedora 35, Android 12

Recently switched to pfSense on my local network and am unable to establish direct connections to a remote server (Ubuntu). Came across this article saying to enable NAT-PMP, which I did. However, I’m getting errors from tailscale netcheck and my pfSense log. No mappings get created.

Not sure if this is a pfSense issue or a Tailscale issue. If I create a manual outbound NAT rule as described here, I’m able to establish a direct connection from my laptop (Fedora), but my Android phone keeps going over a relay.

Tailscale Netcheck:

2022/05/13 15:01:31 portmap: PMP probe failed due result code: {OpCode:128 ResultCode:NetworkFailure SecondsSinceEpoch:161 MappingValidSeconds:0 InternalPort:0 ExternalPort:0 PublicAddr:0.0.0.0}
2022/05/13 15:01:31 portmap: [v1] Got PCP response: epoch: 161
Report:
* UDP: true
* IPv4: yes, REDACTED:5759
* IPv6: no
* MappingVariesByDestIP: true
* HairPinning: false
* PortMapping: PCP
* Nearest DERP: Chicago
* DERP latency:
- ord: 90.6ms (Chicago)
- nyc: 90.7ms (New York City)
- dfw: 118.6ms (Dallas)
- sfo: 150.4ms (San Francisco)
- sea: 159.4ms (Seattle)
- lhr: 166.7ms (London)
- fra: 183.9ms (Frankfurt)
- sao: 201.2ms (São Paulo)
- tok: 213.8ms (Tokyo)
- blr: 314.6ms (Bangalore)
- syd: 314.9ms (Sydney)
- sin: 329.8ms (Singapore)

pfSense Routing Logs:

May 13 15:09:09 miniupnpd 60278 PCP MAP: failed to add mapping UDP 41641->192.168.1.106:41641 ‘PCP MAP d0a44ffed131cc9e7a291b9d’
May 13 15:09:09 miniupnpd 60278 Failed to add NAT-PMP 41641 udp->192.168.1.106:41641 ‘NAT-PMP 41641 udp’

The laptop and Android phone might both be trying to use port 41641, and only one of them will win.

Using Tailscale with your firewall · Tailscale also describes how to set randomizeClientPort, which would have them each choose a different port and might work better with static outbound mappings.

Thanks, actually found that option a little bit ago. Tried it, but doesn’t really help since my port mappings are failing and I can’t create manual rules for all the random ports.

I would expect that with randomizeClientPort set, outbound static port mappings set for all UDP ports, and NAT-PMP disabled, that both the laptop and Android device would be able to make direct connections through the OPNsense firewall. Does that not happen?

1 Like

Yes, that does indeed work. Not sure if I want to use that mapping long-term though. Any idea why NAT-PMP is failing?

The main thing I’ve noted about OPNsense NAT-PMP is that if all of the Tailscale nodes are trying to use port 41641, only one of them wins at any given time.

Setting randomizeClientPort, turning NAT Outbound static mappings back off, and turning NAT-PMP back on may work better.

Randomizing the ports still fails with NAT-PMP. The only way I can get a direct connection at all is with manual mappings. NAT-PMP fails to create any Tailscale mappings no matter what I try. It just gives the errors indicated in my original post.

Having to use manual mappings wouldn’t be the worst thing I suppose. I could create an alias with my Tailscale devices to avoid static mappings on every UDP port in my entire LAN. NAT-PMP would be my preferred method, though. If it sounds like a pfSense issue then I’d be happy to take it to their forums.

This morning everything is back to using relays. Just noticed that my WAN IP is CGNAT 100.126.X.X/10, which is within the range Tailscale assigns. I’m guessing this is the source of my problems and also the reason NAT-PMP is failing?

Very likely. That means you are behind at least two layers of NAT on the way to the Internet, one layer in OPNsense and one in the carrier’s network somewhere. Both NAT-PMP and the static Outbound mapping are able to get through the first layer of NAT but not the second.

I recently upgraded my pfSense to 2.6.0 and have the exact same issue. The rules dont get created and the pfSense logs have the same “failed to add mapping” errors.

Earlier I was on 2.4.4 and everything worked perfectly.