Project

General

Profile

Actions

Bug #12797

open

UPnP+STUN forms invalid outbound NAT rules using the external address discovered from STUN

Added by Bob Dig about 2 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
UPnP/NAT-PMP
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

With the new release of 22.01 pfSense should be able to use Mini-UPnP, even if it is behind another router as an exposed host, therefore the STUN-Server feature. But it is not working. Because it hasn't working for a long time, I can not tell if this is a bug or a feature still to implement fully.

Forum post:
https://forum.netgate.com/topic/169848/upnp-behind-double-nat-is-not-working-even-with-a-stun-server

Actions #1

Updated by Jim Pingle about 2 years ago

This may be the same issue already being discussed in this forum thread: https://forum.netgate.com/topic/169773/miniupnp-full-cone-double-natincorrectly-adding-rules

You also will need the patch from #7727 (See https://forum.netgate.com/topic/169837/upnp-fix-for-multiple-clients-consoles-playing-the-same-game ) but that alone may not be enough if you hit the same issue the other person in that thread is hitting.

Actions #2

Updated by Jim Pingle about 2 years ago

  • Project changed from pfSense Plus to pfSense
  • Category changed from UPnP/NAT-PMP to UPnP/NAT-PMP
  • Affected Plus Version deleted (22.01)
Actions #3

Updated by Jim Pingle about 2 years ago

  • Subject changed from UPnP behind double NAT is not working, even with a STUN-Server to UPnP+STUN forms invalid outbound NAT rules using the external address discovered from STUN

For inbound connections (rdr), STUN is working and a client can open and successfully test a port with a private WAN with 1:1 setup upstream passing all traffic to it.

The STUN case is forming invalid outbound rules (nat on ...) using the IP address it discovered from STUN. This isn't valid because that address is not present on the firewall, it's an address on an upstream device.

Manually setting the ext IP address should use that IP address in the NAT rules because that feature is intended for using IP alias or CARP VIPs on a WAN interface so that UPnP doesn't need to use the main interface address. This appears to be working OK, it's the STUN+nat on case which is problematic since with STUN that address isn't local like it is with the ext IP address set.

Actions

Also available in: Atom PDF