locked
UAG DA - IPHTTPS half working. RRS feed

  • Question

  • I have a UAG DA setup that works wonderfully for internal / external communications as long as the remote client is using Teredo.  If Teredo is blocked (or turned off), the remote client defaults to using IPHTTPS for the IPv6 requirement.

    The remote client authenticates with the IPHTTPS site just fine, gets the IPv6 address... and then stops.

    The remote client can ping the DA DNS while using IPHTTPS but any attempt to ping an internal resource instantly fails:

      "Ping request could not find host server.contoso.com . . Please check the name and try again."

    Any ideas how to troubleshoot this?
    Wednesday, July 21, 2010 3:53 PM

Answers

  • It looks like the issue was simply a lack of entry in the routing table for the DA client to handle the NAT64 prefixed addresses.

    Odd that it affected multiple clients.


    A recommended way to add the static route for NAT64 addresses to DA clients via GPO?

    • Marked as answer by Cheshire43 Tuesday, July 27, 2010 11:03 PM
    Tuesday, July 27, 2010 11:01 PM
  • Hi Aaron,

    It's great that you found and fixed the issue :)

    Can you please explain what do you mean by the NAT64 route was missing?

    Did you configure UAG DA with IPv6 on the internal interface or did you choose to deploy ISATAP on the DirectAccess server?

    If you configured ISATAP, then then a published /49 bits route should have been created on the UAG server - which includes the NAT64 addresses.

    However, if you configured it with native IPv6 on the internal, then the corp routes should have been created manually by you, and if they weren't, you should have been given a warning in the activation that says something like "The UAG DirectAccess server does not have internal routes configured for the entire organization IPv6 prefix. The internal routes do not cover the following address ranges..." and the NAT64 address range was supposed to be specified there.

    Thanks,

    Yaniv

    • Marked as answer by Cheshire43 Wednesday, July 28, 2010 4:07 PM
    Wednesday, July 28, 2010 6:46 AM

All replies

  • Hi Ches,

    Can you ping a host by it's IPv6 address on the intranet? That will tell you if routing if working correctly.

    Check out IPsec security associations in the Windows Firewall with Advanced Security console and confirm that you Main Mode SAs for both the intranet and infrastructure tunnels. Intranet tunnel uses NTLMv2 and Intranet tunnel uses Kerberos.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, July 21, 2010 6:03 PM
  • Using Teredo I can:
    Aquire an IPv6 address
    Ping & RDP to internal IPv6 resources on the Direct Access subnet
    Ping & RDP to internal IPv6 resources on the corporate intranet subnet
    Ping & RDP to internal IPv4 resources on the corporate intranet subnet

    Using IPHTTPS I can:
    Aquire an IPv6 address
    Ping & RDP to internal IPv6 resources on the Direct Access subnet
    Cannot ping & RDP to internal IPv6 resources on the corporate intranet subnet
    Cannot ping & RDP to internal IPv4 resources on the corporate intranet subnet


    The really confusing part for me is why it works with Teredo & not IPHTTPS.

    --
    Using Teredo:
    Under 'Windows firewall with advanced security > monitoring > security associations > main mode' there are 6 entries, 1st authentication is Computer certificate, 2nd authentication has 5 as NTLMv2, 1 as Kerberos V5.
    Under 'Windows firewall with advanced security > monitoring > quick mode' there are 6 entries, 1st authentication is Computer certificate, 2nd authentication is NTLMv2.

    Using IPHTTPS:
    Under 'Windows firewall with advanced security > monitoring > security associations > main mode' there is one entry, 1st authentication is Computer certificate, 2nd authentication is NTLMv2.
    Under 'Windows firewall with advanced security > monitoring > quick mode' there are 3 entries, all look identical, 'local address, remote address, any, any, any, none, SHA-1,AES-CBC 192'.
    Wednesday, July 21, 2010 7:36 PM
  • Teredo and IP-HTTPS using different IPv6 prefixes, hence incorrect IPv6 routing can cause one to work and not the other.

    Try pinging the IPv6 address of the DA client when using Teredo and IP-HTTPS to see if you have a routing problem from intranet resources. To troubleshoot you can also add static IPv6 routes for the Teredo/IP-HTTPS prefixes with a gateway of the UAG IPv6 adddress and see if this helps...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Cheshire43 Wednesday, July 28, 2010 4:06 PM
    • Unmarked as answer by Cheshire43 Wednesday, July 28, 2010 4:13 PM
    Wednesday, July 21, 2010 10:57 PM
  • Hi Ches,

    What's the difference between the "DirectAccess subnet" and the intranet?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, July 22, 2010 11:41 AM
  • 10.10.10.145/28 would be the direct access subnet,
    10.11.10.0/24 would be the intranet.

    Transition & communication between those two subnets is fine with Teredo, can't tell what's happening otherwise.
    Thursday, July 22, 2010 10:18 PM
  • Teredo and IP-HTTPS using different IPv6 prefixes, hence incorrect IPv6 routing can cause one to work and not the other.

    Try pinging the IPv6 address of the DA client when using Teredo and IP-HTTPS to see if you have a routing problem from intranet resources. To troubleshoot you can also add static IPv6 routes for the Teredo/IP-HTTPS prefixes with a gateway of the UAG IPv6 adddress and see if this helps...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Did you try any of this?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, July 22, 2010 11:26 PM
  • 10.10.10.145/28 would be the direct access subnet,
    10.11.10.0/24 would be the intranet.

    Transition & communication between those two subnets is fine with Teredo, can't tell what's happening otherwise.

    Is the DA subnet the one where the DA clients are located?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 23, 2010 11:40 AM
  • The remote DA clients are on the actual internet,

    The DA subnet contains servers relevant to run DA (DC, CA, IIS, etc)

    The intranet is the internal corporate network, not usually accessible from remote clients without using VPN / Cisco work arounds.

    Friday, July 23, 2010 3:05 PM
  • OK, so the DA clients can reach resources on the DA subnet, but they can't reach resources that are remote from that subnet?

    Are you using ISATAP throughout the network, including the non-DA clients subnet?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, July 26, 2010 12:44 PM
  • When the DA client is using Teredo, it gets its IPv6 address, and can connect to resources on the DA subnet as well as the resources remote to that subnet.

    When the DA clients is using IPHTTP, it gets its IPv6 address, and can connect to IPv6 resources on the DA subnet, but cannot connect to anything on the remote subnets.

    - The DA client still connects to the DA server and queries the internal resource.
    - The DA server sends the query for A and AAAA records to the DNS.
    - The DNS queries the FQDN and gets the responses.
    - DNS sends the query responces for both the A record (with IP address) and AAAA record (no IP, IPv4 only addressing) to the DA server.
    - The DA server sends a TLS packet to the DA client.

    - The DA client terminates the session?

    ---

    If I ping the internal resources using teredo to find out their NAT64 address, then try to ping that IPv6 address directly using IPHTTPS, I get a 'general failure' message.

    Monday, July 26, 2010 4:18 PM
  • Hey Jason,

    I do appreciate your feedback, had time to run your suggested tests just now.

    When I try to ping the IPHTTPS address of the DA client from the DA server, it get a reply.
    When I try to ping the IPHTTPS temporary address of the DA client, I get no reply.

    When I try to ping the Teredo address of the DA client from the DA server, there is no reply, 'IPv6 no next header' from a fe80:: address.



    -Aaron
    Monday, July 26, 2010 8:25 PM
  • It looks like the issue was simply a lack of entry in the routing table for the DA client to handle the NAT64 prefixed addresses.

    Odd that it affected multiple clients.


    A recommended way to add the static route for NAT64 addresses to DA clients via GPO?

    • Marked as answer by Cheshire43 Tuesday, July 27, 2010 11:03 PM
    Tuesday, July 27, 2010 11:01 PM
  • Hi Aaron,

    It's great that you found and fixed the issue :)

    Can you please explain what do you mean by the NAT64 route was missing?

    Did you configure UAG DA with IPv6 on the internal interface or did you choose to deploy ISATAP on the DirectAccess server?

    If you configured ISATAP, then then a published /49 bits route should have been created on the UAG server - which includes the NAT64 addresses.

    However, if you configured it with native IPv6 on the internal, then the corp routes should have been created manually by you, and if they weren't, you should have been given a warning in the activation that says something like "The UAG DirectAccess server does not have internal routes configured for the entire organization IPv6 prefix. The internal routes do not cover the following address ranges..." and the NAT64 address range was supposed to be specified there.

    Thanks,

    Yaniv

    • Marked as answer by Cheshire43 Wednesday, July 28, 2010 4:07 PM
    Wednesday, July 28, 2010 6:46 AM
  • It looks like the issue was simply a lack of entry in the routing table for the DA client to handle the NAT64 prefixed addresses.

    Odd that it affected multiple clients.


    A recommended way to add the static route for NAT64 addresses to DA clients via GPO?


    Interesting how you marked this the answer when I suggested routing as the issue in my original post :(
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, July 28, 2010 8:19 AM
  • Thank you Naor,

    That does better explain the behaviour.  I do indeed have an internal IPv6 network configured, though I had not spotted the NAT64 address in the incomplete routes message and thought nothing of it as it had also popped up in previous tests similarly configurd with static routes.

    So my workaround for the time being is a startup script in the GPO that applies to DA clients to statically create the appropriate route.
    Wednesday, July 28, 2010 4:11 PM
  • Hi, 

     

    Im sorry I'm a bit confused about the routing rules and everything. I have been struggleling in the past 2 weeks to setup up UAG with NLB, I had it working fine with the Standalone mode, but we are going with full deployement (2200 users ) and we need it to be a bit more robust. 

     

    I'm able to connect via HTTPS fine and actually all ressources work correctly, however if I enable the Teredo interface on the client I get an IP and I am able to ping all ressources but actually do nothing more. I understand this is because it doesn't have the proper internal routes. I'm just not understanding where to add them in the gpo to solve this issues. 

     

    Here is my config...

    2 Vip on the External with IPv4 (Consecutive)

     

    1 Vip on the Internal Network IPV6 2001:db8::179/48

    1 Dip on the Internal Network IPV6 2001:db8::173/48

     

    Then here are my subnet configuration:

    Full internal Network: fd0c:951b:2ba4::/48

    IPHttps: fd0c:951b:2ba4:5500::/60

    Last one: fd0c:951b:2ba4:4:4:4::/96

     

    It does mention that the internal doesn't have all the route. Can you help me. I going in vacation in 48 hours and this need to be put in production before that.. I would sleep so much better!!!!

     

    Thanks alot for the help!!!

     

    Wednesday, July 28, 2010 8:52 PM
  • Hi Aaron,

    It's great that you found and fixed the issue :)

    Can you please explain what do you mean by the NAT64 route was missing?

    Did you configure UAG DA with IPv6 on the internal interface or did you choose to deploy ISATAP on the DirectAccess server?

    If you configured ISATAP, then then a published /49 bits route should have been created on the UAG server - which includes the NAT64 addresses.

    However, if you configured it with native IPv6 on the internal, then the corp routes should have been created manually by you, and if they weren't, you should have been given a warning in the activation that says something like "The UAG DirectAccess server does not have internal routes configured for the entire organization IPv6 prefix. The internal routes do not cover the following address ranges..." and the NAT64 address range was supposed to be specified there.

    Thanks,

    Yaniv


    Yes, I am curious about this too. As far as I know, no specific routes need to be created based on the type IPv6 address used, at least not on the UAG DA server.

    Are you saying that you had to configure your IPv6 routers with a path to the UAG DA server to reach clients using a particular IPv6 transition technology prefix? I'm not an "IPv6 jockey" but I suspect you shouldn't have to do that. But I'd be glad to be corrected by anybody if I'm wrong :)

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, July 28, 2010 11:51 PM
  • Thank you Naor,

    That does better explain the behaviour.  I do indeed have an internal IPv6 network configured, though I had not spotted the NAT64 address in the incomplete routes message and thought nothing of it as it had also popped up in previous tests similarly configurd with static routes.

    So my workaround for the time being is a startup script in the GPO that applies to DA clients to statically create the appropriate route.


    I don't think the client needs a NAT64 routing table entry, since if it's going to use NAT64, IPv4 routing is actually used on the intranet.

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, July 28, 2010 11:53 PM
  • Hi, 

     

    Im sorry I'm a bit confused about the routing rules and everything. I have been struggleling in the past 2 weeks to setup up UAG with NLB, I had it working fine with the Standalone mode, but we are going with full deployement (2200 users ) and we need it to be a bit more robust. 

     

    I'm able to connect via HTTPS fine and actually all ressources work correctly, however if I enable the Teredo interface on the client I get an IP and I am able to ping all ressources but actually do nothing more. I understand this is because it doesn't have the proper internal routes. I'm just not understanding where to add them in the gpo to solve this issues. 

     

    Here is my config...

    2 Vip on the External with IPv4 (Consecutive)

     

    1 Vip on the Internal Network IPV6 2001:db8::179/48

    1 Dip on the Internal Network IPV6 2001:db8::173/48

     

    Then here are my subnet configuration:

    Full internal Network: fd0c:951b:2ba4::/48

    IPHttps: fd0c:951b:2ba4:5500::/60

    Last one: fd0c:951b:2ba4:4:4:4::/96

     

    It does mention that the internal doesn't have all the route. Can you help me. I going in vacation in 48 hours and this need to be put in production before that.. I would sleep so much better!!!!

     

    Thanks alot for the help!!!

     


    I'm curious - why are you using unique-local addresses? It's typically recommended to use 6to4 addresses based on your public block to create a globally unique addressing scheme for your network.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, July 28, 2010 11:59 PM
  • Thank you Naor,

    That does better explain the behaviour.  I do indeed have an internal IPv6 network configured, though I had not spotted the NAT64 address in the incomplete routes message and thought nothing of it as it had also popped up in previous tests similarly configurd with static routes.

    So my workaround for the time being is a startup script in the GPO that applies to DA clients to statically create the appropriate route.


    Hi again,

    Let me explain myself a little better. If you have native IPv6 on the UAG server's internal leg, then we expect you to create some sort of IPv6 route for your entire organization /48 prefix to an IPv6 router inside your corp network. This /48 route also includes the NAT64 route (since it's a subnet inside the organization).

    If such a route is created, during activation, UAG will publish this route, so that all IP-HTTPS clients will receive it automatically upon connection.

    You shouldn't create a GPO script to create this route on the client. the only thing you should do is create this route on the UAG server:

    netsh int ipv6 add route prefix=<CorpRoute>/48 interface=<PhysicalInternalInterfaceName> publish=yes

    Once this route is created on the UAG server, it will be published to all IP-HTTPS clients automatically.

    By the way, if you don't really have IPv6 in your organization, why didn't you use ISATAP?

    Thursday, July 29, 2010 8:07 AM
  • Hi Aaron,

    It's great that you found and fixed the issue :)

    Can you please explain what do you mean by the NAT64 route was missing?

    Did you configure UAG DA with IPv6 on the internal interface or did you choose to deploy ISATAP on the DirectAccess server?

    If you configured ISATAP, then then a published /49 bits route should have been created on the UAG server - which includes the NAT64 addresses.

    However, if you configured it with native IPv6 on the internal, then the corp routes should have been created manually by you, and if they weren't, you should have been given a warning in the activation that says something like "The UAG DirectAccess server does not have internal routes configured for the entire organization IPv6 prefix. The internal routes do not cover the following address ranges..." and the NAT64 address range was supposed to be specified there.

    Thanks,

    Yaniv


    Yes, I am curious about this too. As far as I know, no specific routes need to be created based on the type IPv6 address used, at least not on the UAG DA server.

    Are you saying that you had to configure your IPv6 routers with a path to the UAG DA server to reach clients using a particular IPv6 transition technology prefix? I'm not an "IPv6 jockey" but I suspect you shouldn't have to do that. But I'd be glad to be corrected by anybody if I'm wrong :)

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team


    Hi Tom,

    What I meant was that if someone defined the IPv6 corp prefix to be for example 2001:db::/48, then it is expected the UAG server will have proper routing to this entire address space, whether it's link-local or in a different subnet. We expect the admin to create a route with this prefix 2001:db::/48 to a next hop IPv6 router. The UAG DA activation will make these routes published, so they will be advertised to the IP-HTTPS clients. Plus, this route is also a superset of the NAT64 route - so that's the way to publish the NAT64 prefix as well.

    In the UAG DA activation we also give a warning in case any address space inside that 2001:db::/48 is not reachable (no route on the machine)

    By the way, IP-HTTPS, unlike other transition technologies, doesn't create a default IPv6 route on the client. IP-HTTPS works like a standard IPv6 router and receives all of the routes on the client from the UAG server (the router). This is why it's important to publish the proper routes on the UAG server (activation will publish them automatically if they exist)

    Thursday, July 29, 2010 8:15 AM
  • Hi, 

     

    Im sorry I'm a bit confused about the routing rules and everything. I have been struggleling in the past 2 weeks to setup up UAG with NLB, I had it working fine with the Standalone mode, but we are going with full deployement (2200 users ) and we need it to be a bit more robust. 

     

    I'm able to connect via HTTPS fine and actually all ressources work correctly, however if I enable the Teredo interface on the client I get an IP and I am able to ping all ressources but actually do nothing more. I understand this is because it doesn't have the proper internal routes. I'm just not understanding where to add them in the gpo to solve this issues. 

     

    Here is my config...

    2 Vip on the External with IPv4 (Consecutive)

     

    1 Vip on the Internal Network IPV6 2001:db8::179/48

    1 Dip on the Internal Network IPV6 2001:db8::173/48

     

    Then here are my subnet configuration:

    Full internal Network: fd0c:951b:2ba4::/48

    IPHttps: fd0c:951b:2ba4:5500::/60

    Last one: fd0c:951b:2ba4:4:4:4::/96

     

    It does mention that the internal doesn't have all the route. Can you help me. I going in vacation in 48 hours and this need to be put in production before that.. I would sleep so much better!!!!

     

    Thanks alot for the help!!!

     

    Hi NorthFace21,

    Please don't add any routes to the GPO :) (ever)

    If you can ping all of the resources it indicates there isn't any routing problem. Do you really have native IPv6 servers in your organization? (I see you aren't using ISATAP)

    To avoid the warning in the activation, you should create the route  fd0c:951b:2ba4::/48 on all UAG servers to point to your internal next hop IPv6 router. (Or create the route on link if you don't have any IPv6 routers in your organization)

    The problem with the resources not being reachable is probably due to IPsec 2nd tunnel failure. Try to check:

    • You started NLB on both nodes using UAG's Web Monitor
    • Try to access the domain controller from your Teredo Client
    • IPv6 should be enabled in the TCP/IP properties of your physical external interface. make sure the checkbox is checked.
    • Enable IPsec auditing on both servers and see if there are any failures in the Security Event Log

    By the way, if you don't have IPv6 in your organization, then you should really deploy UAG as an ISATAP router. It saves all the hassle with configuring IPv6 routes and does everything for you automatically.

    Thursday, July 29, 2010 8:27 AM
  • Hi Yaniv,

    Thanks! That was very instructive! It puts me in a good position to create a Test Lab Guide for native IPv6 networks so that people get exposed to these concepts. Your post will do a lot to inform that discussion.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, July 29, 2010 11:57 AM
  • Wow, even if I am sure to have done this configuration in the past, I followed the advice and it worked flawlessly.

     

    On a side note, if I enable isatap on the network here it seems to cause problems, some addresses get registered in the dns and when you try to ping them you get time out. I am sure I could have it working someway but here is the config I ended up with.

     

    First by configuring UAG with IP4 and isatap it sets all the required subnet. Then I added the local ipv6 (fe20::1:1 - NLB) and selected it instead of the ip4. All the subnet were configured I just left them with the same config. 

    I still have a warning that I do not cover my whole /49 zone (No route for some addresses) I am not sure I do understand why, but in any cases Teredo and IpHttps now works fine!

     

    I have 2 more questions. First I published my CRLD on the UAG server (to use the NLB feature and have it on all the servers, but somehow each time I activate a configuration it reset all the IIS settings and I loose the configuration for my website CRLD/CRLD on port 80 it all gets lost each time, is there anyway to prevent this from happenning?

    Lastly I am trying to reach an internal Citrix server and as it is well documented it doesn,t work well with uag da natively, this is why I wanted to go to IPV6, I was told you could make it work with using IPV6, but then I also saw that Citrix was absolutely not IPV6. Do you know anything I can do other than simply publishing on the external with a separate web server?

     

    Thanks a lot for everything... IPV6 is still a bit of a mistery for all of us here!

     

    NF21

    Thursday, July 29, 2010 6:07 PM
  • Hi NF,

    1. If the addresses don't register right away, you can do an ipconfig /registerdns
    2. If you can't ping by ISATAP address, make sure that ICMPv6 and ICMPv4 echo requests are allowed inbound to those machines
    3. You might need to check the routing table again, but if it works, then it works :)
    4. You are correct - the IIS gets reset each time you activate the configuration. Put the CRL site someone behind the UAG server to simplify things
    5. I think there is a workaround for the Citrix issue, I'll see if I can find that.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 30, 2010 12:59 PM