Help test incoming udp issue on specific tierhive SG node

mhubud

Hi folks, I've been trying to troubleshoot issues with incoming udp (wireguard) on one sg node (51.79.162.49). If anyone else has a moment to build a vm on this node and perform these tests, I would appreciate it.

I'm not sure if it's me (apologies in advance if so) or if it's related to the this node being unique from others (it has advanced ddos according to ant). And yes, we've been corresponding about it.
I have tested the exact same setup (which isn't much, just wg on new deb13 vps) on other Tierhive nodes and it works fine. The issue is specific to this node/network. That said, Ant says there are hundreds of instances on this node so it would be surprising if no one else has witnessed this behavior (since others must also be using for wg right?). I agree, but I've been able to consistently reproduce the issue many times. So that's why I asking for a couple people to test.

What I describe below ONLY happens on new instances built on SG node 51.79.162.49 (which essentially is the default node for new instances in SG). This behavior does not exist on other nodes in SG nor 3 other Tierhive locations I tested. Also if the vps is created on 51.79.162.49 and the inbound udp issue exists but then the vps is moved to a different node in SG, then it works fine.

Basically with my testing, even with a fresh vps with nothing installed/configured other than wireguard, new inbound UDP packets never arrive to the vps from a client ip that hasn't already communicated with 51.79.162.49. So if you setup a wg server here, it will only work if you perform some out-of-band connection between 51.79.162.49 and the client ip. Once any kind of non-udp communication happens between them, then wireguard/udp starts flowing.

Here is what I do and would like someone else to do/test:

• Create new instance in SG (verify after that it's on 51.79.162.49)

  Debian13, default ram/disk, all low performance settings

• Install/setup wireguard (I'm using angristan script)

• Create at least 2 client configs
• Setup the port forward in web panel
• Change the wg client configs to use forwarded port
• Test wgclient1 just to make sure wg is working. For initial test, this must be done from the SAME internet IP that you used to ssh into this testvps.
• Disconnect wgclient1 from wg and reconnect to testvps via ssh (from same IP).
• Fire up tcpdump -n udp.

Now what we're going to do is test wg connection from a client using an internet IP that is NOT coming from the same internet IP that you connected to your testvps via ssh.

• It is very important that there have not been ANY communications between 51.79.162.49 and this client/IP recently (I'm not sure the duration yet).
• Copy wgclient2 config to client device 2 on a different network (or how ever you want as long as this device will connect via wg from a different internet IP than client 1. Again, you must not communicate between 51.79.162.49 and client2 device yet.
• Now Connect to wg from wgclient2/device 2/separate internet ip.
• Viewing your already running ssh/tcpdump session on testvps, note whether or not the udp traffic is appearing. In my case, there is no inbound udp traffic. Let it run a bit if you want.

Assuming the wg udp packets are not arriving (keep tcpdump running/watching on testvps ssh session from device1), then perform one of these tests:

• ping or tcp connect from the testvps on 51.79.162.49 to the internet ip of client2.
• tcp connect (not ping) from a different device on same network as client2 to 51.79.162.49.

Upon non-wg/udp traffic initiation, then wg traffic between client2<>51.79.162.49 will start flowing.

To retest, it does not matter if you restart wg on vps or restart the vps, the inbound udp traffic will continue to work for a while. Eventually however, when there has been no communications between 51.79.162.49 and client2 for a while, then if you retest the same thing will happen (inbound udp connections to vps won't reach vps unless an out of band connection happens).

I have tested this from 5 different client devices (mac, pi, vps) on numerous ip networks in different locations. I have built and tested 3 new vps instances on 51.79.162.49 with the same results.

But I'm curious what others find. Thanks!

PS (only if using another vps as a wg client test):
Don't forget if you test wgclient2 from another vps, you need to add rules in ur wgclient config on that client vps so you don't lose ssh access once you up the wg client. Several of my tests were on non-vps devices, so not necessary.

tulipyun

Maybe you should try using Codex or Claude?

natboxio

Great

AnthonySmith

Ok cool, happy for testing to be outsourced

Just as a little bit of extra information, for any OVH experts, the unique thing about this server is the OVH game ddos protection.

I say unique, but that's on in Australia too but apparently it doesn't have the same impact there.