2

I have several windows 10 machines with (A) 1Gbs and (B) 40Gbs networks cards. The cards are on different networks, but both provide a path to same router.

The router has 4 networks, WAN, (C), (A) and (B) above. Routing is possible between A, B and C. (A) is configured with the gateway.

From the 3rd (C) network I am having trouble communicating with the (A) 1Gb network, its like packets are routed ok at first, then routed via the faster (B) network which confuses the Windows 10 OS when it gets responses from an address it did not connect to, these are then dropped and communication just hangs.

It is important to note that machines on the (A) + (B) networks are choosing to switch routes back to (C) via (B) even though the conversations started on (A).

To be clear:

  • This is not a routing problem, everything can ping everything
  • This is not a connectivity problem, for example - from (C) I can RDP into (A) and (B), but - only connections to (B) are stable. (A) connects, and after a few frames (packets?) it hangs.
  • CIFS File copies have no issue, but then again Windows will route copies across the fastest routes - its designed to handle this...
  • Windows Server expects multi-homing it seems and does not behave like this, only windows 10 machines do

So, RDP - representative here of a package that does not expect the routes to switch, does not handle this.

There must be a configuration switch somewhere to get the machines to not switch interfaces. I dont care if I lose performance on CIFS, if I need speed and the route is available I will target the (B) network.

How can I fix this?

Improve this question
6
  • The windows 10 machines have two interfaces...which one is configured with a gateway?
    – Larryc
    Jan 30, 2019 at 5:13
  • The "gets responses from an address it did not connect to" part is a bit strange. If this happened for a TCP connection, that would be a severe bug in the network stack. Sending a packet through the wrong interface is a common problem in multihoming, yes, but generating that packet with the wrong source address is something entirely odd. There is no SNAT in any of your networks, is there?
    – u1686_grawity
    Jan 30, 2019 at 5:28
  • (A) is configured with the gateway.
    – Inquisitor Shm
    Jan 30, 2019 at 5:47
  • @grawity - "gets responses from an address it did not connect to" is a guess, a bad one most likely. Any suggestions on where to look at what is going on? Router is PFSense, A is gig network, B is Infiniband, C is wifi. Router has 4 cards, only Windows 10 machine exhibit this issue and only from C and A. Have tried with and without TCP over netbios (just in case).
    – Inquisitor Shm
    Jan 30, 2019 at 5:51
  • Guesses don't count; install Wireshark or tcpdump and look at the actual packets being transmitted.
    – u1686_grawity
    Jan 30, 2019 at 5:54

1 Answer 1

Reset to default
2

I was right about the guess, I guess 35 years of hard earned 50-60 technical hour work weeks has its effect on guesswork.

RDP Servers (the host machine being logged into) will attempt to detect the fastest route by sending packets back to clients on all interfaces, in both UDP and TCP. At some point in time, one of these machines on the A+B networks consistently makes a decision to favor B for returning calls coming in on A.

I know TCP itself does not support this, but in fact, RDP - the protocol, does.

So, the solution:

On clients: Open gpedit -> Computer configuration -> Administrative Templates\ Windows Components \ Remote Desktop Services\ Remote Desktop Connection Client and Turn Off UDP on Client

On Servers / Hosts (In my case, on all 4 headless Windows 10 'servers') Open gpedit -> Computer configuration -> Administrative Templates\ Windows Components \ Remote Desktop Services\ Remote Desktop Session Host \ Connections and

  • Select Network Detection on the server -> Enabled & Turn Off Connect Time Detect and Continuous Network Detect
  • Select RDP Transport Protocols -> Enabled & Use TCP Only

Now, I dont have to worry about the servers trying to select paths on the 40Gb network (which is for kubernettes in any case) halfway through a conversation.

I found problems with 1803 (occasional) and could not work at all on 1809.

I composed this 'Answer' using an RDP connection from one the headless machines.

Works like a charm now...

Improve this answer
0

You must log in to answer this question.

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