Thursday, 7 October 2010

The Curious Case of Forefront UAG DirectAccess and the Teredo Failure…

I experienced a slightly unusual problem during a recent Forefront UAG DirectAccess (DA) deployment which I thought would be interesting to share…

Background

The particular DirectAccess deployment was a little unusual because DA clients were located on a private MPLS cloud and not the Internet as you would normally expect. The DA solution was designed to allow home workers with dedicated connections into the MPLS cloud to experience seamless and transparent access to corporate resources, as opposed to using some form of traditional VPN offering. As the MPLS cloud was not running a native IPv6 infrastructure, it was necessary use IPv6 transition technologies in order for DA clients to reach the UAG array of DA servers.

The UAG infrastructure consisted of an array of UAG servers combined with integrated Network Load Balancing (NLB) for failover and load balancing duties. The UAG server external network interfaces were connected to a public IPv4 addressed DMZ and assigned two public IPv4 addresses.

During the design process I was faced with the following interesting question:

“If DA clients are using private addresses but have a fully routed (non-NAT’ed) connection to the UAG array with no firewall limitations, which transition technology would be used?”

It is usually easy to answer this type of question for an Internet connected DA client, based upon the following knowledge:

  • If the DA client is using a public IPv4 address, 6to4 will be used.
  • If the DA client is using a private IPv4 address, Teredo will be used.
  • If the DA client is using a private IPv4 address and is located behind a firewall device that is blocking UDP3544 (Teredo), IP-HTTPS will be used.

If you consider a standard Internet connected DA client, the ability to be able to use a private IP address and reach the UAG DA array with a routed connection (e.g. without the use of NAT) just does not exist. Consequently, my gut feeling in this particular scenario was that Teredo would be used as opposed to any other transition technology, but couldn’t be 100% sure it would work.


Establishing a Baseline

During the early stages of testing, we placed a DA client on the same network as the UAG DA servers external interfaces to provide a simple, direct connection and establish a working baseline. In this particular scenario, the DA client was using a public IPv4 address because it was in the same network as the UAG DA servers. Hence, the DA client used the 6to4 transition technology and connected successfully to corporate resources first time – DirectAccess was working! So, we now had a working baseline upon which to move forward.#


The Problem

However, upon connecting a DA client to the MPLS cloud, the DA connection failed. Early observations revealed the following:

  • The DA client was using a private IPv4 addresses, assigned by the local MPLS router.
  • The DA client was attempting to Teredo, but could not complete the connection with “State: offline, Error: primary teredo server unavailable over UDP” errors.

The first observation was achieved using the ipconfig /all command. The second observation was achieved using the netsh interface teredo show state command.

Based upon experience with other deployments, my first thoughts turned to some form of in-path firewall blocking UDP3544 (Teredo) from reaching the UAG DA array. After investigating the only in-path firewall (located between the MPLS cloud and the UAG DA array) it could be seen that UDP3544 was not being blocked and we could see traffic from the DA client passing through the firewall successfully.

To begin troubleshooting, we first looked at the general DA client state using the netsh dnsclient show state command, looking for the following key states:

  • Machine Location: Outside Corporate Network
  • DirectAccess Settings: Configured and Enabled

Next, we determined whether we could ping the actual IPv6 address of the UAG DA array (well, to be precise, the IPv6 address of the first public IPv4 NLB VIP in this case).

By using a netsh namespace show effective we were able to list the Name Resolution Policy Table (NRPT). Within this table, it is possible to see the IPv6 address of the UAG DirectAccess DNS server listed under the DirectAccess (DNS Servers) section.

This resulted in successful replies and we provided we were able to successfully ping the IPv6 address. I repeated the process with the relevant IPv4 address, which also resulted in successful replies.

In order to verify potential IPv4 routing problems and ensure that traffic was indeed reaching the UAG DA servers, I looked at the TMG real-time logs which showed both Ping and Teredo protocols as Initiated/Allowed.

Please Note: In order to test IPv4 Ping, it was necessary to amend the default system policy Remote Management | ICMP (Ping) access behaviour by adding the IPv4 address of our DA client to the Remote Management Computers computer set. After testing, this temporary entry was removed for security reasons.   

So, to summarise our findings:

  • DirectAccess was configured and enabled on the DA client.
  • The DA client had successfully determined it was located outside of the corporate network.
  • We could ping the IPv6 address of the DA DNS server.
  • We could ping the IPv4 address of the first public IP address assigned to the UAG DA array.
  • The in-path firewall was not blocking Teredo on port UDP3544.
  • DA client traffic for both Ping and Teredo protocols were being logged by the local TMG instance on UAG.

At this point, I was a little confused as we appeared to have good connectivity and had met all the necessary requirements for DA to function. From our testing of the DA client “on subnet” I also knew that DirectAccess connectivity could be achieved and it must be a specific issue with Teredo, as connectivity via 6to4 was already proven.


The Solution

After a little research into the mechanics of the Teredo protocol, I suddenly released that the detection of NAT was actually inherent to the Teredo protocol. However, in this particular scenario we were using DA clients with private IPv4 addresses yet no form of NAT was actually being employed because we didn’t actually need it.

After reconfiguring the in-path firewall to employ NAT for for the associated DA firewall rule, the Teredo protocol successfully negotiated a connection with the UAG DA server and DirectAccess was finally working! Hot smile


Bonus Question!

Now, a sensible question for those paying attention would be:

“If Teredo was not able to connect, why didn’t the DA client fall back to using IP-HTTPS?”

Well, this is a very good question and is easily answered. During the design stages the customer had decided to specifically prevent the use of IP-HTTPS; mainly because of the associated performance loss and there was just no need for it due to the inherent openly routed private network design. Consequently, I had disabled the IP-HTTPS interface using a custom Group Policy object (more on this in a future blog post) on all DA clients to meet this requirement. With the IP-HTTPS interface disabled, and 6to4 not available, Teredo is, and was, the only remaining option.


Summary

So, a slightly unusual deployment scenario but I gained a much better understanding of the Teredo protocol and a useful exercise for troubleshooting failed DA client connectivity. Hopefully you have learned something too Winking smile

6 comments:

  1. I'd definitely still use VPN. Hope you also agree with me on this one.
    usa vpn

    ReplyDelete
  2. Severing the firewall connection will really make it a lot harder to set this up. Can I also use IPv6 address on this program?

    ReplyDelete
  3. Not sure I understand what you mean?

    ReplyDelete
  4. So if there was no NAT in place, why would it not use 6TO4? Does Teredo assume that if you have a private IP (10.x.x.x etc) that NAT would be present? It seems like a flawed assumption to me.

    ReplyDelete
  5. I definitely learned a lot. Thank you for this great post.

    ReplyDelete