[Workaround] QUIC misconfigured

Node Operators FAQ
,
1

Continuing the discussion from Binding to a specific interface to stabilize QUIC connectivity:

Evidently, two things need to be true for QUIC to work:

  1. As indicated in the linked post, the interface address must be explicitly included in the server.address; e.g.:

    server.address: 10.0.17.120:28967

  2. The port advertised in contact.external-address and forwarded to the node must be the same. I.e. if you advertise port 28967 in contact.external-address: icecream.example.com:28967 you shall also use the same port in server.address and port forwarding rules/DNAT on your router.

This is on FreeBSD 13.3. YMMV.

2

So if the external port and internal ports are different, it stops working on some OS?

Because all three of my nodes have different ports:

  1. Windows service
  2. And two containerd (Rancher Desktop) nodes (WSL2 engine)

And the host (Windows) has many interfaces (two physical network ports, but only one is connected), including virtual (Hyper-V, WSL2, Wireguard).

3

Yes, it broke in the version from the linked post, and I read that the same trickaroo also helped some synology users. Today I was messing with routing, broke it again, in spite of the first workaround being still in place, and narrowed it down to the port…

4

Tried this on an older Syno and didn’t solve the problem. It’s the only Syno with QUIC missconfig.

2 Likes
5

It’s likely an ARM-based

6

Intel Celeron N3050…