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.

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

UPNP_GetValidIGD returns Temporary IPv6 Address, causing UPNP_AddPinHole to fail with 606 #600

Closed
Memnarch opened this issue Feb 28, 2022 · 9 comments
Assignees
Labels
miniupnpc windows bug related to MS Windows build

Comments

@Memnarch
Copy link

Platform: Windows 10 x64 21H2
Local-Sourcestate: Commit 51f185f

As I wanted to work with IPv6, I used UPNP_AddPinHole and ended up with it returning 606 ("Authorization required")

After digging into it, I found out that my IF has 2 IPv6 addresses. A "Normal" one and a "temporary" one (according to IPCONFIG).
The LanAddr argument of UPNP_GetValidIGD is filled with the temporary one, which seems to be the cause of it failing. When I used my normal one, by hardcoding it, it worked. Though UPNP_DeletePinHole would still fail with 606, so I ended up working around that by updating a pinhole with a leasetime of 1.

I walked through the code but haven't found the exact issue, yet.
Using the "empty" Wildcard for intClient, instead of my local lanadrr failed with 402 ("Invalid Args")

@Memnarch
Copy link
Author

Memnarch commented Mar 31, 2022

I worked around this by grabbing the first normal IPv6 address, for now.
However, this allows me to use UPNP_AddPinhole, only. Update/Delete have no IP argument. It seems the underlying code will send the request using the temporary IPv6 and the router will decline the request with a 606. My workaround, which works most of the time, is to call AddPinhole with a leasetime of 1 when I want to delete it, which seems to do the job.
At least most of the time. Seems sometimes a port may stay behind with the leasetime i specified when I called AddPinhole for opening it.

So this is still not solved for me, completely :/

@miniupnp miniupnp self-assigned this May 1, 2022
@miniupnp miniupnp added miniupnpc windows bug related to MS Windows build labels May 1, 2022
@miniupnp
Copy link
Owner

miniupnp commented May 1, 2022

@Memnarch what is the IGD implementation your router is running ?

@Memnarch
Copy link
Author

Quite possibly a MiniupnpD (and older router from that company was using that so I assume the newer one does aswell).
Though, what's the best way to check that?
Sorry for the late reply.

@miniupnp
Copy link
Owner

$ upnpc -s
upnpc : miniupnpc library test client, version 2.2.3.
 (c) 2005-2021 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
 desc: http://192.168.11.254:5678/desc/root
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

open the description url in your browser you should see the various informations

@Memnarch
Copy link
Author

So all i can see are the keywords
SpecVersion: 1.0
"FRITZ!Box" (That's the router family)
"AVM Berlin" (That's the company producing them)
"AVM IGD" (?)

I have attached the document(with .txt because github can docx but .xml is invalid for some reason as filetype..yay?)
igddesc.xml.txt

Regarding (temp)IPv6 and what I understood sofar, just so we are on the same page:
My Windows 10 OS has Temporary IPv6 enabled(which is the default it seems). Therefore my interface has a normal IPv6 (the one I want) and a temporary one windows shuffles around once in a while. All outgoing requests, by default, are made using that temporary IPv6 it seems. A router on the other hand, usally only knows you by the original IPv6 it assigned to your device. So any request coming from that temp IPv6 is an unknown participant.
Did I get that right?

@miniupnp
Copy link
Owner

There is no "temporary" address regarding IPv6 protocol and routing. one address may be temporary if you change it, but that doesn't change anything for routing.

With IPv6 a host has typically at least 2 addresses :

  • one link local address fe80::/10 which is specific to the network interface (which means you have at least one of such address per network interface)
  • one global address 2000::/3 which is routable on the internet.

the link local address has no meaning on the internet, so for adding a pinhole the global address must be used.

The global address can be "temporary" (change from time to time) to avoid being used as an identifer.

@Memnarch
Copy link
Author

Memnarch commented May 19, 2022

In regards to temporary, I am talking about how windows 10 handles them.
grafik
Translation:
IPv6-Adresse -> IPv6-Address
Temporäre IPv6-Adresse -> Temporary IPv6 Address
Verbindungslokale IPv6-Adresse -> Linklocal IPv6-Address
IPv4-Adresse -> IPv4-Address
Subnetzmaske -> Subnetmask
Standardgateway -> Standardgateway

When I do a request, the "temporary" v6 address is used. Windows changes and manages it from time to time by itself. An Interface can have any number of temporary addresses windows desires. The router has given my computer the first IPv6 Address. That one is the one the router is aware of. The temporary one seems to be rolled by windows.

Creating pinholes with this temp address is not possible as that address is not known to the router, but it's the one returned by GetValidIGD. I assume because of the fact the initial request was done using that IP. If I use the first address, I can create a pinhole.

My current workaround is to go through the interfaces and pick the one i guess is the right one and use that interface IPv6 address instead of the one returned by GetValidIGD

@miniupnp
Copy link
Owner

@Memnarch the temporary IPv6 address looks perfectly routable, so there is no reason not using it, except if there is some special feature on your router that it forbid pinhole on an address it has not assigned. So the problem is with your router, you should contact AVM about it.

Generally speaking there is no need for an IPv6 address to be assigned by the router to be globally routable, it only needs to have the correct prefix.

Also, to my knowledge, there is no way for miniupnpc to know which IP is a "temporary one" and which one was assigned by the router. It takes the one used by default by the OS.

@Memnarch
Copy link
Author

except if there is some special feature on your router that it forbid pinhole on an address it has not assigned

That seems to be the issue, here. My workaround is to try every routable IPv6 and see which one ends up in an "OK". I then keep that in mind and use it for pinholes. Seems that's the only way for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
miniupnpc windows bug related to MS Windows build
Projects
None yet
Development

No branches or pull requests

2 participants