QUIC is not actively used between my nodes, while it should technically be possible. Here some more information:
Node 1 is behind a classic home-grade router, sometimes detected as:
quic_listen.go:54: INFO: quic://0.0.0.0:22000 detected NAT type: Full cone NAT
and most times detected as:
quic_listen.go:54: INFO: quic://0.0.0.0:22000 detected NAT type: Port restricted NAT
In any case, I get:
quic_listen.go:73: INFO: quic://0.0.0.0:22000 resolved external address quic://my_real_external_ip:61930 (via stun.syncthing.net:3478)
Node 2 is non-NATed and behind a connection-tracking firewall which expectedly drops untracked UDP, i.e. hole punching is required. Code detects that as
symmetric UDP firewall, which is correct (i.e. non-NATed). The constant in the code is misnamed, though (
NATSymmetricUDPFirewall) and it’s missing from
isCurrentNATTypePunchable. Adding it triggers STUN keepalives as expected.
Still, in no case I get connections apart from via relays.
Logs from node 1 trying to reach node 2 contain:
structs.go:220: DEBUG: dialing my_node_UUID quic://global_ip_address_of_node2:22000 error: context deadline exceeded
Node 2 trying to reach node 1 fails for a stupid reason. Node 1 is NATed, as mentioned. Another node (node 3) is directly reachable via
tcp://my_real_external_ip:22000 (port forwarding).
When node 2 tries to contact node 1, it also tries
tcp://my_real_external_ip:22000 when contacting node 1, believes the connection is successful, and only then realizes it has actually contacted node 3 again and drops the extra connection, never actually trying
quic to contact node 1.
Forcing node 2 to use
quic://my_real_external_ip:61930 to contact node 1 actually works fine(!), but of course is not maintainable, since ports are random.
In this case, also node 1 can now contact node 2 (QUIC client/server relationship), but this should technically also work vice-versa.
So I observe a series of issues:
- NAT detection seems to flap between full cone and port restricted for me.
- If two nodes are in the same private network advertising
tcp://my_real_external_ip:22000and one of them is directly reachable (e.g. through port forward), the other node will never be able to be directly reached e.g. via QUIC, since Syncthing gives up after the first “successful” connection even if it reaches a different node than what was targeted.
NATSymmetricUDPFirewallis not a NAT (misnamed).
NATSymmetricUDPFirewallis not considered punchable (but it is!).
- I encounter
error: context deadline exceededwhen trying to contact a node behind a symmetric UDP firewall via QUIC.