none
SSTP woes on two Node NLB array RRS feed

  • Question

  • Hi All,

    I'm in the process of setting up a two node UAG array and SSTP access is the first thing on my list.

    Setting up SSTP seemed to be pretty straight forward, but my Win7 client would not connect via an DialUp applet, but would connect via the portal (Remote Network Access). Event logs on the UAG showed "no Remote Access permission". I finally figured out that for some reason no users were configured in TMG (TMG --> Remote Access Policy --> Specify Windows Users). Not sure if this is supposed to be configured by the UAG Mgmt console or manually.

    Now I can connect using a DialUp applet (NLB address on the outside), but I have no connection to internal resources. Static IP assignements for both UAG nodes are configured (172.16.255.x) and the Internal Network is on 192.168.1.x.

    So I probably need a route on the internal network for the return packets, right? The question is, where do I send the return packets to? NLB on the internal NICs is not configured and - as far as I've read - shouldn't be. Meaning if my client VPNs to Node1 the return route is different than if it connects to Node2 (depending on which node has the trunk at any point in time).

    I'm starting to think that SSTP VPN is not possible with an NLB array ...

    Thx in advance for help and/or pointers.
    Rgds - M.

    Thursday, September 8, 2011 1:41 AM

Answers

  • Hi Marcus,

    first of all UAG is responsible for maintaining the entire VPN configuration, so every configuration change outside of UAG will most likely become overwritten when you reboot the server or reapply UAG configuration.

    To have to user to VPN directly to the TMG VPN services (without loggin in on the UAG Portal first) you have to "Allow VPN Acces" on each of the User Account objects in Active Directory. On this way you can overwrite the RRAS default rules - which are normaly deny every remote access connection which was not initiated through the UAG Portal.

    The second thing is your routing issue. Both UAG node will use unique IP Scopes for the VPN connection, so you have to make sure the pools are routed back accordingly to the right UAG. Enabling NLB on the internal Network Interfaces is not supported by the UAG team (although it may work), so the official supported way would be creating the releated routes for each of the VPN pools on your network equip.

    Example Cisco Configuration:

    ip route 172.16.255.0 255.255.255.128 192.168.1.1
    ip route 172.16.255.128 255.255.255.128 192.168.1.2


    Where 172.16.255.0/25 and 192.168.1.1 is the VPNPool and internal IP of UAG1 and 172.16.255.128/25 and 192.168.1.2 is the VPNPool and internal IP of UAG2.

    -Kai

    • Proposed as answer by Ran [MSFT] Thursday, September 8, 2011 9:53 AM
    • Marked as answer by MarcusB Thursday, September 8, 2011 7:08 PM
    Thursday, September 8, 2011 7:26 AM

All replies

  • Hi,

    I configured NLB for the internal NICs. Than you can use the virtual IP as Gatway for the VPN-Network. It works ...

     


    Viele Grüße Carsten
    Thursday, September 8, 2011 5:40 AM
  • Hi,

    I configured NLB for the internal NICs. Than you can use the virtual IP as Gatway for the VPN-Network. It works ...

     


    Viele Grüße Carsten

    However, Carsten, this is not supported, as Marcus said, except for DirectAccess.
    -Ran
    Thursday, September 8, 2011 7:21 AM
  • Hi Marcus,

    first of all UAG is responsible for maintaining the entire VPN configuration, so every configuration change outside of UAG will most likely become overwritten when you reboot the server or reapply UAG configuration.

    To have to user to VPN directly to the TMG VPN services (without loggin in on the UAG Portal first) you have to "Allow VPN Acces" on each of the User Account objects in Active Directory. On this way you can overwrite the RRAS default rules - which are normaly deny every remote access connection which was not initiated through the UAG Portal.

    The second thing is your routing issue. Both UAG node will use unique IP Scopes for the VPN connection, so you have to make sure the pools are routed back accordingly to the right UAG. Enabling NLB on the internal Network Interfaces is not supported by the UAG team (although it may work), so the official supported way would be creating the releated routes for each of the VPN pools on your network equip.

    Example Cisco Configuration:

    ip route 172.16.255.0 255.255.255.128 192.168.1.1
    ip route 172.16.255.128 255.255.255.128 192.168.1.2


    Where 172.16.255.0/25 and 192.168.1.1 is the VPNPool and internal IP of UAG1 and 172.16.255.128/25 and 192.168.1.2 is the VPNPool and internal IP of UAG2.

    -Kai

    • Proposed as answer by Ran [MSFT] Thursday, September 8, 2011 9:53 AM
    • Marked as answer by MarcusB Thursday, September 8, 2011 7:08 PM
    Thursday, September 8, 2011 7:26 AM
  • Well duh - I guess I've been looking at the screens for too long. You're (of course) right, Kai - the IP pools are assigned to each node, so I can add a static route per pool.

    Regarding the dial in permission: changing the setting on the user object was the first thing I tried - that made no difference. Only after adding my AD VPNUsers group in TMG was I able to connect.

     

    Which leads me to a (somewhat broad) follow up question: how much should I be messing around in TMG on a UAG system? (I confess to be a UAG newbie, but I guess I could consider myself an ISA/TMG veteran)
    Obviously I want to stay away from things like NLB settings or modifying the UAG generated rules, but what about, for example, adding rules to TMG - things like redirects for published Exchange (example: http://mail.domain.com --> https://mail.domain.com/owa).

    Thx again to everyone in this thread!
    Rgds - M.

     

    Thursday, September 8, 2011 7:08 PM
  • Hi Marcus,

    > Regarding the dial in permission: changing the setting on the
    > user object was the first thing I tried - that made no difference.
    > Only after adding my AD VPNUsers group in TMG was I able to connect.

    Could be a caching or AD replication problem? What i've explained should work with the UAG out-of-the box rule set. So i would recommend to reapply the UAG configuration and also reboot your box. This procedure will most likely reconfigure the entire VPN configuration.
    I addition you may take a look to your local NPS rules. You should see three rules which are all set to DENY dial-in. The point is here, that only the AD setting (aka. don't control /w RRAS policy) or the UAG RRAS hook would be able to overwrite the rule action from DENY to ALLOW and threfore grant access. 

    > Which leads me to a (somewhat broad) follow up question: how much
    > should I be messing around in TMG on a UAG system? (I confess to be
    > a UAG newbie, but I guess I could consider myself an ISA/TMG veteran)

    For UAG starters i would strongly recommend to not change that much even if you're an TMG professional. It may cause some trouble if you change the wrong things (e.g. VPN!) and will also cause some unexpected behavior which are hard to troubleshoot even for UAG veterans^^
    The official word on this question is "only a few scenarion" (see link below) are "supported" by UAG Team.

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

    > Obviously I want to stay away from things like NLB settings or modifying
    > the UAG generated rules, but what about, for example, adding rules to
    > TMG - things like redirects for published Exchange (example:
    > http://mail.domain.com -->https://mail.domain.com/owa).

    If your familiar with the TMG socketpooling workarounds then you could mix those things together with the UAG IIS stuff. But remember its not supported by CSS /PSS so there may be a chance that some patches or servicepack may break this configuration or will simply fail durring installation. So you're pretty much on your own when problems arive! Personally i have glued almost all TMG and UAG feature together - but i'm using two dedicated machines which are side-by-side deployed for this task.

    BTW: The exchange redirect part you've mentioned can be done using UAG only. But i've to agree the TMG rules would be easier to configure in this case^^

    -Kai


    • Edited by Kai Wilke Thursday, September 8, 2011 9:47 PM
    Thursday, September 8, 2011 9:47 PM
  • Kai,

    thx for your comments and help.

    You are correct, reapplying the SSTP configuration removed the entry I did in the TMG VPN config, now I'm back to getting "no Remote Access privilege" event log entries.

    I did reboot both UAG nodes, so it can't be a chaching issue. Also verified replication on all my DC's. Not sure where to go from here.

    Thx again!
    M.

    PS: I'm assuming you're referring to the "Manual URL Replacement" in the Trunk Config for the Exchange redirect?

    Thursday, September 8, 2011 11:16 PM
  • Hi Marcus,

    > I did reboot both UAG nodes, so it can't be a chaching issue. Also verified replication on all my DC's. Not sure where to go from here.

    As i said, the remote access is completely controlled by the local NPS policies. And if something goes wrong in your deployment, then the problems should be found in NPS. Well, i recommend you to review and post the NPS policy configuration here in the forum...

    > PS: I'm assuming you're referring to the "Manual URL Replacement" in the Trunk Config for the Exchange redirect?

    Unfortunately, this configuration setting wouldn't have any impact on OWA. The OWA redirect is a very special case and causes a lot of headaches. But yesterday (right after my reply to your thread), i've posted a solution for this task here in the forum which will streamlines the OWA redirect thing very much. Take a look to the bottom of...

    http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/877b0bc2-b730-4a39-b747-a83f66b52fb7

    ... its a very tiny UAG customization which does the trick for you. The provided code in addtion to a HTTP-to-HTTPS redirect trunk is all whats needed to get those initial "mail.domain.de + hitting enter" request redirected to https://mail.domain.de/owa/

    -Kai


    • Edited by Kai Wilke Friday, September 9, 2011 10:08 AM
    Friday, September 9, 2011 9:28 AM
  • Hello Kai,

    NPS only had the three deny rules you mentioned in a post above somewhere. I don't have a central NPS deployed yet, so I added a policy to the local NPS on both nodes.

    Just for my own sanity: is this the correct approach?

    Thx again for you patience :)
    Rgds - M.

    Saturday, September 10, 2011 12:13 AM
  • Hi Marcus,

    on the next reboot your rule will either become moved to the bottom and therefore overwritten, or it will got deleted^^

    -Kai

    Saturday, September 10, 2011 5:03 AM