none
UAG not Accepting HTTP/HTTPS requests RRS feed

  • Question

  • I have setup UAG on a Windows 2008 R2 box. The server and UAG have been updated with the latest patches.

    I have done the following experiements:

    Pinged mail.company.com from Company workstation & home pc
         o   Failed to connect and this showed up in the logs as denied

    ·       Telnet on port 23 to mail.company.com from Company workstation & home pc
         o   Failed to connect and this showed up in the logs as denied

    ·       Telnet on port 443 to mail.company.com from Company workstation & home pc
         o   Failed to connect and this DOES NOT show up in the logs

    ·       In IE browsed to https://mail.company.com/owa from Company workstation & home pc
         o   Failed to connect and this DOES NOT show up in the logs

             I then turned off all UAG/TMG services and tried the same test as above and was not able to connect to any of the same ports

              I have been insured that packets from our Cisco firewall are getting to this box even though nothing is being logged in the TMG logs. I watched our network admin sniff the network port on the UAG to show me packets are getting though to the box and being drop there.

              I am at a lose here and not sure what I should look at next. I am able to browse the portal from the server itself, but not from any other machine.

     

    Friday, August 26, 2011 10:56 PM

Answers

All replies

  • Hi,

    can u verify that uag is listening to these ports doing a netstat -an|find ":443"? I want to know if the ports are opened on the UAG box?

    Cheers

    Andreas


    Andreas Hecker - Blog: http://microsoft-iag.blogspot.com/ Please remember to use “Mark as Answer” or "vote as helpful" on the posts that help you.
    Friday, August 26, 2011 11:49 PM
  • Yes it looks like only UAG is using these ports.

    Netstat results:

    TCP    0.0.0.0:443            0.0.0.0:0              LISTENING
    TCP    192.168.73.4:11158        192.168.19:443         ESTABLISHED
    TCP    192.168.73.4:11159        192.168.73.20:443         ESTABLISHED
    TCP    [::]:443               [::]:0                 LISTENING
    Saturday, August 27, 2011 12:25 AM
  • Start by doing some general network checking. Ensure that you have a default gateway listed on your External connection and NOT on your Internal connection. And make sure you have a DNS server specified on your Internal connection and NOT on your External connection. Then in UAG, launch the Network Interfaces wizard from the Admin menu and walk through that again. Make sure your Internal and External NICs are propertly defined, and also make sure that your internal IP ranges are correct, and that your external subnet is not included in the internal network definition. Oh, before running this wizard you also want to ensure that routing is assigned properly on your UAG server. Because you do not have a default gateway on the Internal NIC, you need to statically define any internal routes that might be necessary to flow communications to your other subnets successfully.

    Saturday, August 27, 2011 2:30 AM
  • thanks for the reply Jordan. I have gone through all the general networking settings. All network settings on the UAG is setup as you recommended.

    I beleive the network settings are setup correctly because I can ping the server, I get no reply but it is registered in the TMG logs as denied (which is expected). Whenever a connection to http/htts is tried it is not logged in TMG. I am under the impression that there is a service or program that is blocking the http/https traffic. With the netsat info above I beleive shows that port 443 is listening properly.

    I am wondering if the issue maybe is in IIS. Is there any recommended settings I should go over with IIS?

    Saturday, August 27, 2011 1:40 PM
  • No, on a UAG server the only reason you should ever have to touch IIS is for requesting and importing certificates, otherwise all IIS settings are configured automatically by the UAG activation process. If you do not see anything logged in TMG, my first inclination is that the traffic is not getting to the server. I would have the firewall administrator check over the config again to make sure 443 is allowed and being routed through properly. I have actually seen problems just like this numerous times, and every time we triple check everything on the UAG because the "firewall is properly configured" - only to find out in the end that the firewall is not actually properly configured.

    You could also try doing a telnet to port 443 for some testing. Try doing it from a machine that is on the same external network as the UAG's external interface to see if you can make a socket connection to port 443 from there, and then try the same thing from an externally connected client. If you can make a successful telnet connection from the same subnet as the UAG's external interface, but cannot connect from the internet, once again that is likely a misconfig on the firewall.

    Just for a test you could also try plugging the UAG directly into the internet if it's possible. If it works there but not behind the Cisco, then you know where the problem lies.

    Saturday, August 27, 2011 3:28 PM
  • Hi,

    you do not need to change any settings within iis. As you mentioned it is just an idea but do you run any 3rd party software on uag, especially av? Perhaps this piece is blocking inbound traffic.

    Cheers,

    Andreas


    Andreas Hecker - Blog: http://microsoft-iag.blogspot.com/ Please remember to use “Mark as Answer” or "vote as helpful" on the posts that help you.
    Saturday, August 27, 2011 3:38 PM
  • Ok found out from the network guy how the network is setup.

    We are using a cisco box that is handling the load balancing to the UAG servers. This box is the one with the VIP.

    I am almost positive it will take an act of congress to get this changed to have the UAG server handle the VIP.

    So my question now is how do I set the UAG to publish applications when it is not hosting the VIP on the server itself?

    Monday, August 29, 2011 3:53 PM
  • Ok Think I found some part of the answer. I have a very similair setup as this poster:
    http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/9d6ccd80-2a2b-4b50-8f24-1e5b9a24a01d#2659d483-65b0-4448-a404-ff11b5d1d831

    I also have my UAG configured to use the DIPs instead of the NLB VIP. I am still not able to access the OWA published application.

    I checked the TMG logs and I see the requests being denied:

    Denied Connection
    Server02 8/29/2011 4:29:17 PM
    Log type: Firewall service
    Status: The policy rules do not allow the user request.
    Rule: Default rule
    Source: External (IPADDRESS:58254)
    Destination: External (VIPADDRESSFROMLB:443)
    Protocol: HTTPS

    Additional information
    Number of bytes sent:
    0 Number of bytes received: 0
    Processing time: 0ms Original Client IP: IPADDRESS

    What else needs to be set inorder for this to work?
    Monday, August 29, 2011 11:15 PM
  • Ok Think I found some part of the answer. I have a very similair setup as this poster:
    http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/9d6ccd80-2a2b-4b50-8f24-1e5b9a24a01d#2659d483-65b0-4448-a404-ff11b5d1d831

    I also have my UAG configured to use the DIPs instead of the NLB VIP. I am still not able to access the OWA published application.

    I checked the TMG logs and I see the requests being denied:

    Denied Connection
    Server02 8/29/2011 4:29:17 PM
    Log type: Firewall service
    Status: The policy rules do not allow the user request.
    Rule: Default rule
    Source: External (IPADDRESS:58254)
    Destination: External (VIPADDRESSFROMLB:443)
    Protocol: HTTPS

    Additional information
    Number of bytes sent:
    0 Number of bytes received: 0
    Processing time: 0ms Original Client IP: IPADDRESS

    What else needs to be set inorder for this to work?


    Hi,

    Please see Kai's answer on your other thread http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/9668ea27-7693-4897-964d-fa03567a7da8:

     

    Hi BD142001,

    since the destination address of the denied packet is your VIP address i would guess the Load Balancer is accessing the wrong external IP?

    -Kai

    Regards,
    -Ran
    • Marked as answer by bd142001 Tuesday, August 30, 2011 2:40 PM
    • Unmarked as answer by bd142001 Friday, September 9, 2011 2:46 PM
    Tuesday, August 30, 2011 7:06 AM
  • Found out what the issue is. We have the UAG servers setup on VSphere 4.1.0. Whenever I had NLB enabled I could not connect to the portal as stated above. In a VMware KB (linked below) it stats that UAG's NLB needs to be set to Multicast.

    I set the UAG's NLB to Multicast, saved and activated and it did not work. For one reason or another I needed to rebuild the NLB. I removed it from UAG save and activated without the NLB. Then rebuilt it with Multicast as the mode.

    Using Unicast mode in VSphere
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556

    Using Multicast mode in VSphere
    http://www.vmware.com/files/pdf/implmenting_ms_network_load_balancing.pdf
    Top of page 3.

     

    • Marked as answer by bd142001 Friday, September 9, 2011 2:46 PM
    Friday, September 9, 2011 2:46 PM