locked
UAG Public Interface RRS feed

  • Question

  • We have a UAG server with 2 consecutive public IPv4 interfaces. When I plug a laptop into our ISP switch, which is on the same subnet as the UAG public interface server, everything works great. IPSec tunnels come up and I can remote all over CorpNet. However, once I move the client machine off the ISP subnet, to like my house or coffee shop, I lose all connectivity to the UAG server. I can't even ping either the IPv4 or IPv6 address assigned to UAG and defiantly no IPSec. Does anyone know why I can't get UAG Public Interface once I move the client off my ISP's subnet? Any help would be appreciated.
    Wednesday, January 25, 2012 10:27 PM

All replies

  • hi

     

    sure there a firewall in front of your UAG server.

     

  • Allow inbound and outbound “Protocol 41″ (aka ISATAP) to support 6TO4 connections.
  • Allow UDP trafic over port 3544 to support Teredo connections.
  • Allow TCP traffic over port 443 to support IP-HTTPS connections.
  • Allow ping (ICMP echo).

  • BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
Thursday, January 26, 2012 6:39 AM
  • If you have a firewall between the UAG and the internet then you need to open everything that Benoit specified.

    Additionally, it is possible that when you plugged into the ISP switch directly that you connected via 6to4 or Teredo, which caused you a successful connection, but on the other networks you have tried those mechanisms may be unable to connect and therefore the client computer may be falling back to use IP-HTTPS. Many people have trouble with IP-HTTPS during their initial configuration, typically the trouble revolves around certificates. If you do not have an external firewall or feel that it is not causing the problem, take the troubleshooting from the client's perspective with the DirectAccess Connectivity Assistant logs. These logs will indicate whether or not the client is attempting to connect over IP-HTTPS, and if it is having trouble you will be able to start troubleshooting from the information in these logs.

    Thursday, January 26, 2012 2:13 PM
  • I would suggest looking at the firewall settings first. However, we had problems with direct access and found it was because the client was trying to connect over 6to4 which failed but then wasn't falling back to teredo/ip-https correctly. Take a look at this thread.

    http://social.technet.microsoft.com/Forums/en/windowsserver2008r2networking/thread/e036afe6-bf91-4bba-9d6f-acea7fcf8436

    Many thanks

    Peter

    Wednesday, February 1, 2012 10:58 AM