Hello there! My name is Daniele Francioni and I work as an IT consultant in Microsoft Italy.
As you know, DNS is a core element in many kinds of IT infrastructures, from Active Directory to IPv6 networks; however, in IPv6 networks, addresses are simply too long and too cryptic to remember and use. Dynamic DNS registrations do two things: (1) they allow clients to register their IP addresses in the corporate DNS to be easily reachable and (2) they play an important role in DirectAccess. A DirectAccess client frequently changes its IP address because it can connect from home, from a customer site, using a Mobile connection through 3G or HSDPA, and so on. Management servers rely on DNS to get the IPv6 address of remote DirectAccess clients, so dynamic DNS registration must work if you want to manage remote DirectAccess clients.
I’ve recently been involved in setting up a DirectAccess solution using Forefront UAG, and everything worked… except when a management server tried to contact a remote DirectAccess client. After a short troubleshooting session, it was found that remote DirectAccess clients were able to connect to the corporate intranet using DirectAccess, but they were not registering their IPv6 addresses in the internal DNS. Trying to force the registration with “ipconfig /registerdns” didn’t produce any errors in the event viewers, but also didn’t produce any records in the DNS.
The dial-up connection (in particular a mobile connection using a 3G modem) was the problem. When you create a dial-up connection, Windows does not enable “Register this connection’s addresses in DNS”.
When a client connects to the intranet through DirectAccess, it registers its IPv6 address only if the connection it’s using has that option checked. And, of course, the clients affected by the problem were using a dial-up connection with a 3G modem. Lesson learned: if you’re planning to deploy DirectAccess in your infrastructure and your mobile workforce extensively uses mobile cards (e.g. 3G or HSDPA cards), or dial-up connections, don’t forget to enable this option. If you do forget, the clients will be able to connect to your internal network, but you will not be able to manage them while they are at a remote site; a unique feature of DirectAccess.
If you use DirectAccess with Forefront UAG, DNS has one more important role. The NAT64 feature of UAG DirectAccess relies on DNS to allow remote DirectAccess clients to communicate with IPv4-only hosts. When a DirectAccess client tries to connect to a server, UAG intercepts the DNS query and splits it into two different queries: one looking for the AAAA record (IPv6 record) and the other one for the A record (standard IPv4 record). If DNS replies with either both records, or only the IPv6 record, the IPv6 address is returned to the DirectAccess client and no translation occurs since the client sends IPv6 packets directly to the requested server. If only the IPv4 record is present, UAG returns a specially crafted IPv6 address to the client (the last part of the address contains the IPv4 address of the server). NAT64 intercepts all IPv6 traffic directed to this address and translates it into IPv4 packets directed to the target server. This is particularly useful if you have server applications that are not able to communicate using IPv6. NAT64 only works when the connection starts from an IPv6 host, not vice versa. For this reason, if a server in your internal network needs to contact a remote DirectAccess client, it needs to be IPv6 enabled.
Suppose that you have two services installed on the same server: one service is IPv6 enabled and is used to manage clients, while the other one is not. For example, you installed SCOM 2007 on a Windows Server 2003 server with Remote Desktop Services (RDS) enabled. Many system services on Windows Server 2003 are able to only use IPv4 and RDS is no exception. You can install the IPv6 stack on Windows Server 2003 and let the SCOM service contact DirectAccess clients directly, but you won’t be able to connect to the Windows Server 2003 using RDS from a remote DirectAccess client. The problem is that no NAT64 translation takes place because there’s an IPv6 address registered in DNS; therefore, the client tries to connect using IPv6, but RDS on Windows Server 2003 is not able to receive IPv6 packets.
You can re-enable NAT64 translation by adding a second entry in DNS with the IPv4 address of the server and using it to connect to IPv4-only services. In this case, NAT64 translates all packets, and everything should work with no further issues.
Author:
Daniele Francioni, IT Consultant, Microsoft Services Italy
Reviewer:
James Kilner, Technical Writer, Forefront Edge
