none
Publishing two consecutive IP address on the Internet for DirectAccess RRS feed

  • Question

  • We would like to install a DirectAccess server in the DMZ behind a Cisco firewall. Forefrount document states that you need two consecutive public IP address on the Internet.  Our network group say that they NAT all Internet addresses to a private IP address. I assume this a common practice in all large companies.

    I've sent our Network group the following link showing the UAG behind a firewall BUT it was not NATTED.

    http://technet.microsoft.com/en-us/library/ee809089.aspx

     

    There response from my email was:

    Sounds like they are talking about a transparent NAT.  A transparent NAT pretty much makes the firewall act more as a packet filter device by doing only ACL’ing and no NAT translation.  Although we do a lot of transparent natting on the inside of the network, we do not transparent NAT on the outside.  We translate Public IP addresses to private IP Addresses on the DMZ.  We can’t assigned a Public IP Address directly to the NIC of a server on the DMZ, our rules and basic technology will not allow it.

    With all this said, is there another way to get around these requirements for the server to be in the Internet?

     

    Thanks,

    Frank

     

    Monday, March 29, 2010 2:23 PM

Answers

  • Jason's solution has a lot of advantages - most of all is the fact that the front-end firewall can provide basic packet filtering so that only inbound SSL is allowed, or if you're going to use it for UAG DA, then you need to configure the packet filters required to support DA, which you can find at:

    http://technet.microsoft.com/en-us/library/ee809062.aspx

    Also, if you plan on hosting your own CRL, you'll need to allow inbound HTTP (TCP port 80)

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    • Marked as answer by Erez Benari Wednesday, March 31, 2010 7:10 PM
    Wednesday, March 31, 2010 12:40 PM
    Moderator

All replies

  • We ran into the same problem when we first looked at testing DA about two months ago.  We gave up on the testing for this very reason.  So if there are any solutions available we'd be glad to hear them also.
    Monday, March 29, 2010 2:40 PM
  • Yes, you need to route the connections to the DirectAccess server, as the public IP addresses are a requirement. More firewalls will enable this, as NAT is not a requirement for any firewall. They might want to revisit network policies and realign them with business needs in this situation.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, March 29, 2010 2:59 PM
    Moderator
  • A public IP addressed "front" DMZ, protected by an edge firewall is the best option here. You then connect the UAG external interface to this DMZ. If also requried, you can connect the UAG internal interface to a "back" DMZ if you want to firewall between UAG and the internal network. If not, UAG can connect direct to the LAN; you are still protected by your edge firewall in this scenario and also by TMG which runs underneath UAG... 
    Jason Jones | Forefront MVP | Silversands Ltd
    Monday, March 29, 2010 3:58 PM
    Moderator
  • A public IP addressed "front" DMZ, protected by an edge firewall is the best option here. You then connect the UAG external interface to this DMZ. If also requried, you can connect the UAG internal interface to a "back" DMZ if you want to firewall between UAG and the internal network. If not, UAG can connect direct to the LAN; you are still protected by your edge firewall in this scenario and also by TMG which runs underneath UAG... 
    Jason Jones | Forefront MVP | Silversands Ltd
    Monday, March 29, 2010 3:59 PM
    Moderator
  • Jason's solution has a lot of advantages - most of all is the fact that the front-end firewall can provide basic packet filtering so that only inbound SSL is allowed, or if you're going to use it for UAG DA, then you need to configure the packet filters required to support DA, which you can find at:

    http://technet.microsoft.com/en-us/library/ee809062.aspx

    Also, if you plan on hosting your own CRL, you'll need to allow inbound HTTP (TCP port 80)

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    • Marked as answer by Erez Benari Wednesday, March 31, 2010 7:10 PM
    Wednesday, March 31, 2010 12:40 PM
    Moderator
  • Thanks everyone for the quick replies. I'm forwarding the information to my manager. He's going to have our MS representive get some more answers.

    Jason,

    Our network group / security polices wants to NAT every public IP address to reduce attacks on a Windows server. I'm not a expert in routers but if you ONLY allow certain packets to a server behind a firewall based upon what Thomas said above, how secure is this solution?  I'm aware of the TMG but how would this stand up to a regular Cisco firewall?  We would also have a firewall behind this server to protect our internal network.

     

     

    Wednesday, March 31, 2010 5:14 PM
  • Thanks everyone for the quick replies. I'm forwarding the information to my manager. He's going to have our MS representive get some more answers.

    Jason,

    Our network group / security polices wants to NAT every public IP address to reduce attacks on a Windows server. I'm not a expert in routers but if you ONLY allow certain packets to a server behind a firewall based upon what Thomas said above, how secure is this solution?  I'm aware of the TMG but how would this stand up to a regular Cisco firewall?  We would also have a firewall behind this server to protect our internal network.

     

     

    Wednesday, March 31, 2010 5:14 PM
  • Hi Frank,

    The UAG DA server can be put in between a front-end and back-end firewall. Not that this is required, but its the most common deployment method.

    However, there is no workaround for the two consecutive public IP addresses on the external interface of the DA server. You don't have to allow all traffic to those IP address (actually, just a handful of protocols). On the back-end, you essentially need to allow all traffic between the UAG DA server and the corpnet, unless you have an intimate knowledge of your traffic profile and want to instantiate that knowledge on firewall policy on the back-end firewall.

    Check out my recent blog post on this subject at:

    http://blogs.technet.com/tomshinder/archive/2010/04/01/uag-directaccess-server-deployment-scenarios.aspx

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, April 1, 2010 1:40 PM
    Moderator
  • Firstly, NAT is not a security solution. Opening a port to a routed public IP address and opening a port to a NAT'd private address exposes the same service and risk.

    Giving UAG a public IP address does not mean it is "open on the Internet", even without a front-end firewall the local TMG instance will protect the host and only allow the necessary inbound protocols for DA. By placing a front-end firewall in front of UAG, you simply introduce a little defense in depth and reduce the packet filtering load on UAG/TMG.

    There is no getting away from the fact that you will need to open DA services to the Interent for DA to function; filtering of these services using a front-end firewall is a popular choice as discussed by Tom...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd
    Thursday, April 1, 2010 10:23 PM
    Moderator
  • Hi Jason,

    Thanks! I've heard the question come up from other potential DA admins - good to hear that we have a solid consensus on this issue.

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, April 2, 2010 10:32 AM
    Moderator
  • Hi Jason,

    Thanks! I've heard the question come up from other potential DA admins - good to hear that we have a solid consensus on this issue.

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, April 2, 2010 10:32 AM
    Moderator
  • Thanks Jason and Tom for the extra informaiton. I think we have some hope on getting this installed. The article by Tom and Jason's point should be enough to convince our network group.

    I'll keep you updated on the progress.

    Frank

    Friday, April 2, 2010 7:35 PM
  • Thanks Jason and Tom for the extra informaiton. I think we have some hope on getting this installed. The article by Tom and Jason's point should be enough to convince our network group.

    I'll keep you updated on the progress.

    Frank

    Friday, April 2, 2010 7:36 PM
  • Hi Frank,

    I'll write up a discussion on NAT and DA and considerations regarding NAT and where it fits into the spectrum of security solutions. While NAT wasn't designed to be a security solution in and of itself, it does have some security advantages in some scenarios. I'll take about that in the blog post.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, April 5, 2010 1:53 PM
    Moderator
  • Here's our Network group response to your replys.

    I understand Microsoft’s explanation on where the external server “could go”.  Here are my thoughts and issues;

     

    ·         I have never allowed Protocol 41 through my external Firewall.  I believe that I could specified a specific protocol number instead of TCP or UDP, but it has never been tested, so there for I cannot say with certainty that it would work. 

    ·         Although I understand the NAT itself is not a security layer, it is how our network is setup.  We cannot put a Public IP Address on your interface because our DMZ servers sit on the <NATTED address here..for our security > address space.   The ONLY way for your server to have a REAL public IP Address physically assigned to your NIC would be to place it on the public segment, outside of all firewalls and security layers. 

    ·         My other issue I have is the dual interface design. We can overcome the dual interface design as long as the server is not by-passing any firewalls in the process of routing traffic.  For example, if you place the server on the public segment, outside of all firewalls, we will NOT allow you to place the inside interface in our dmz or corporate network, because you would be by-passing our firewalls altogether. 

     

    See if you can get an answer on the public IP address on the NIC question from any of the forums or Microsoft.

    Please let me know your thoughs on this response.

    Thanks

    Frank

    Monday, April 5, 2010 4:18 PM
  • Hi Frank,

    Check this out

    http://blogs.technet.com/tomshinder/archive/2010/04/01/uag-directaccess-server-deployment-scenarios.aspx

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, April 6, 2010 5:36 PM
    Moderator
  • Here's our Network group response to your replys.

    I understand Microsoft’s explanation on where the external server “could go”.  Here are my thoughts and issues;

     

    ·         I have never allowed Protocol 41 through my external Firewall.  I believe that I could specified a specific protocol number instead of TCP or UDP, but it has never been tested, so there for I cannot say with certainty that it would work. 

    ·         Although I understand the NAT itself is not a security layer, it is how our network is setup.  We cannot put a Public IP Address on your interface because our DMZ servers sit on the <NATTED address here..for our security > address space.   The ONLY way for your server to have a REAL public IP Address physically assigned to your NIC would be to place it on the public segment, outside of all firewalls and security layers. 

    ·         My other issue I have is the dual interface design. We can overcome the dual interface design as long as the server is not by-passing any firewalls in the process of routing traffic.  For example, if you place the server on the public segment, outside of all firewalls, we will NOT allow you to place the inside interface in our dmz or corporate network, because you would be by-passing our firewalls altogether. 

     

    See if you can get an answer on the public IP address on the NIC question from any of the forums or Microsoft.

    Please let me know your thoughs on this response.

     

    Thanks

     

    Frank


    Looks like they have given you few options :(

    The only real way to achieve what you need and keep them happy is:

    (1) Create a new public DMZ that uses a new public IP address range; the external firewall can then packet filter and route this subnet from the outside world.

    (2) Create a new private DMZ that uses a new private IP address range; the internal firewall can then packet filter and route this subnet to the internal network.

    (3) Connect the UAG external interface to the public DMZ and connect the UAG internal interface to the private DMZ.

    If (1) is never going to possible and you cannot connect UAG to the public segment, then sorry but looks it like DirectAccess is not going to happen for you...

    Cheers

    JJ 

     


    Jason Jones | Forefront MVP | Silversands Ltd
    Tuesday, April 6, 2010 11:44 PM
    Moderator