Setup node through a VPN

Node Operators troubleshooting
, ,
1

I can’t setup port forwarding due to my ISP restrictions so I try using port forwarding with ProtonVPN. I can’t chose the port so I have to use the one proton gives me, I tried running the container like this but throw me this error

QUIC is misconfigured. You must forward port 28967 for both TCP and UDP to enable QUIC.

I ran the docker like this

sudo docker run -d --restart unless-stopped --stop-timeout 300 \
    -p 51637:28967/tcp \
    -p 51637:28967/udp \
    -p 127.0.0.1:14002:14002 \
    -e WALLET="" \
    -e EMAIL="" \
    -e ADDRESS="storj-test.zapto.org:51637" \
    -e STORAGE="2TB" \
    --user $(id -u):$(id -g) \
    --mount type=bind,source="/home/miguel/.local/share/storj/identity/storagenode/",destination=/app/identity \
    --mount type=bind,source="/home/miguel/storj/storage",destination=/app/config \
    --name storagenode storjlabs/storagenode:latest

Docker and proton has differents network interfaces, I don’t know if that can be a problem

2

What port can you use? You need to use the same port everywhere if you want QUIC to have a chance of working. Use the same port in forwarding rules, in advertisement, and in server.address.

1 Like
4

You also need to adjust external address and server address.

5

I don’t think this is a general rule. I have 16 ubuntu/docker nodes using vpn with a random port assigned on vpn login. Those random ports are forwarded to the default storj port without any quic problems.

6

I’m not saying it won’t work unless you do it; otherwise the node software would not pass QA.

I’m saying that due to the nature of QUIC being a protocol on top of another protocol, that therefore has no idea about QUIC, and all the network stack it works on does not know about quic, quic has to do a lot of work to figure how how and where to route packets. The fewer challenges you present to it the higher chances of it working. Swiss cheese model - Wikipedia.

Having multiple interfaces and multiple forwards are evidently enough on some platforms to derail it.

Obviously, if it works for you repeatedly and reliably – don’t change anything. But this topic contains “QUIC Misconfigured” wording. So it does not work reliably. And therefore, giving QUCK best chances is a way to go.

7

I’ve used protonvpn for several months and I’ve never managed to get QUIC to turn green.
The node worked fine, but with a red QUIC.

8

Can you confirm that you:

  • bound to explicit interface?
  • keep the port number unchanged all the way to the node process?
  • Increase UDP buffer size to 64 megabytes or more?

And what OS are you using? Which VPN protocol?

9

@arrogantrabbit,

Mikrotik chr’s public IP address, say 123.123.123.123
Wireguard1 interface 192.168.43.3

Wireguard2 interface on the local Mikrotik address 192.168.43.4

Ping Mikrotik chr and the local Mikrotik address can now be done via the Wireguard connection

Forwarding is enabled
NAT has been set
Mikrotik local network IP address 192.168.60.0/28
PC/SNO IP address 192.168.60.14 running on windows 10
Storj external contact address points to 123.123.123.123:28967
server.address: 192.168.60.14:28967
MTU wireguard interface 1420

Everything works smoothly on Storj version 1.130.8,
status online but QUIC is misconfigured on version 1.131.7.

log error :
“contact: failed to ping storage node using QUIC, your node indicated error code: 0, rpc: quic: timeout: handshake did not complete in time”}

how fix it ?

10

Interesting, your microtik is handling VPN and DNAT? Does it also send all traffic from the node intothe same tunnel?

I would try reducing mtu to 1380 or 1300 for the tunnel.

Also disable Windows firewall to remove it from the picture altogether.

Also confirm this

11
  • Adjust MTU to 1280
  • Windows firewall has been set
  • DefaultReceiveWindow = 100000000
  • DefaultSendWindow = 100000000

Everything has been done but QUIC is still misconfigured.

12

Excellent.

Next steps:

  • remove Mikrotik from the picture. Run vpn client directly on the host where node is.

If this works — you’ll need to look into what does microtic do with QUIC udp packets.

If it does not — that gets more interesting, and having everything on one host makes it much easier to troubleshoot. I almost wish it should not work locally either.

You would want to capture udp packets arriving and departing on storj port and check for types 0, 1, 2, and 1c. You would not be able to decrypt the packets easily but just seeing handshakes and connection close shall suffice for our purposes. You want to ensure that the packets arrive at the correct interface and leave through the correct interface. How familiar are you with tcpdump/wireshark?

As a long shot you can read changelist of the go-quick between the versions in the storj regression range, but i don’t think you’ll find anything useful there, it’s pretty random and depends on environment. For me QUIC has been absolutely solid, but I don’t use windows.

13

okay, i will try it, thanks @arrogantrabbit