Innernet client not reporting the public IP to the server for NAT traversal

[fersingb]

Hello,

When I list the peers in my network, the endpoint that is reported is the private IP, not the public IP. I also checked the database on the server and couldn't find any info about the peer's public IP.

Those peers are NATed and I thought the client would try to detect the public IP and report it to the server (or the server use the seen IP) so that all peers could connect to each other using NAT holepunching. Am I misunderstanding something here? Right now my setup consists of a server and 2 clients. All was working well as long as the clients were on the same LAN, however now I just tried with one client on an other LAN and it doesn't work anymore.

What's the intended behavior and how do debug this issue? I'm using the latest version: 1.5.2 on Linux

Thank you,
Boris

[strohel]

Hi Boris, this is a good question.

The discovery of public IP of each peer is done by the server itself - it simply assumes it is the IP of the incoming connection. In other words, there is an assumption that the innernet server is reached by clients via public internet. Perhaps your clients reach the server via a private network? See #115 (comment) for a better explanation from @mcginty.

Some basic NAT traversal has been added since then, but it should be still considered a basic level: AFAIK it currently only helps for peers on the same private network to communicate with each other. Please see the following issue for tracking NAT traversal efforts in innernet

• NAT traversal [tracking issue] #109

[fersingb]

Hi @strohel,

The clients reach the server via public IP. The wg command on the server correctly shows the public IP as endpoint for both clients.

When you say the nat traversal logic is very basic, do you mean it doesn't actually work?

Can I expect 2 peers to connect to each other if they are both behind a NAT (different NAT/LAN, different public IP) without any port forwarding set up?

[strohel]

Thanks for adding extra context, that explains it I think.
Currently communication between 2 NAT-ed clients only works if at least one of these two conditions holds:

• at least one of the clients has port forwarding set up for their NAT
• the clients are on the same private network (this was enabled by 1.5.0 and tweaked in later releases)

(edit: corrected the first condition)

[fersingb]

Oh, thanks @strohel , I think that explains it.

I was hoping for NAT traversal support after reading the innernet introduction article, maybe I misunderstood it. Anyway, it's nice that the feature is planned and WiP. I'll try to contribute to it if I find some time.

Cheers,
Boris

[strohel]

Glad this has been cleared up! Contributions of any form are of course very welcome.

I'll go ahead and close this as #109 works as the main tracking issue.

[alerque]

I think there is more to this problem than noted above. At any given time I have several peers shoring 192.168.x.x addresses in my list, and they are not necessarily the peers that happen to be in the same network that I am running innernet list from. Clearly these do NOT come from the innernet server as that in only reachable via a real world IPv4 address, there is no way the server can see the 192 addresses, and they are not discoverable via the local network, so the peer (or other peers on the same network) are reporting those to the server somehow.

Incidentally the WG links to these peers work even though I know the endpoint addresses are bogus and unreachable.

[strohel]

@alerque I think that what you see above is the

• NAT traversal: ICE-esque candidate selection #134, server: candidate reporting #151: Peers and servers now report local IP addresses for establishing connections within the same NAT. Local networkers rejoice!

...entry from https://github.com/tonarino/innernet/releases/tag/v1.5.0 (1.5.0 release notes).

Note that explanation above in this issue only relates to how the server determines the public IP of the clients. The clients also report addresses of their local interfaces.

[alerque]

@strohel Thanks for the clarification on that. I did notice (and rejoiced) that local networking was working well, just the innernet list output is a bit spastic because what gets reported in that output isn't consistently one or the other.

[strohel]

just the innernet list output is a bit spastic because what gets reported in that output isn't consistently one or the other.

AFAIK innernet list (or show) reports the currently used (or tried) endpoint address of each peer. For reachable peers this is the correct address. But for unreachable ones, it seems that the "try each IP candidate after another" algorithm tries the client-reported local IP address (like 192.168.0.13) as the last ones, and leaves them assigned, which is confusing.

I think the last aspect definitely could/should be improved. I say contributions would be welcome here (but note I haven't yet consulted that with @mcginty).