Connection failure when listening on multiple interfaces and overriding host candidate

[streamer45]

Connection failure when listening on multiple interfaces and overriding host candidate

[cnderrauber]

If you have multiple interfaces to listen on, don't use a single external address to call SetNAT1To1IPs, which override your candidates. And it will cause another port conflict issue like this:

You have interface IA, IB, both mapping to IC. Two clients 1 and 2.
client 1 get server candidates IC:34567(from IA), IC:45678(from IB)
client 2 get server candidates IC:34567(from IB), IC:45678(from IA), because when pion allocateing port for client2, IA:45678 and IB:34567 are free to use, but when they mapped to IC, will conflict with client1's address and failed to connect.

The better way is (what we are doing now):

1. enumerate the interfaces you are going to use. (IA, IB, IC)
2. resolve external address for each interface (by public stun server) (IA -> EA, IB ->EB, IC -> EA)
3. SetNAT1To1IPs with mapping pair instead of a single external address, and if you have two interface resolved to same public address, only map the first one and keep the other one map to itself. SetNAT1To1IPs([]string{EA/IA, EB/IB, IC/IC})

[streamer45]

Very interesting, I wasn't aware SetNAT1To1IPs supported more advanced parameters like pairs but now it makes all sense. I'll definitely give this a try, thank you!

[streamer45]

@cnderrauber That "trick" seems to work nicely. Out of curiosity, would it be acceptable to map the first interface (e.g. IA) as EA/IA and any subsequent interface to itself (IB/IB, IC/IC, and so on)? I am thinking of a scenario where resolving the external address is not possible (e.g. blocked outgoing ports) and the user will explicitly provide a single public IP instead.

[cnderrauber]

@streamer45 It will definitely work if your IA can be accessed from EA by public clients.

[streamer45]

Very well, this was extremely helpful, thank you again. We can close this one :)