none
Windows Server 2012 R2 - Direct Access Server Setup for Behind a NAT Device Should Not Require a Public IP Address

    Question

  • Behind a NAT Device should not require a public IP address because the NAT Device (Edge Device) translates the actual Public IP address to a Private Perimeter IP Address.  Attempting to configure Direct Access Server Setup behind a NAT device (e.g. Cisco Firewall) with an Internal IPv4 Address fails with the error: "The specified IP address is not a public IPv4 address".

    This condition makes the Direct Access Server Setup option for "Behind an edge device" the same as the option for "Edge" device.

    I think this condition is inconsistent with the Support Behind a NAT Device section specifying "DirectAccess server behind a NAT device, with support for a single network interface or multiple interfaces, and removes the public IPv4 address prerequisite."  Reference:  http://technet.microsoft.com/en-us/library/hh831416.aspx

    I just tested this with the "Behind an edge device (with a single network adapter)" and received the same public IPv4 address prerequisite.  My conclusion is that the Direct Access Server Setup's Enable DirectAccess Wizard does not work unless one of the network adapters has a public Internet IP address.  That is: a public IPv4 address is still a prerequisite for DirectAccess in Windows Server 2012 R2 Preview.

    Questions:

    1) Will this issue be fixed in the final R2 release?  If not, does this mean that only Edge servers with one or more public IP addresses are supported for Direct Access?

    2) Is there a way to install RRAS for NAT and VPN without requiring IIS to be installed?




    • Edited by IceHiker Monday, August 12, 2013 2:06 AM
    Monday, August 12, 2013 2:04 AM

Answers

  • Hi,

    1.We don’t know for sure if the issues will fixed in the final R2 release.

    2.You don’t need to IIS when installing RRAS for NAT and VPN.

    Hope this helps.

    Wednesday, August 14, 2013 12:53 AM
    Moderator
  • Thank you for your feedback.

    The Add Roles wizard in Windows 2012 R2 preview forces the installation of IIS when selecting to install RAS.  After the install, IIS can be shut down and RRAS seems to work fine for straight forward NAT and VPN.  However, if I try to Remove the IIS Role, then the Roles wizard forces the removal of RAS.  This may be specific to Windows Server 2012 R2 Preview.  I haven't regression tested to see if the new RAS/IIS Roles dependency is an issue in Windows Server 2012.    In all versions previous to Windows 2012, RRAS could be installed easily without IIS using the Windows Add/Remove Windows Components wizard.  An answer to my question could be a work around for manually installing just RRAS - bypassing the use of the Add Roles wizard.

    I noticed that the Lab Guide base configuration works around the Public IP address requirement by using a Public IP Address and subnet in the Lab environment to simulate the Internet.  Since I'm working with virtual machines, I really don't want to connect a virtual switch directly to the public Internet or DMZ.  I would like to keep all my virtual network interfaces inside a security perimeter.   An answer to my Direct Access private network IP address, behind and edge device, could be a procedure for first installing Direct Access with a Public IP address, then manually changing the configuration after installation to use a private IP address.

    If not going to "fix" the R2 release, then an even easier solution would be if someone would update the Technet Library documentation for Direct Access Installation to specify that a Public IP Address IS REQUIRED.  After all, if Direct Access works with a Public IP address using the behind edge device installation options, then the only thing broken is the documentation - and the people that want to put a firewall device in the perimeter between the DA server and the Internet.


    Wednesday, August 14, 2013 3:46 AM

All replies

  • Hi,

    1.We don’t know for sure if the issues will fixed in the final R2 release.

    2.You don’t need to IIS when installing RRAS for NAT and VPN.

    Hope this helps.

    Wednesday, August 14, 2013 12:53 AM
    Moderator
  • Thank you for your feedback.

    The Add Roles wizard in Windows 2012 R2 preview forces the installation of IIS when selecting to install RAS.  After the install, IIS can be shut down and RRAS seems to work fine for straight forward NAT and VPN.  However, if I try to Remove the IIS Role, then the Roles wizard forces the removal of RAS.  This may be specific to Windows Server 2012 R2 Preview.  I haven't regression tested to see if the new RAS/IIS Roles dependency is an issue in Windows Server 2012.    In all versions previous to Windows 2012, RRAS could be installed easily without IIS using the Windows Add/Remove Windows Components wizard.  An answer to my question could be a work around for manually installing just RRAS - bypassing the use of the Add Roles wizard.

    I noticed that the Lab Guide base configuration works around the Public IP address requirement by using a Public IP Address and subnet in the Lab environment to simulate the Internet.  Since I'm working with virtual machines, I really don't want to connect a virtual switch directly to the public Internet or DMZ.  I would like to keep all my virtual network interfaces inside a security perimeter.   An answer to my Direct Access private network IP address, behind and edge device, could be a procedure for first installing Direct Access with a Public IP address, then manually changing the configuration after installation to use a private IP address.

    If not going to "fix" the R2 release, then an even easier solution would be if someone would update the Technet Library documentation for Direct Access Installation to specify that a Public IP Address IS REQUIRED.  After all, if Direct Access works with a Public IP address using the behind edge device installation options, then the only thing broken is the documentation - and the people that want to put a firewall device in the perimeter between the DA server and the Internet.


    Wednesday, August 14, 2013 3:46 AM