Windows 10 multihomed routing - RDP black screens, locking and connection timeouts












1















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?










share|improve this question

























  • 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
















1















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?










share|improve this question

























  • 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














1












1








1








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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



















  • 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










1 Answer
1






active

oldest

votes


















1














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...






share|improve this answer























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    1














    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...






    share|improve this answer




























      1














      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...






      share|improve this answer


























        1












        1








        1







        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...






        share|improve this answer













        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...







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 30 at 21:44









        Inquisitor ShmInquisitor Shm

        3382414




        3382414






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Сан-Квентин

            Алькесар

            Josef Freinademetz