UAG can be used as both DA server and to publish applications over SSL.
In a scenario where UAG has both roles you might run into a situation where ping does not work when connected using DirectAccess over 6to4 tunnel.
This is due the fact that if UAG has multiple roles it will have multiple IP’s on external interface. In my example the UAG has the following IP’s on the external interface.
UAG External adapter IPs
The first two .67 and .68 are used for trunks, publishing applications, and .77, .78 are used by DA.
When a client is connected using 6to4 tunnel and tries to ping an internal resource it fails. Lets look at this in a network monitor trace on the UAG server.
Echo Request from 6to4 Client
The client send a ping request to internal resource 2001:1630:100:10::120, using its 6to4 tunnel endpoint .77. So far all looks good.However lets look at the next packet the echo reply.
Echo reply from UAG to 6to4 Client
UAG sends the reply from the resource back to the client on the internet. But uses the wrong source address, instead of .77 UAG uses it default IP on the external interface .67.
This does not mean DA is not working, just that ping will not work.
Dr. Shinder has written a good article on using ping to troubleshoot DA that explains this.
Solution to this issue is to make sure that UAG has it’s first DA IP as the primary IP. I have for the moment not been able to test this in a load balanced environment. But looking at the current fact, I would guess ping will not work when using load balanced UAG’s since I believe that UAG will use its primary IP in that case as well when sending the reply.