search

openwrt / packages

Community maintained packages for OpenWrt. Documentation for submitting pull requests is in CONTRIBUTING.md
GNU General Public License v2.0
3.95k stars 3.46k forks source link

miniupnpd: Issues when adding IPv6 Firewall rules #9752

Open ffrediani opened 5 years ago

ffrediani commented 5 years ago

I have observed an issue when working with miniupnpd 2.1 package and OpenWrt 18.06 and trying to add IPv6 Firewall rules to allow traffic towards a device in the LAN:

When using a miniupnp client to make the request depending on the local IPv6 used for the target device it gives back a "code 606 (Action not authorized)".

When tested for example from a Windows Desktop which gets its IPv6 addresses by both RA (Stateless) and DHCPv6(Statefull). It had 3 addresses, 1 via DHCPv6 and 2 via SLAAC (those Temporary IPv6 Address). It only works for 1 of the addresses and not for the other two - one of the Temporary Addresses. This may be a problem depending on the IPv6 Address the application making the request takes in consideration to be used on the request. I even tried to disable "Enable secure mode" in miniupnpd configuration but it keeps giving the same error.

There should be some way for the miniupnpd daemon to check the request comes from the same IPv6 address requesting it and a the same device may have multiple of them. Even though when disabling secure mode it doesn't allow.

Maintainer: nobody Compile tested: ar71xx Run tested: TP-LINK Archer C7 v5

ffrediani commented 5 years ago

@ldir-EDB0 @neheb I saw you had some involvement with this package in other issue and wonder if you have any idea about

neheb commented 5 years ago

I have none.

ffrediani commented 5 years ago

Hi @neheb I took is based on #8533 and #8671 Anyway, perhaps if you have any input is welcome.

neheb commented 4 years ago

https://sources.debian.org/patches/miniupnpd/2.1-6/miniupnpd-allow-ipv4-listening-specify.patch/

I wonder if this can solve these IPv6 issues...

ffrediani commented 4 years ago

@neheb I am not sure if the problem is related to what interfaces it listen to.

The point it: in IPv6 often you have more than one IPv6 address in the same interface. Generally the one configured stateless via RA and another stateful via DHCPv6. So any incoming requests can come to any of them and the host will reply fine.

But in order to allow it through the firewall it is necessary to know which one is normally used for outbound connections.

Let me exemplify: I have an application who requires incoming connection (say a camera system) and to access it from external there is some DDNS system in the host. This system will update a AAAA record to point to one of the IPv6 addresses present in the interface. Then the application in the host with embedded upnp client requests the router to let traffic trough it with destination to that IPv6 address. The address it chooses to send the request to the router must match the same one the DDNS updated the AAAA.

This is just an example, but it could be a Torrent system, a Game who requires it to host a match in order for others to connect, etc.

So when any application with embedded upnp client functionality sends a request to add a rule in the firewall it must match with the outbound IPv6 address that application is talking to miniupnpd daemon.

neheb commented 4 years ago

In my attempt to convert miniupnpd to procd, I see this entry in the log: 

HTTP IPv6 address given to control points : [fd9f:300d:aab8::1]

My br-lan interface has three IPv6 addresses. an fe80 (link local), that one, and a 2002 one (this is a 6to4 tunnel). Something tells me that IP address is wrong...

ffrediani commented 4 years ago

Hi, not sure if it would have to do with ULA addresses, but to GUA addresses. The point is that the daemon has in some way to know what address the client is communicating to it (so the outbound address of the host) and use it for the PinHole. Is there anything that looks after miniupnpd within Openwrt now a days or is it currently without someone ?

neheb commented 4 years ago

Nobody is looking after it. Here's my procd attempt: https://github.com/openwrt/packages/pull/11275

At the end of the day, it works with transmission, but no real idea about IPv6 or whatever.

neheb commented 4 years ago

Now I get this error: Failed to convert hostname 'fd9f:300d:aab8::' to ip address. Apparently that's a hostname...

ffrediani commented 4 years ago

The ability of miniupnpd to understand the source IPv6 address that is requesting to add the PinHole in the firewall is even more important than in IPv4 because it has a functionality the if not turned off will not add the forward rule. So if the local upnp embed client picks a different IPv6 address and the one that communicates to the daemon are not the same it may refuse to add it, so it has to understand this extra complexity when using IPv6.

As in IPv6 there is no fixed internal IP, but Prefix Delegation it is slightly harder to work with a permanent IP for these rules to persist and the reliance on the upnp client information to match correctly is even higher.

neheb commented 4 years ago

Is this issue OpenWrt specific or miniupnpd specific?

ffrediani commented 4 years ago

Not sure yet if a bit of both.

neheb commented 4 years ago

If the latter, it should be reported upstream.

neheb commented 4 years ago

https://github.com/openwrt/packages/commit/c61614a849d1c7fc0cb6d0dafd79440a35bb5fc6 was merged. I assume this is still an issue?

ffrediani commented 4 years ago

Hi neheb thanks for the update. Will need to test with the snapshot version.

The issue as described is quiet simple actually. Just need to find out if anything on the commit changed the way miniupnpd server understands the request for a PinHole comes from a device with the same address it is requesting to add the PinHole.

My impression is that it only checks the client IP that is communicating to the miniupnpd server, but even disabling secure mode it still doesn't work as expected.

neheb commented 3 years ago

There was recently an IPv6 related fix. No idea if it fixes anything here.

Neustradamus commented 3 years ago

@ all: What is the status of this ticket?

ffrediani commented 3 years ago

@Neustradamus I will try to get an environment to validate if this has been fixed at least in the snapshot and in the 19.07.8 and 21.02.0 as well.

Neustradamus commented 3 years ago

@ffrediani: Have you checked?

frederictobiasc commented 2 years ago

The syntax for IPv6 Pinholes is different to NAPT, see https://github.com/transmission/transmission/issues/993#issuecomment-882843115 upnpc -6 -m enp0s31f6 -A 0 0 2a02:(...)aa:d5 5900 TCP 300 I can confirm that it works. Only thing left is a proper display of the forwardings in the corresponding luci addon. So could be closed?

tiagogaspar8 commented 2 years ago

Hi @ffrediani can you test this with the latest fix recently merged? it fixed IPv6 port opening on my setup with firewall4