1

I currently have a network with the following topography: topography

Networking is fine and all works well, except for one thing: UDP seems to be unstable/not working on the subnets 192.168.3 and 192.168.4.0. The way that these subnets are setup is that my Windows Server instance has two (virtual) NIC's that act as gateways for their designated subnets. These subnets are statically routed in dd-wrt like this: static routing.

I cannot seem to be able to figure out why UDP is so unreliable on these subnets while it works just fine on the main net (192.168.2).

Any help or explanation as to why this is happening would be greatly appreciated!

EDIT:

For anyone wondering, this is the result of packetlosstest, as can be seen in the image, as soon as it has sent 50 packets, all subsequent traffic is cut off: enter image description here

10
  • Could you explain more detailed what exactly you mean with „unstable / not working “?
    – Martin
    Feb 13, 2021 at 17:38
  • @Martin Ok so, the way I tested this was as following, I setup a continuous ping to 8.8.8.8 on a machine that's on the 192.168.4 subnet. Then I setup a OpenVPN connection. At first I set the configuration to TCP only. This results in expected behaviour: the packets are dropped during the connecting phase but the ping will continue running normally once connected. However, when I select UDP it starts going wrong. Again packets are dropped when I connect. After that I manage to consistently receive 4 packets before the ping starts to timeout. This behaviour is also seen in UDP based games.
    – Teitoku42
    Feb 13, 2021 at 17:46
  • The behavior in your comment sounds exactly normal. TCP will adjust transmission to network congestion, but UDP has no way to do that.
    – Ron Maupin
    Feb 13, 2021 at 18:13
  • @RonMaupin Ok, but how would I make it work consistently though? Clearly the way that UDP seems to be behaving now is very undesirable.
    – Teitoku42
    Feb 13, 2021 at 18:22
  • The problem is that your incoming bandwidth is already used by the time you see the traffic, TCP being dropped due to congestion will slow the TCP transmission, but you simply cannot do that with UDP. You could try to get more bandwidth, or you will need to work with your upstream provider to drop UDP before it reaches you. In any case, I'm not sure why you allow employees to play games on your business network. You could try to block gaming.
    – Ron Maupin
    Feb 13, 2021 at 18:30

1 Answer 1

0

The static routing is okay - otherwise the TCP testcase wouldn't work. What I meant was the dynamic routing:

  • client 192.168.4.111 sends a UDP packet to 8.8.8.8
  • on the windows server, the source ip is translated to 192.168.2.2, and a dynamic source port is assigned.
  • any response on that port is routed back to the client.

This process is called masquerading - and such a dynamic route has a timeout - if no response is received on that source port for a certain amount of time, the dynamic port is closed. Usually, this timeout setting is configurable. And: This timeout setting is different to TCP, since UDP doesn't know any connections. I do not know where to setup this timeout on windows ... If I were you, I would install wireshark on your windows server. If your wireshark sees a response which is not received by your client, you know that this timeout is the cause.

3
  • Hey Martin, I did some more testing and unfortunately my assertion about it not disconnecting when the packets are sent fast enough wasn't true. It seems that around 1 out of the 5 tests I run completes successfully. I tried playing around with the UDP timeout limits on my router as well (unfortunately to no avail). I should also note that my Windows Server isn't actually doing the routing itself, it is simply a host for the subnet gateway NICs.
    – Teitoku42
    Feb 13, 2021 at 22:06
  • your dd-wrt router is not the cause... I am pretty sure the reason must be hidden somewhere in your windows server, because otherwise these issues would appear on the 192.168.2.0/24 subnet, too!
    – Martin
    Feb 14, 2021 at 9:39
  • One thing I forgot to mention is that the server instance runs on a VM, so the internet connection for the server and those two (virtual) NIC's get pushed over one line. Do you think that that might cause the issue?
    – Teitoku42
    Feb 14, 2021 at 16:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .