UAG SSTP: Can only access the UAG Host subnet


  • My company is currently evaluating UAG.  I was able to get it installed, get remote administration set up (with the help of this forum- thx), create a portal and an SSTP application.  Users can access the page and installl the SSTP client.  However, once connected, users are only able to reach machines that are on the same subnet as the SSTP server.  They can't get to any of the other networks listed on our internal adapter.

    I'm assuming this is related to the network configuration.  My external NIC is in the DMZ on a 192.x.x.x subnet- this NIC has the default gateway.  My internal NIC is in my client LAN on a 10.x.x.x subnet.  I created a static route to ensure all traffic on the 10.x.x.x can find the gateway.

    Can anyone tell me what I'm doing wrong, or a log I can look in to better understand the problem?

    Monday, August 15, 2011 9:08 PM


All replies

  • Hi Friedman,

    you should take a look to the TMG "Logs & Reports" console node, to get some additional information aboud the lost packets. If TMG has some problems while forwarding the packets the log will most likely contain some additional informations and sometimes even the exact reason.

    I'd like to recommend to set the TMG Log filters to display "Ping" packets only. After do some tests where...

    1.) The UAG server pings machines on the internal subnets.

    2.) The UAG server pings the default gateway connecting the different subnets.

    3.) The VPN clients pings machines on the internal subnets.

    4.) The VPN clients pings the default gateway connecting the different subnets.

    5.) A machine on the internal subnet pings a VPN client.


    Tuesday, August 16, 2011 6:57 AM
    • Proposed as answer by ZarkoC Tuesday, August 16, 2011 1:46 PM
    • Marked as answer by FriedmanJ Thursday, August 18, 2011 9:26 PM
    Tuesday, August 16, 2011 1:39 PM
  • That did it!  Thank you very much Dr. Troy.
    Thursday, August 18, 2011 9:27 PM
  • Hi Friedmann,

    glad it helps in your case. But i've to mention that the "easiest way is not always the best way"^^

    The setting you did does have some impact on the VPN functionality. When enabling NAT for your VPN Clients you simply cant access the VPN clients from internal devices (manage out) and sometimes it will also conflict with "complex protocols" which are using for an example multiple in/outboud connections. This was the reason why i tried to help you finding the real cause of your routing problems instead of recommending the NAT setting...

    If you're interessted in fixing the routing issues you have seen and to reenable routing of VPN client connection, then let me know...


    Friday, August 19, 2011 12:03 PM
  • Kai,

    You present a compelling case.  Any reason I can't turn off NAT, run the tests, and then turn NAT back on while I review the report, understand the problem, and am prepared to fix it?


    Friday, August 19, 2011 12:10 PM
  • Hi Jeffrey,

    to not interupt your (now) daily business you could create a dedicated "TMG Network Rule" for a single VPN Client IP address (e.g. your test maschine). The new rule has to be placed on top of the original VPN rule to overwrite the existing NAT releationship. On this way you can disable NAT for just a single client without interupting the others. Once done, you will be able to monitor where the packets are getting lost in a routed releationship (but don't redial the connection too often, since it will most likely cause in getting a new IP resulting in additional TMG rule changes).

    You should start to inspect the IP adress pool from where the VPN clients are getting their IPs assigned. There is a big difference in having DHCP enabled IPs (routing problerms are less likely) or using a static IP pool (routing problems are more likely).

    DHCP enabled addresses will most likely be not a problem since they appear on your internal network as additional hosts (done via simple Proxy ARP aka. L2 Bridging).

    But in the case of using static IP pools, you have to make sure your internal network knows to forward those IP addresses to the internal UAG interface (L3 Routing instead of Proxy ARP). Make sure the destination servers will have an active route to the VPN IP Scope set. If they only have a default gateway set, then you have to make sure the intermediate routers knows the correct route to the VPN pool. Follow each hop and also check if intermediate routers have some ACLs set who may filter out the packets^^

    BTW: The route from your UAG machine to your internal network is already healthy - otherwise thé NAT scenarion would't work. So i already took that out of the equation...


    Friday, August 19, 2011 12:53 PM
  • troy thank you

    Cüneyt E. ORHUN

    Friday, April 05, 2013 9:10 AM