Traffic goes through relay instead of peer to peer, what could cause this?

[mailinglists35]

This is a discussion question, not a bug.

I tried sending and immediately remarked that throughput is very slow.

Found out the traffic goes via the relay and not between peers.

Does this mean none of the peers router managed to create a reliable nat udp mapping?

I tried again with a different peer and it worked. But the first peer always got relayed and never managed to do direct link. I am behind enterprise Fortigate firewall and peer is behind some other enterprise firewall. The second test peer that got connected: direct is behind a home router with proper nat-pmp and upnp support.

2021/01/12 15:10:19 got A pake msg (48 bytes)
2021/01/12 15:10:19 have key, sent B pake msg (32 bytes)
2021/01/12 15:10:19 sent offer
2021/01/12 15:10:19 sent new local candidate: udp4 host MY_LOCAL_IP1:34591
2021/01/12 15:10:19 sent new local candidate: udp4 host MY_LOCAL_IP2:49317
2021/01/12 15:10:19 sent new local candidate: udp4 host MY_LOCAL_IP3:36061
2021/01/12 15:10:19 sent new local candidate: udp4 host MY_LOCAL_IP4:48562
2021/01/12 15:10:19 sent new local candidate: udp4 host MY_LOCAL_IP5:41764
2021/01/12 15:10:19 sent new local candidate: udp4 srflx MY_EXTERNAL_IP:53799 related 0.0.0.0:53799
2021/01/12 15:10:19 sent new local candidate: udp4 srflx MY_EXTERNAL_IP:38761 related 0.0.0.0:38761
2021/01/12 15:10:19 sent new local candidate: udp4 relay 157.245.15.73:56906 related 0.0.0.0:38783
2021/01/12 15:10:19 got answer
2021/01/12 15:10:19 received new remote candidate: candidate:1714356938 1 udp 2113937151 5b235b89-f44b-4b02-a3e2-a6f6120f7e4c.local 56259 typ host generation 0 ufrag K979 network-cost 999
2021/01/12 15:10:19 received new remote candidate: candidate:842163049 1 udp 1677729535 PEER_EXTERNAL_IP 18481 typ srflx raddr 0.0.0.0 rport 0 generation 0 ufrag K979 network-cost 999
2021/01/12 15:10:19 received new remote candidate: candidate:797711510 1 udp 33562367 157.245.15.73 50882 typ relay raddr PEER_EXTERNAL_IP rport 18481 generation 0 ufrag K979 network-cost 999
2021/01/12 15:10:22 webrtc connection succeeded, closing signalling channel
connected: relay
sending checksums.sha256... done
sending checksums.sha1... done

[mailinglists35]

Does this mean none of the peers router managed to create a reliable nat udp mapping?

And if yes, is there anyway a cheat like this can be implemented?:

Manually specify a binding UDP PORT and IP address as arguments to ww to tell the peer to connect to (so you tell the peer, "look, here is an IP and PORT where you should attempt to get the SCTP data stream from")
And before that I do some socat and ssh with port forwarding to some same geographical area server where I have access so I can force the traffic through that? (since ssh cannot do UDP which is required for SCTP, socat can be used to convert to/from tcp <-> udp)

what do you think?

[saljam]

Does this mean none of the peers router managed to create a reliable nat udp mapping?

that's correct. that's the case with some enterprise nats. aka symmetric nat or "endpoint-dependent mapping" in the naming from rfc4787. there's unfortunately not much we can do to traverse them automatically.

home router with proper nat-pmp and upnp support.

aside: this (i.e. webrtc) only uses stun, which only relies on the nat table being "well-behaved". nat-pmp and upnp are unnecessary and aren't used at all.

Manually specify a binding UDP PORT and IP address as arguments to ww to tell the peer to connect to

interesting idea! i think it might be worth a try. especially if it's just a matter of injecting a remote candidate in one peer to try.

that said, i'd like to spend some time looking into why the relay server is slow for some. there's reason why it should be since it's well connected and lightly loaded.

[mailinglists35]

why the relay server is slow for some.

probably long distance links and higher chances udp traffic being treated different at some router across the route?

I can setup a iperf3 server if you want to dig it for this particular case. If you think you have good bandwidth at the relay server then I suspect the cause is either the traffic going from europe to us and back and/or maybe not guaranteed udp throughput at my isp?