1

We have configured a RD Gateway server (with Web Access on same machine) with two network cards. The server is working fine, however the "connect" of an application is taking a long time. Upon investigation via Wireshark it turns out that the RD Gateway server is trying to connect to the Active Directory server via the wrong network interface card on port 389.

A static route has been setup to force the connection to the AD server via a specific NIC, but apparently there is something in the Remote desktop services that forces it to use the wrong network interface (0; with default gateway on it).

The connection is working fine if I try ping, and telnet (on port 389). Also I later on see successful communication in the Wireshark trace using the correct network interface (using same port). That is however only after 1 minute, so this seems to explain the login delay.

I expect the communication to start from the RD Gateway, is there an NIC directly bound to it, and how to change that?

Edit with some details:

  • The internal network is on interface 192.39.212.112
  • The external network (clients) are on interface 192.39.58.112
  • The AD server is at 192.39.212.227

Edit route print output: ===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.39.58.97    192.39.58.112    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
    129.224.72.60  255.255.255.255    192.39.212.97   192.39.212.112     26
    129.224.72.61  255.255.255.255    192.39.212.97   192.39.212.112     26
   129.225.79.115  255.255.255.255    192.39.212.97   192.39.212.112     26
      169.254.0.0      255.255.0.0         On-link   169.254.176.205    281
  169.254.176.205  255.255.255.255         On-link   169.254.176.205    281
  169.254.255.255  255.255.255.255         On-link   169.254.176.205    281
     172.19.91.14  255.255.255.255    192.39.212.97   192.39.212.112     26
     192.39.58.96  255.255.255.224         On-link     192.39.58.112    281
    192.39.58.112  255.255.255.255         On-link     192.39.58.112    281
    192.39.58.127  255.255.255.255         On-link     192.39.58.112    281
    192.39.212.96  255.255.255.224         On-link    192.39.212.112    281
   192.39.212.112  255.255.255.255         On-link    192.39.212.112    281
   192.39.212.127  255.255.255.255         On-link    192.39.212.112    281
   192.39.212.192  255.255.255.224    192.39.212.97   192.39.212.112     26
   192.39.212.224  255.255.255.224    192.39.212.97   192.39.212.112     26
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link    192.39.212.112    281
        224.0.0.0        240.0.0.0         On-link     192.39.58.112    281
        224.0.0.0        240.0.0.0         On-link   169.254.176.205    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link    192.39.212.112    281
  255.255.255.255  255.255.255.255         On-link     192.39.58.112    281
  255.255.255.255  255.255.255.255         On-link   169.254.176.205    281
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
    129.224.72.60  255.255.255.255    192.39.212.97       1
    129.224.72.61  255.255.255.255    192.39.212.97       1
   129.225.79.115  255.255.255.255    192.39.212.97       1
     172.19.91.14  255.255.255.255    192.39.212.97       1
   192.39.212.192  255.255.255.224    192.39.212.97       1
   192.39.212.224  255.255.255.224    192.39.212.97       1
          0.0.0.0          0.0.0.0     192.39.58.97  Default
===========================================================================
Ben Ootjers
  • 145
  • 5
  • It sounds like both NIC's have ip addresses in the same network. Is that the case? – joeqwerty Dec 04 '19 at 12:34
  • Both NIC's have their own subnet, so they have their own network. One NIC is used to interface externally (running the website). The other is facing internally. The domain controller is in a different subnet than the two NIC, so reaching this could be via both NIC's and subnets, but in our routing only the internal NIC has been connected to this subnet. – Ben Ootjers Dec 04 '19 at 15:12
  • So the externally facing NIC has a DG, and the DC is on a different network than both NIC's. You added a static route to the DC for the internal NIC. Can you paste the output of the `route print` command in your question. – joeqwerty Dec 04 '19 at 17:07
  • Network adapter selection is rarely controlled by the application layer. This sounds like the normal domain controller selection process. A better question is why LDAP traffic is observed on the external network adapter if it would be blocked by the Windows firewall and if the binding for the Client for Microsoft Networks is not enabled. Or why it takes much time at all, if the subnet for the internal adapter is in AD Sites and Services, it should only take a second. – Greg Askew Dec 04 '19 at 17:07
  • @GregAskew the Windows Firewall is not enabled, because the firewall is controlled by a hardware firewall. The client for Microsoft networks is enabled on the external NIC, so I think this could be turned off. The time it takes, is because I see retransmissions (and no response in the trace). First retransmit after 3s, then after 6s, then after 12s. After that another sequence like this – Ben Ootjers Dec 04 '19 at 19:28
  • @GregAsked, I think you are correct. I further digged into the issue and after doing a `netstat -a -n -b` I was able to see that the owning process for the communication was the service NlaSvc or Network Location Awareness Service. This is not the RD Gateway, and I suspect that task of the network location awareness is just to try and find what network connectivity each of the interfaces has. It does not seem to be my issue that is causing the delay during the logon – Ben Ootjers Dec 06 '19 at 10:46

0 Answers0