locked
VPN clients connecting to wrong AD site RRS feed

  • Question

  • Hi,

    I'm really stumped on this one, hope someone can help as I've spent days trying to resolve it.

    As our company is expanding overseas I have setup a new server in a new branch location. This server has many roles. It is a RWDC, DNS, DFS fileserver and PPTP VPN server (RRAS). I have created a new site in AD Sites and Services and configured appropriate subnets for this site (including the local subnet and the VPN static pool range). All the SRV entries appear to be correct. Apart from this one branch we have a Head Office which has two DC's.

    My problem is that users connecting in via VPN are authenticating and associating with the wrong AD site (set logonserver shows a DC at head office, and nltest /dsgetsite shows head office site). And they are also incorrectly choosing the wrong DFS fileserver, which I think is all related. I'm using the VPN logon method to VPN and logon in one go. DNS is working correctly, ie the clients are pointing to the branch DC for DNS. But for some reason, they choose to logon using a DC at Head Office across the WAN link. Does anyone know why this might be happening?

    I managed to get one client to use the correct site by disjoining and re-joining it to the domain. But I can't do this for the others as it would be impractical. If I take the WAN link down between HO and Branch then everything works as expected and clients logon to the local DC. So why would they want to connect to the non local site if the local DC is working correctly?

    Appreciate any help.

    Thursday, April 2, 2015 4:57 AM

Answers

  • Hi All,

    I have found the cause of this issue. It was actually a network issue in the end, combined with the branch DC not replying to SRV requests fast enough. In the netlogon log on one of the DC's I found this entry:

    05/28 11:56:01 [SESSION] DOMAIN.COM: NetrServerAuthenticate entered: LAPTOP (192.168.2.1) on account LAPTOP$ (Negot: 612fffff)

    The hostname is correct but the IP address was not. This tells me that the DC determines the client IP from the source address of the packet, not from the client "telling" the DC it’s IP address like I thought. This means if the IP address is translated at any point along the way, the DC will see the translated address and not the clients real address. This is what was happening to me. We had a catch all NAT rule on a gateway device at head office that was translating the client IP address.

    In Summary

    - Client sends out a SRV request to all DC’s

    - A DC in site Head Office reply’s first 

    - The gateway has translated the clients real IP address (e.g. 10.10.10.x) to its own (e.g. 192.168.2.1)

    - The DC see’s the request as coming from 192.168.2.1 and matches this IP with HO site

    - The client is associated with the Head Office site






    • Edited by Wayne_G Thursday, May 28, 2015 3:33 AM
    • Marked as answer by Wayne_G Tuesday, June 2, 2015 12:34 AM
    Thursday, May 28, 2015 3:30 AM

All replies

  • Hi,

    Did you mean that the vpn client did not connect to the vpn server?

    Did you configure VPN server to assign a DNS server address to the VPN clients?

    http://www.isaserver.org/img/upl/vpnkitbeta2/dnsvpn.htm

    Regards.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com

    Friday, April 3, 2015 5:28 AM
  • No I mean the VPN clients connect to the server fine, but they authenticate and associate with the AD server at Head Office which then makes them connect to the file server across the WAN link rather than the local branch files server.

    Yes the VPN server is configured to assign itself as a DNS server, since it is also acting as an AD DNS server.

    Monday, April 6, 2015 10:41 PM
  • So I've done some more digging and it seems the DynamicSiteName registry entry plays a big part in which site a client chooses. I can force the client to use a site by adding a SiteName entry but I'd like to avoid this as we have some users who float between sites.

    My problem seems to be that the DynamicSiteName entry is not updating. I found this blog https://dirteam.com/tomek/2009/02/15/and-i-will-stick-to-my-site/ that shows a client should update it's site over time. But this is not happening for me. What could prevent this registry entry from updating?

    Thursday, April 9, 2015 12:43 AM
  • Hi,

    Sorry for the delay reply.

    This registry entry stores the dynamically-determined  site name for the domain in which this member server or workstation is located. The value of this entry is determined by the Net Logon service, not by an administrator or user.

    Never change dynamically determined values. To override the dynamic site name, add the  SiteName entry with the REG_SZ data type in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. When a value is present for the  SiteName entry, the  DynamicSiteName entry is not used.

    If you want to update this registry entry, you could change the value of  SiteNameTimeout, when the value of SiteNameTimeout expires, Net Logon requests the current site from the domain controller in the computer's primary domain, and it updates DynamicSiteName.

    Regards.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com

    Wednesday, April 15, 2015 7:53 AM
  • Thanks for your reply. Yes I know not to change DynamicSiteName, I was more asking what process updates this key. From looking at netlogon debug the DC that replies is either not recognising the client's subnet, or the client is ignoring the DC list that is return and using the cached value.
    Friday, April 17, 2015 1:46 AM
  • Hi All,

    I have found the cause of this issue. It was actually a network issue in the end, combined with the branch DC not replying to SRV requests fast enough. In the netlogon log on one of the DC's I found this entry:

    05/28 11:56:01 [SESSION] DOMAIN.COM: NetrServerAuthenticate entered: LAPTOP (192.168.2.1) on account LAPTOP$ (Negot: 612fffff)

    The hostname is correct but the IP address was not. This tells me that the DC determines the client IP from the source address of the packet, not from the client "telling" the DC it’s IP address like I thought. This means if the IP address is translated at any point along the way, the DC will see the translated address and not the clients real address. This is what was happening to me. We had a catch all NAT rule on a gateway device at head office that was translating the client IP address.

    In Summary

    - Client sends out a SRV request to all DC’s

    - A DC in site Head Office reply’s first 

    - The gateway has translated the clients real IP address (e.g. 10.10.10.x) to its own (e.g. 192.168.2.1)

    - The DC see’s the request as coming from 192.168.2.1 and matches this IP with HO site

    - The client is associated with the Head Office site






    • Edited by Wayne_G Thursday, May 28, 2015 3:33 AM
    • Marked as answer by Wayne_G Tuesday, June 2, 2015 12:34 AM
    Thursday, May 28, 2015 3:30 AM