Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NAT-PMP will only accept default gateway IP as IGD #5502

Open
joshbenner opened this issue Aug 30, 2022 · 6 comments · Fixed by #6946
Open

NAT-PMP will only accept default gateway IP as IGD #5502

joshbenner opened this issue Aug 30, 2022 · 6 comments · Fixed by #6946
Labels
bug Bug connectivity L1 Very few Likelihood P1 Nuisance Priority level portmap Pertaining to NAT-PMP, PCP, UPnP T3 Performance/Debugging Issue type

Comments

@joshbenner
Copy link

What is the issue?

Tailscale clients could not detect the UPnP nor NAT-PMP capabilities of my OPNSense failover pair of routers. UPnP & NAT-PMP were enabled, and other devices could discover and use these services.

I eventually discovered that the IGD response from the currently-primary router was coming from its LAN address instead of the gateway IP, which is a virtual (floating) IP that can failover to the secondary router. Because of this, tailscale client seemed unable to discover UPnP or NAT-PMP.

I successfully worked around this issue by forwarding port 5351/udp from the gateway IP to the primary router's LAN address, which allowed the tailscale client to discover NAT-PMP (but not UPnP).

I expected tailscale to detect these capabilities, or expose configuration to override its (arguably reasonable) default behavior to only accept the system's default gateway as IGD.

Steps to reproduce

  1. Use OPNSense in failover pair with virtual IP as default gateway.
  2. Enable UPnP & NAT-PMP in OPNSense.

Are there any recent changes that introduced the issue?

Unclear if this is recent behavior, though PR #3202 seems relevant.

OS

Linux, macOS

OS version

Ubuntu 22.04, macOS 12.5

Tailscale version

1.28.0

Bug report

No response
@StraightfaceStudios
Copy link
Contributor

StraightfaceStudios commented Sep 2, 2022 •
edited

Same issue.

This is partially an issue with OPN\PFSense. If you send a NAT-PMP request to the default gateway and the default gateway is a CARP IP nothing happens. You need to send the NAT-PMP request to the actual LAN interface.

https://redmine.pfsense.org/issues/13222

Other applications that have implemented UPnP don't seem to have any issues with UPnP (Parsec, various games and syncthing tested and confirmed to work on our network). I can see the response from PFSense to UPnP Searches:
SRC: [USER] DST: [CARP GATEWAY]
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900

And it gets a response correctly

HTTP/1.1 200 OK CACHE-CONTROL: max-age=120 ST: uuid:837 USN: uuid:837 EXT: SERVER: FreeBSD/12.3-STABLE UPnP/1.1 MiniUPnPd/2.2.1 LOCATION: http://192.168.##.NONCARP:2189/rootDesc.xml OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01 01-NLS: 1662155185 BOOTID.UPNP.ORG: 1662155185 CONFIGID.UPNP.ORG: 1337
Parsec then uses the correct UPNP IP and maps addresses. Tailscale though appears to just send endless requests to NAT_PMP none of which get a response due to PFSense issue 13222

@StraightfaceStudios
Copy link
Contributor

Further digging.

https://github.com/tailscale/tailscale/blob/5f6abcfa6f15cde7ab4dc4c94ec49b80e4639f8c/net/portmapper/upnp.go

	if ipp.Addr() != gw {
		return nil, fmt.Errorf("UPnP discovered root %q does not match gateway IP %v; ignoring UPnP",
			meta.Location, gw)
	}

Tailscale's UPnP implementation explicitly ignores situations where the CARP IP (Gateway IP) is different from the response IP (The specific router's UPnP Response)

@DentonGentry
Copy link
Contributor

The check of IP address went in via #2572, which was the first point where portmapping really worked. I suspect we can relax that check.

@bigfoxtail
Copy link

What is the issue?

Tailscale clients could not detect the UPnP nor NAT-PMP capabilities of my OPNSense failover pair of routers. UPnP & NAT-PMP were enabled, and other devices could discover and use these services.

I eventually discovered that the IGD response from the currently-primary router was coming from its LAN address instead of the gateway IP, which is a virtual (floating) IP that can failover to the secondary router. Because of this, tailscale client seemed unable to discover UPnP or NAT-PMP.

I successfully worked around this issue by forwarding port 5351/udp from the gateway IP to the primary router's LAN address, which allowed the tailscale client to discover NAT-PMP (but not UPnP).

I expected tailscale to detect these capabilities, or expose configuration to override its (arguably reasonable) default behavior to only accept the system's default gateway as IGD.

Steps to reproduce

  1. Use OPNSense in failover pair with virtual IP as default gateway.
  2. Enable UPnP & NAT-PMP in OPNSense.

Are there any recent changes that introduced the issue?

Unclear if this is recent behavior, though PR #3202 seems relevant.

OS

Linux, macOS

OS version

Ubuntu 22.04, macOS 12.5

Tailscale version

1.28.0

Bug report

No response

There is a similar problem with openwrt's miniupnp, may I ask what command you used for port forwarding. The forwarding command I used didn't work.

@StraightfaceStudios
Copy link
Contributor

Packet Source: LAN interface
Packet Destination: UDP | Gateway IP (192.168.1.1 or whatever) | Port 5351
Forward: LAN IP (192.168.1.2 or whatever) | Port 5351

@jwhited jwhited self-assigned this Dec 2, 2022
@DentonGentry DentonGentry changed the title Client will only accept default gateway IP as IGD Portmap client will only accept default gateway IP as IGD Dec 15, 2022
jwhited added a commit that referenced this issue Jan 12, 2023
@jwhited
net/portmapper: relax handling of UPnP resp
334924d 
Gateway devices operating as an HA pair w/VRRP or CARP may send UPnP
replies from static addresses rather than the floating gateway address.
This commit relaxes our source address verification such that we parse
responses from non-gateway IPs, and re-point the UPnP root desc
URL to the gateway IP. This ensures we are still interfacing with the
gateway device (assuming L2 security intact), even though we got a
root desc from a non-gateway address.

This relaxed handling is required for ANY port mapping to work on certain
OPNsense/pfsense distributions using CARP at the time of writing, as
miniupnpd may only listen on the static, non-gateway interface address
for PCP and PMP.

Fixes #5502

Signed-off-by: Jordan Whited <jordan@tailscale.com>
@jwhited jwhited mentioned this issue Jan 12, 2023
Merged
jwhited added a commit that referenced this issue Jan 13, 2023
@jwhited
net/portmapper: relax handling of UPnP resp (#6946)
25a0091 
Gateway devices operating as an HA pair w/VRRP or CARP may send UPnP
replies from static addresses rather than the floating gateway address.
This commit relaxes our source address verification such that we parse
responses from non-gateway IPs, and re-point the UPnP root desc
URL to the gateway IP. This ensures we are still interfacing with the
gateway device (assuming L2 security intact), even though we got a
root desc from a non-gateway address.

This relaxed handling is required for ANY port mapping to work on certain
OPNsense/pfsense distributions using CARP at the time of writing, as
miniupnpd may only listen on the static, non-gateway interface address
for PCP and PMP.

Fixes #5502

Signed-off-by: Jordan Whited <jordan@tailscale.com>
coadler pushed a commit to coder/tailscale that referenced this issue Feb 2, 2023
@jwhited @coadler
net/portmapper: relax handling of UPnP resp (tailscale#6946)
d194994 
Gateway devices operating as an HA pair w/VRRP or CARP may send UPnP
replies from static addresses rather than the floating gateway address.
This commit relaxes our source address verification such that we parse
responses from non-gateway IPs, and re-point the UPnP root desc
URL to the gateway IP. This ensures we are still interfacing with the
gateway device (assuming L2 security intact), even though we got a
root desc from a non-gateway address.

This relaxed handling is required for ANY port mapping to work on certain
OPNsense/pfsense distributions using CARP at the time of writing, as
miniupnpd may only listen on the static, non-gateway interface address
for PCP and PMP.

Fixes tailscale#5502

Signed-off-by: Jordan Whited <jordan@tailscale.com>
@StraightfaceStudios
Copy link
Contributor

NAT-PMP still fails with #6946 merged.

@DentonGentry DentonGentry changed the title Portmap client will only accept default gateway IP as IGD NAT-PMP will only accept default gateway IP as IGD Jun 30, 2023
@DentonGentry DentonGentry reopened this Jun 30, 2023
@DentonGentry DentonGentry added the portmap Pertaining to NAT-PMP, PCP, UPnP label Sep 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Bug connectivity L1 Very few Likelihood P1 Nuisance Priority level portmap Pertaining to NAT-PMP, PCP, UPnP T3 Performance/Debugging Issue type
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

net/portmapper: relax handling of UPnP resp tailscale/tailscale
5 participants
@joshbenner @DentonGentry @StraightfaceStudios @jwhited @bigfoxtail