Hi All

I have a Multisite Direct Access 2012 r2 environment setup. Site A works perfectly, clients can connect successfully using Teredo or IPHTTPS. Site A contains the NLS server. Intranet is IP v4 only.

Site B, is a little strange. On the Remote Access Management console I can see clients connected with Teredo, but the clients themselves state they are in the Connecting state and never reach Connected

The clients can resolve all intranet names, but can only ping servers on in the Site B subnet, they get a request timed out when trying so ping servers in Site A

If I disable Teredo on the server or the client, the clients connect successfully using IPHTTPS and can ping servers in both sites.

I've tried recreating the Site B DA service

I've tried setting the Teredo Client Type to EnterpriseClient

The DA servers in both sites are both edge devices with 2 consecutive public IP address.

The same problem occurs whether the client is behind a NAT device (home router) or connected directly to the internet with a public IP

I've run out of ideas, any help would be appreciated greatly.

Cheers

Darren

Hi Darren - are both Site A and Site B separate locations with IPv6 Border Routers between them or operating in two different Datacentres over a stretched VLAN ? It used to be that Teredo is quicker but you will find that IP-HTTPS is more routable over your Multi Site Deployment (including Manage Out). If you are using Win 8 Clients with No VPN on the DA Servers you will not get the double encryption hit. Also I would look at deploying multiple NLS Servers using either load balancing or DNS Round Robin as this is a multi site issue I have seen. Go back to basics and check routing between sites between the DA Servers. Happy to help where I can.

Hi John,

Thanks for the quick reply

Site A and B are connected by 2 TMG 2010 servers that are forming a Site to Site VPN.

All clients are Windows 8 or 8.1. so it's good to know there isn't the same performance hit as before.

Is there a trick to Deploying Multiple NLS servers? I would like to have one in each local site, so that the clients don't have to traverse the Site to Site VPN to check. I've only used the wizard to deploy the Multisite DA configuration and it didn't give me the option or using a second NLS server for Site B

Routing between the two sites seems fine, clients in each site can connect to each other and resources without issue, and DA clients who connect via Site A using Teredo or IPHTTPS can connect to resources in Site B. and as I mentioned in my original post DA clients who connect to Site B using IPHTTPS can connect to resources in both sites. It's only DA clients using Teredo via Site B that cannot route to Site A and get stuck with Connecting (maybe this is happening due to the NLS server being in Located in a site that cannot be reached.

I'm wondering is there's a "catch 22" situation here, e.g. the DA client using Teredo cannot connect successfully until it locates (connects to the HTTPS page) the NLS server, but as that isn't on a local LAN in site B then this isn't going to happen? Could that be the case?

Cheers

Darren

Hi Darren - thanks for the info - yes this appears to be the problem (and I have come across this before in the current workplace that I represent.)

In short the resolution is as follows. Create a DNS Record called NLS which resolves to an IP in Site A WebServer. Create another record called NLS which resolves to an IP in Site B

A single, organization-wide network location URL with per-site, highly-available Web servers, All of the DirectAccess clients are configured with the same network location URL but network location detection traffic stays within the site to which the DirectAccess client is attached. DNS records within each site resolve the FQDN in the network location URL to the IP addresses of the Web servers in the site. This is the recommended configuration. For example, DNS records in Site 1 resolve the name nls.company.com to Web servers in Site 1 that host the https://nls.company.com URL. DNS records in Site 2 resolve the name nls.company.com to Web servers in Site 2 that host the https://nls.corp.contoso.com URL. Use the same NLS WebServer certificate on both. (Basically this is DNS Round Robin) - make sure the DNS TTL is quite low for resilience on both records.

http://technet.microsoft.com/en-us/library/ff625682(v=ws.10).aspx

I have also attached another (older but relevant light reading for you) with regards NLS and Branch Office / WAN

http://technet.microsoft.com/en-us/library/ff576612.aspx

Again just to reiterate yes Teredo is better I guess but the trade off for IP-HTTPS in Windows 8 is ok - but the DA Servers have to be enabled for DirectAccess Only not DA & VPN and this negates the improvement.

See Richard's article here - http://directaccess.richardhicks.com/2014/06/24/directaccess-ip-https-null-encryption-and-sstp-vpn/

Hi John,

Thanks again for the fast response. I did consider DNS round robin of an alias based url e.g. nls.company.com, but was concerned about the clients not picking up their local site NLS Server DNS entry.

I wasn't aware that the Network Location client on the workstations was intelligent enough to figure out that it should always try to reach its local NLS server first.

Actually I just read up on this and it appears that it's the DNS server that seems to do the clever bit

http://technet.microsoft.com/en-us/library/cc787373(v=ws.10).aspx 

So am I correct in assuming that when the client requests a connection to the NLS server, the queries actually come from the DA server in the site? Meaning that the DA servers Intranet IP address is the one that the DNS server uses to localise it's response?

I'm still surprised this would only affect Teredo connections, but i'm sure there's a good reason for it.

I'll give this all a try tomorrow morning and report back, users across the pond have started to connect now so I don't want to disrupt them during the day.

Cheers

Darren

Hi Darren - it a "one of those things" that will be fixed in the future I guess. Your assumptions are correct but do remember it is Round Robin, it's a workaround to a problem with Multi Site but works and is as recommended practise. The IP-HTTPS will be more efficiently routed hence why that site is working using that. If I can find the official "good reason" for you I will. Kr and keep me posted.

Hi Darren - how did you get on with the above problem ?

Hi John,

Sorry for the late response. I've been away for most of the summer and was unable to implement your advice until I returned last weekend. It seems to have worked just fine. There are a couple of other strange things going on but i'll put those in a separate thread when I have the time.

Thanks again for your assistance on this.

Cheers

Darren