Windows 10 multihomed routing - RDP black screens, locking and connection timeouts
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?
windows-10 ip routing windows-server multi-homed
|
show 1 more comment
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?
windows-10 ip routing windows-server multi-homed
The windows 10 machines have two interfaces...which one is configured with a gateway?
– Larryc
Jan 30 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?
– grawity
Jan 30 at 5:28
(A) is configured with the gateway.
– Inquisitor Shm
Jan 30 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 at 5:51
Guesses don't count; install Wireshark or tcpdump and look at the actual packets being transmitted.
– grawity
Jan 30 at 5:54
|
show 1 more comment
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?
windows-10 ip routing windows-server multi-homed
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?
windows-10 ip routing windows-server multi-homed
windows-10 ip routing windows-server multi-homed
edited Jan 31 at 4:15
Inquisitor Shm
asked Jan 30 at 4:38
Inquisitor ShmInquisitor Shm
3382414
3382414
The windows 10 machines have two interfaces...which one is configured with a gateway?
– Larryc
Jan 30 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?
– grawity
Jan 30 at 5:28
(A) is configured with the gateway.
– Inquisitor Shm
Jan 30 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 at 5:51
Guesses don't count; install Wireshark or tcpdump and look at the actual packets being transmitted.
– grawity
Jan 30 at 5:54
|
show 1 more comment
The windows 10 machines have two interfaces...which one is configured with a gateway?
– Larryc
Jan 30 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?
– grawity
Jan 30 at 5:28
(A) is configured with the gateway.
– Inquisitor Shm
Jan 30 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 at 5:51
Guesses don't count; install Wireshark or tcpdump and look at the actual packets being transmitted.
– grawity
Jan 30 at 5:54
The windows 10 machines have two interfaces...which one is configured with a gateway?
– Larryc
Jan 30 at 5:13
The windows 10 machines have two interfaces...which one is configured with a gateway?
– Larryc
Jan 30 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?
– grawity
Jan 30 at 5:28
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?
– grawity
Jan 30 at 5:28
(A) is configured with the gateway.
– Inquisitor Shm
Jan 30 at 5:47
(A) is configured with the gateway.
– Inquisitor Shm
Jan 30 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 at 5:51
@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 at 5:51
Guesses don't count; install Wireshark or tcpdump and look at the actual packets being transmitted.
– grawity
Jan 30 at 5:54
Guesses don't count; install Wireshark or tcpdump and look at the actual packets being transmitted.
– grawity
Jan 30 at 5:54
|
show 1 more comment
1 Answer
1
active
oldest
votes
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...
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1399941%2fwindows-10-multihomed-routing-rdp-black-screens-locking-and-connection-timeou%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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...
add a comment |
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...
add a comment |
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...
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...
answered Jan 30 at 21:44
Inquisitor ShmInquisitor Shm
3382414
3382414
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1399941%2fwindows-10-multihomed-routing-rdp-black-screens-locking-and-connection-timeou%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The windows 10 machines have two interfaces...which one is configured with a gateway?
– Larryc
Jan 30 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?
– grawity
Jan 30 at 5:28
(A) is configured with the gateway.
– Inquisitor Shm
Jan 30 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 at 5:51
Guesses don't count; install Wireshark or tcpdump and look at the actual packets being transmitted.
– grawity
Jan 30 at 5:54