locked
Help troubleshooting UAG connectivity issues RRS feed

  • Question

  • Hi,

    I have setup UAG in a test lab similar to the Microsoft step-by-step except I have DMZ Front and DMZ Back subnets and there is a router/firewall between Contoso and DMZ-Back subnets and another between Contoso and Internet subnets. This topology reflects out production topology and I imagine it would be similar to many larger organizations. Before installing UAG I verified basic connectivity between all networks. After Installing UAG and I have encountered several problems. I'm sure there is a simple fix and was hoping someone could help.

    1. When I connect to the Internet subnet I get a 6to4 and Teredo tunnels active. I think I should only get a 6to4 tunnel right? I can browse to \\IIS1\temp and \\AD1 but I can't ping them. I disable the Teredo tunnel manually, but it doesn't help. I also can't access any IPv4 resources. Manage-out doesn't work either.

    2. When I connect to the Home subnet I get a Teredo tunnel. IPv6 connectivity is good. I also can do manage-out but I can't access any IPv4 resources. DNS64 is working but I can't tell if NAT64 is working.

    3. When I connect to the Home subnet and disable the Teredo tunnel I get an IP-HTTPS tunnel. Same problems as Teredo tunnel.

    Any help would be appreciated!

    Cheers,
    Matt
    Wednesday, January 27, 2010 4:30 AM

Answers

  • Hi M,

    I don't see any trace at the DC1 computer to see if the ICMP message got there. Check that out too.

    HTH,
    Tom
    MS ISDUA Anywhere Access Team
    • Proposed as answer by Erez Benari Thursday, February 11, 2010 10:54 PM
    • Marked as answer by Erez Benari Thursday, February 18, 2010 12:08 AM
    Monday, February 8, 2010 7:56 PM

All replies

  • Hi

    1. Teredo is supposed to come up, but in a dormant state - meaning, it will handle only traffic destined to other teredo clients. This is called the Teredo Host Specific Relay.
    To verify this, check the roue table on the client and see that only the 2001::/32 route is assigned to the teredo interface.
    If you can access corp resources but can't ping them, it means that you have a problem with your routing.
    When you ping an address, it doesn't go through the IPsec tunnel. Your IPsec tunnel works, because you are able to reach the 6to4 IP address of the UAG server, which is used as the tunnel endpoint.
    Which IPv6 prefix did you use for your corporate network?
    Oh and also check that the client has a default gateway on the 6to4 interface. There is a bug that cuases the 6to4 default gateway setting not to be applied directly after gpupdate. You'll have to restart the client machine for this to take effect.

    2+3. Weird. Does ping works when you try to access IPv4 only servers? You get their translated IPv6 address and what is the error ping shows?
    Check that you configured the IPv4 routes properly on the UAG server. Using UAG Network Configuration wizard, verify that the correct routes are configured on the internal adapter, and a default route is configured on the external adapter.
    Wednesday, January 27, 2010 8:29 AM
  • Hi Yaniv,

    I found I am able to access IPv4 resources using FQDN instead of IP address. I can see this causing problems later on. Is this is behavior normal?

    Re the 6to4 problems:

    - In the Internet subnet when Teredo is connected the route 2001::/32 has a gateway called "on-link"
    - The Contoso subnet is IPv6 enabled using isatap. I didn't assign an IPv6 address or prefix so must be auto-assigned
    - AD1 and IIS1 have IPv6 addresses obtained from isatap
    - All servers can ping each other using IPv4 and IPv6 addresses
    - The UAG Server is connected to DMZ-Front and DMZ-Back subnets. The default route is to Internet subnet.
    - Contoso and DMZ-Back subnets are separated by a router/firewall so there is a static IPv4 route on the UAG server for Contoso subnet.

    I didn't add any routes for IPv6. My understanding is that isatap encapsulates IPv6 in IPv4 so IPv6 will be a virtual subnet spanning the two IPv4 subnets (Contoso and DMZ-Back). It uses IPv4 routing so no IPv6 routes are required. Is this correct?

    If ICMP is outside IPsec then unless the subnets are IPv6 enabled ICMPv6 won't work. ?!


    Thursday, January 28, 2010 1:29 AM
  • Hi M,

    You need to use names because connectivity is based on the NRPT. For example, you can use \\<IPv6_address> to reach SMB resources and you can use http://<IPv6_address> to reach Web sites. At least that's what I've seen so far.

    6to4 is only used when you have a public IP address and are connected directly to the Internet. The Teredo interface should be dormant at that time.

    Make sure the back-end firewall is allowing all IPv4 and IPv6 traffic from the UAG server and the internal network behind the back-end firewall, also make sure that IPv6/IPv4 echo request is allowed from the UAG server to all machines behind the back-end firewall.

    ISATAP will use IPv4 routing, as your ISATAP server delivers addresses on the same IPv6 network ID, so regardless of the number of IPv4 network IDs you have, IPv6 sees that you have a single IPv6 subnet.

    HTH,
    Tom


    MS ISDUA Anywhere Access Team
    Friday, January 29, 2010 5:44 PM
  • Yes,
    you can't use an IPv4 address in DirectAccess. To access IPv4 resources using DirectAccess, you must either use a DNS name, which using DNS64 will be translated to an IPv6 address that NAT64 will pick-up later on. Or predict the IPv6 address that will be used by NAT64 for this resource.

    So I understand we are only left with issue #1 - with the 6to4.
    It is expected that you'll have both teredo and 6to4 on.
    I don't understand why ping doesn't work while SMB does. Can you please turn on Network Monitor on the DirectAccess server + client + IIS1,
    Filter for ICMPv6 or Echo Requests/Replies. This will show us how the ping packet travels - and where is it dropped.

    Regarding manage-out, if you want to be able to initiate a remote desktop connection with a DirectAccess client, then you should create a new firewall rule on the client that allows RDP. it is crucial that you configure this firewall rule to allow edge traversal.

    Make sure you read this guide: http://technet.microsoft.com/en-us/library/ee809065.aspx


    • Marked as answer by Erez Benari Monday, February 1, 2010 7:05 PM
    • Unmarked as answer by mrains Wednesday, February 3, 2010 1:15 AM
    Sunday, January 31, 2010 12:48 PM
  • Yes most of it is working now. When connected as a 6to4 client DA is working. I can access the netlogon share, IPv4 web sites etc. The only issue is ICMP. It isn't essential but as a diagnostic tool it's very useful so I'm interested in knowing what it doesn't work.


    - Ping from DA client to AD1 there are ICMP requests going from the DA client to the UAG DA server. They are received at the DA server but not AD1.

    Log from DA client
    96.0.0.147	96.1.0.1	ICMPv6	ICMPv6:Echo request, ID = 0x1, Seq = 0x1ea
    2002:6000:93:0:0:0:6000:93	2002:6001:1:8001:0:0:A00:1	ICMPv6	ICMPv6:Echo request, ID = 0x1, Seq = 0x1ea
    

    Detail of ICMP Packet from DA client to AD1
    Frame: Number = 121, Captured Frame Length = 114, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-46-D1-50],SourceAddress:[00-0C-29-03-8B-54]
    + Ipv4: Src = 96.0.0.147, Dest = 96.1.0.1, Next Protocol = IPv6 over IPv4, Packet ID = 1640, Total IP Length = 100
    - Ipv6: Next Protocol = ICMPv6, Payload Length = 40
      + Versions: IPv6, Internet Protocol, DSCP 0
        PayloadLength: 40 (0x28)
        NextProtocol: ICMPv6, 58(0x3a)
        HopLimit: 128 (0x80)
        SourceAddress: 2002:6000:93:0:0:0:6000:93
        DestinationAddress: 2002:6001:1:8001:0:0:A00:1
    + Icmpv6: Echo request, ID = 0x1, Seq = 0x1a7

    Log from UAG DA server:
    96.0.0.147	96.1.0.1	ICMPv6	ICMPv6:Echo request, ID = 0x1, Seq = 0x1c6
    

    - Ping from AD1 to DA client there are ICMP requests going from AD1 to UAG DA server. They are received at the DA server and DA client. A response is sent back and received at the DA server but not AD1.


    Log from AD1:
    2002:6001:1:8000:0:5EFE:A00:1	2002:6000:93:0:0:0:6000:93	ICMPv6	ICMPv6:Echo request, ID = 0x1, Seq = 0x17
    AD1 	isatap.corp.contoso.com	ICMPv6	ICMPv6:Echo request, ID = 0x1, Seq = 0x17
    

    Detail of ICMP Packet from AD1 to DA client:
    Frame: Number = 8, Captured Frame Length = 114, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-85-D4-AF],SourceAddress:[00-0C-29-BE-C6-88]
    + Ipv4: Src = 10.0.0.1, Dest = 10.1.0.1, Next Protocol = IPv6 over IPv4, Packet ID = 4964, Total IP Length = 100
    - Ipv6: Next Protocol = ICMPv6, Payload Length = 40
      + Versions: IPv6, Internet Protocol, DSCP 0
        PayloadLength: 40 (0x28)
        NextProtocol: ICMPv6, 58(0x3a)
        HopLimit: 128 (0x80)
        SourceAddress: 2002:6001:1:8000:0:5EFE:A00:1
        DestinationAddress: 2002:6000:93:0:0:0:6000:93
    + Icmpv6: Echo request, ID = 0x1, Seq = 0x7
    

    Log from UAG DA server:
    ad1.corp.contoso.com	UAG1  	ICMPv6	ICMPv6:Echo request, ID = 0x1, Seq = 0xd
    2002:6001:1:8000:0:5EFE:A00:1	2002:6000:93:0:0:0:6000:93	ICMPv6	ICMPv6:Echo request, ID = 0x1, Seq = 0xd
    2002:6001:1:8000:0:5EFE:A00:1	2002:6000:93:0:0:0:6000:93	ICMPv6	ICMPv6:Echo request, ID = 0x1, Seq = 0xd
    96.1.0.1	96.0.0.147	ICMPv6	ICMPv6:Echo request, ID = 0x1, Seq = 0xd
    96.0.0.147	96.1.0.1	ICMPv6	ICMPv6:Echo reply, ID = 0x1, Seq = 0xd
    

    - TMG logs and Windows firewall are not logging and blocked IPv6 over IPv4 or ICMP packets.

    It seems the UAG DA server is not forwarding ICMP from DA client to AD1. Oddly from AD1 to DA client is working.
    Tuesday, February 2, 2010 12:27 AM
  • Hi M,

    I don't see any trace at the DC1 computer to see if the ICMP message got there. Check that out too.

    HTH,
    Tom
    MS ISDUA Anywhere Access Team
    • Proposed as answer by Erez Benari Thursday, February 11, 2010 10:54 PM
    • Marked as answer by Erez Benari Thursday, February 18, 2010 12:08 AM
    Monday, February 8, 2010 7:56 PM