Just finished implementing Direct Access in the office, using Forefront UAG to publish it. The wizard in UAG is a dream, everything just works, only things to note are that when you are asked to specify names for the DNS exclusion list, be careful to add all the names you would use to VPN in and to retrieve CRL’s – if you don’t, you’ll find that once the policy is applied, you won’t be able to access the LAN externally – and if you are doing the installation remotely, we would class this as a BAD THING. Easy enough to rectify, just delete the cached GPO policy (HKLM/Software/Policies/Microsoft) – everything under this key is volatile and will be restored next time GP is updated. Also, occasionally I noticed that running the GPO export script would error on the NPRT sections, saying the file was in use – rerunning the script worked every time.
The one thing to note, however, which is true for UAG and TMG, is that all the IPSec functionality is delivered by the Windows Firewall, not UAG or TMG. If, then, the Windows firewall has been disabled prior to the installation of UAG, you will find that the installation proceeds without a hitch, and running the Direct Access wizard works, clients that receive the group policies will connect over Teredo and IPHTTPS, everything looks great – but the clients can’t actually contact any of the internal servers, which is a shame being that contacting the internal severs is the entire point of the exercise 🙂 Frustratingly, at this point you find a distinct lack of errors – all the components appear to be functioning perfectly. However, if you look at the Windows Firewall, you will see that the IPSec Connection Security Rules from the UAG wizard are present in Windows Firewall/Connection Security Rules, but are not present in Windows Firewall/Monitoring/Connection Security Rules, even though the Public Profile is marked as active. The solution? Enable the Windows Firewall for the Public Profile, if not all Profiles. Take home lesson? In Windows 7 and Server 2008, the Windows Firewall should no longer be treated as a bolt on extra, to be disabled unless there is a specific requirement for it to be on – it should now be treated as a core component, and only disabled when a specific requirement to do so exists.