Configuration Manager clients Auto-Site Assignment with DirectAccess IPv6 #sysctr
Currently I’am implementing DirectAccess (DA) infrastructure for a Dutch customer. First I must say I am very satisfied with its operation of DA. Part of DA is remote management (Eventlog, RDP, SCCM, DPM) of Internet DA clients from Intranet, which is pretty nice working as well!
I was wondering how SCCM client auto-site assignment works through DA. Is it a supported scenario and how does I have to define site boundaries as auto site-assignment is based on? Does I have to define my DA server IPv6 or corporate IPv6 prefix as SCCM IPv6 site boundary? Yes, yes, yes!!! Auto-site assignment is supported by DA and works pretty straight foward as it does for your intranet clients :-)
But first some background of IPv6 prefix.
If you have an IPv4 address on the internal facing interface of UAG DirectAccess server, DirectAccess assumes that you don’t have IPv6 deployed in your organization. An IPv6 address is 128 bit – the first 64 bits are the IPv6 “prefix” (which is similar to the IPv4 network ID) and the last 64 bits represent the IPv6 Host ID (similar to the IPv4 host ID). The UAG DirectAccess wizard configures the network prefix information using a 6to4 prefix based on the public IP address bound to the UAG DirectAccess server.
Behind the scenes UAG DirectAccess automatically configures the following prefixes using 6to4 notation:
- 2002:WWXX:YYZZ:8000::/49 as the organizational prefix
- 2002:WWXX:YYZZ:8000::/64 as the ISATAP prefix
- 2002:WWXX:YYZZ:8001::/96 as the NAT64/DNS64 prefix
- 2002:WWXX:YYZZ:8100::/56 as the IP-HTTPS prefix
If you have an IPv6 address on the internal facing interface of UAG DirectAccess server, DirectAccess assumes that you have IPv6 deployed in your organization and therefore you need to enter three different IPv6 prefixes. Organization, IP-HTTPS and NAT64/DNS64 prefix.
As DirectAccess clients can use different IPv6 translation methods to connect to your DirectAccess server, all IPv6 prefixes must be defined as IPv6 site boundary’s enabling auto-site assignment. If you don’t, you might be at risk that auto-site assignment for one or more IPv6 translation methods will fail.
Hereby a number of examples of SCCM clients connected by different translation methods in relation to auto-site assignment.
DirectAccess client scenario connected by Teredo.
DirectAccess client scenario connected by IP-HTTPS.
An interesting question here (similar to boundaries that define VPN connections) is whether to configure these boundaries as fast or slow. There’s no right or wrong answer here, it depends on the throughput and reliability of the DA connection (which in turn depends on the Internet connection) and your preferred behavior for installing software updates and software distribution packages. I mention it because we do see customers reporting this as a problem – documented in “Clients Connecting over VPN Cannot Install Software Updates or Run Advertisements” from http://technet.microsoft.com/en-us/library/bb694288.aspx.
Used sources:
Categories
Modern Workplace 
