none
DirectAccess - Teredo not working with 2 Consecutive IP's RRS feed

  • Question

  • I need some help as to the troubleshooting approach.  IPHTTPS works just fine but we are not able to get Teredo to work from the clients.  The Remote Access Management console also shows only IPHTTPS.

    DA server setup with two consecutive IP's externally

    • Edge Firewall setup to allow 443 tcp and 3544 udp
    • Verified Edge Firewall ports are open to the server with nmap from my home internet

    get-daserver

    TeredoState : Disabled

    set-DAServer -TeredoState enabled

    set-DAServer : Teredo cannot be enabled when the Remote Access server is located behind a NAT device.

    I'm just looking for any ideas that might point me in the right direction.

    Wednesday, May 8, 2013 11:40 PM

Answers

  • Hi

    reconfiguing URA rôle is a good option. But Watch out, it's not because you have two public IPv4 addresses that Teredo is configured by default. This is an option to add. Have a look at the Set-DAServer Powershell commandlet.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    • Marked as answer by KentFar Wednesday, May 29, 2013 4:46 AM
    Monday, May 27, 2013 7:15 PM

All replies

  • Hi

    If your DirectAccess is located behing an edge device, your server have IPv4 private address. Teredo protocol was designed to operate with two public IPv4 addresses (must be consecutive for DirectAccess specific scenario). For this reason, you cannot activate Teredo. If your DirectAccess server does not have a network interface directly connected to Internet you cannot use Teredo.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Thursday, May 9, 2013 6:42 AM

  • Thanks for the reply.

    Our direct access server is located behind our corporate firewall which would be "Behind an edge device" in Remote Access Setup.  Our public IPv4 addresses are consecutive and are a class B address.  We have enabled the recommended ports on our corporate firewall as well.  The only thing we did not do was enable protocol 41 since our team was not familiar with that and did not see an option in our corporate firewall.

    Basically our setup is

    Firewall <-> External NIC on DA Server with two consecutive Public IPv4 addressess <-> Internal NIC on DA Server routed to internal network.

    While I thought we might have some issues with our Windows Firewall making our external NIC public I no longer believe that to be the case.  We updated our Windows Firewall rule to only block LDAP 389 based on a recommendation in a previous post instead of all TCP traffic.

    Kent


    • Edited by KentFar Tuesday, May 14, 2013 1:50 AM
    Tuesday, May 14, 2013 1:48 AM
  • Hi

    If your DirectAccess server is configured for the "begin an edge device' scenario, you acnnot enable Teredo. How do you manage communication between Firewall and external NIC? If by NAT, it cant work.

    If you block LDAP trafic with a firewall rule, this means that you can contact your coporate network by using the external network card. In this situation, your external interface is configured with a "Domain" firewall profile. With Teredo, it must be a "Public" firewall profile.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Tuesday, May 14, 2013 7:05 AM
  • Sorry for the delayed reply as I was working on other issues.  Thanks for your responses.

    The external NIC on the URA server has a public IP and goes through our edge firewall.  There is no NAT going on from the external NIC to to the Internet through the firewall.

    I think I just need to change to "Edge" from "Behind an edge device" but the option is greyed out.  Is there a simple way to do this?

    So if I understand the topology correctly based on your comment NAT would be assumed for the behind the edge device and the following transition technologies would be available.  Correct?
    6to4, Teredo, IP-HTTPS - Edge
    6to4, IP-HTTPS - Behind and edge device (with two network adapters)
    6to4, IP-HTTPS - Behind and edge device (with a single network adapter)



    Kent


    Monday, May 27, 2013 1:31 AM
  • Hi

    if the option is greyed, this means you do not respect requirements. Are you sure that the Windows Firewall profile for your external network card is configured to Public?

    6to4 and Teredo are not available in "Behind an edge device". Only IPHTTPS will be available. If you want to have all IPv6 transition protocols you must have two public IPv4 addresses on your URA box.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Monday, May 27, 2013 6:52 AM
  • I thought since the option was grayed out that I was not able to change the topology after it was setup.  I would like to switch it Edge so I might just run "Remove Configuration Settings" and start over.

    • External NIC shows as public in "Network and Sharing Center"
    • We have two public IPv4 addresses assigned to the external NIC
    • I can see 6to4 traffic once in a while in my reports and it looks like it is when the client is not behind a NAT device

    Thanks again.

    Kent

    Monday, May 27, 2013 5:48 PM
  • Hi

    reconfiguing URA rôle is a good option. But Watch out, it's not because you have two public IPv4 addresses that Teredo is configured by default. This is an option to add. Have a look at the Set-DAServer Powershell commandlet.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    • Marked as answer by KentFar Wednesday, May 29, 2013 4:46 AM
    Monday, May 27, 2013 7:15 PM
  • I just wanted to provide a final update on this issue.

    I reconfigured URA by removing the current configuration and creating a new configuration on the Edge instead of Behind and Edge Device.  Teredo is now working which is great to see and the server status shows as configured.

    Thanks again for the information provided as this helped us get URA into a more optimal configuration.

    Take care,

    Kent

    Wednesday, May 29, 2013 4:46 AM