locked
UAG and IP configuration for Portal site RRS feed

  • Question

  • Hi,

    We are in the process of implementing UAG. I have the software installed on the server and have referenced the material on correctly setting the IP configuration on internal and external adapters. This has all been picked up fine. It appears that our network setup is different to other scenarios mentioned in reference material. I'm struggling to get the Portal site to work as it should or be accessible. I will try to describe our network setup in the hope someone may be able to point me in the right direction.

    Internal NIC IP address - 10.x.x.x

    External NIC IP address - 199.x.x.x

    The 199.x.x.x network is actually behind a firewall so the external address in DNS for the server is a 213.x.x.x address which then has a static translation through to the 199.x.x.x address for ports 80, and 443.

    I can access the Portal site to some extent from another machine on the 199.x.x.x network. I'm unable to access the Portal site from the 213.x.x.x network. The UAG external address is configured as the 199.x.x.x address. Due to the way DNS points to the 213.x.x.x address the Portal doesn't load properly when accessing from a machine on the 199.x.x.x network.

    This may sound very confusing if it would help I could host a diagram somewhere to show the setup. It appears I'm missing something from the configuration for this type of setup but rather than randomly change setting thought I'd post here.

    Thanks for any help.

    Wednesday, April 21, 2010 4:53 PM

Answers

  • Based upon your analysis, it would appear that there must be something wrong with the NAT'ing, external firewall policy, gateway on UAG or the actual public IP adderss itself (IP accidently outside subnet range etc.)

    What is the default gateway (or routing) on the UAG server? Does this return traffic to the firewall correctly?

    If you can see inbound traffic leaving the firewall and not being returned, the problem must lie with UAG network configuration. The fact that the portal responds from 199.x (e.g. on subnet) implies UAG is cofigured correctly. If you use a local hosts file on another 199.x machine, this should work correctly and avoid the DNS problems while you are testing.

    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 Erez Benari Wednesday, April 28, 2010 12:23 AM
    Thursday, April 22, 2010 1:35 PM

All replies

  • You configuration is quite common, almost all IAG/UAG deployments I have done are the same way.

    However, we don't encounter any issues with portal access, as long as your certificates and DNS are all good.  We do have to tweak some settings for the Network Connector application to work with the NAT'd address.

    Can you describe in detail the errors you are seeing with the portal?  Will be helpful in narrowing down the cause.

    Wednesday, April 21, 2010 5:39 PM
  • At the moment I've setup a simple HTTP trunk in an effort to remove as much complexity as possible to diagnose the issue. If I try to get to the portal from a machine out on the internet I get no response at all. I've tried the Superscan tool to do a HTTP Get and HTTP Head request and nothing comes back at all. Completing this on another machine on the 199.x.x.x network gets a reponse back. The portal doesn't complete properly though due to the DNS entry for the site pointing to the 213.x.x.x address which seems to be unreachable  as described above.

    Would I have missed a step in the configuration? I've literally setup a basic trunk with OWA published.

    Thursday, April 22, 2010 8:14 AM
  • Based upon your analysis, it would appear that there must be something wrong with the NAT'ing, external firewall policy, gateway on UAG or the actual public IP adderss itself (IP accidently outside subnet range etc.)

    What is the default gateway (or routing) on the UAG server? Does this return traffic to the firewall correctly?

    If you can see inbound traffic leaving the firewall and not being returned, the problem must lie with UAG network configuration. The fact that the portal responds from 199.x (e.g. on subnet) implies UAG is cofigured correctly. If you use a local hosts file on another 199.x machine, this should work correctly and avoid the DNS problems while you are testing.

    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 Erez Benari Wednesday, April 28, 2010 12:23 AM
    Thursday, April 22, 2010 1:35 PM