NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

NetMotion Mobility for DirectAccess Administrators – Split vs. Force TunnelingDirectAccess employs a split tunneling network model by default. In this configuration, only network traffic destined for the internal network (as defined by the administrator) is tunneled over the DirectAccess connection. All other network traffic is routed directly over the Internet.

Force Tunneling Use Cases

For a variety of reasons, administrators may want to configure DirectAccess to use force tunneling, requiring all client traffic be routed over the DirectAccess connection, including public Internet traffic. Commonly this is done to ensure that all traffic is logged and, importantly, screened and filtered to enforce acceptable use policy and to prevent malware infection and potential loss of data.

DirectAccess and Force Tunneling

Enabling force tunneling for DirectAccess is not trivial, as it requires an on-premises proxy server to ensure proper functionality when accessing resources on the public Internet. You can find detailed guidance for configuring DirectAccess to use force tunneling here.

NetMotion Mobility and Force Tunneling

With NetMotion Mobility, force tunneling is enabled by default. So, if split tunneling is desired, it must be explicitly configured. Follow the steps below to create a split tunneling policy.

Create a Rule Set

  1. Open the NetMotion Mobility management console and click Policy > Policy Management.
  2. Click New.
  3. Enter a descriptive name for the new rule set.
  4. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Create a Rule

  1. Click New.
  2. Enter a descriptive name for the new rule.
  3. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Define an Action

  1. Click on the Actions tab.
  2. In the Addresses section check the box next to Allow network traffic for address(es)/port(s).NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  3. In the Base section select Pass through all network traffic.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Define the Internal Network

  1. In the Policy rule definition section click the address(es)/port(s) link.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  2. Click Add.
  3. In the Remote Address column select Network Address.
  4. Enter the network prefix and prefix length that corresponds to the internal network.
  5. Click Ok.
  6. Repeat the steps above to add any additional internal subnets, as required.
  7. Click Ok.
  8. Click Save.
  9. Click Save.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Assign the Policy

  1. Click on the Subscribers tab.
  2. Choose a group to assign the policy to. This can be users, groups, devices, etc.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  3. Click Subscribe.
  4. Select the Split Tunneling policy.
  5. Click Ok.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Validation Testing

With split tunneling enabled the NetMotion Mobility client will be able to securely access internal network resources over the Mobility connection, but all other traffic will be routed over the public Internet. To confirm this, first very that internal resources are reachable. Next, open your favor Internet search engine and enter “IP”. The IP address you see should be the IP address of the client, not the on-premises gateway.

Summary

I’ve never been a big fan of force tunneling with DirectAccess. Not only is it difficult to implement (and requires additional infrastructure!) the user experience is generally poor. There are usability issues especially with captive portals for Wi-Fi, and performance often suffers. In addition, enabling force tunneling precludes the use of strong user authentication with one-time passwords.

With NetMotion Mobility, force tunneling is on by default, so no configuration changes are required. The user experience is improved as NetMotion Mobility intelligently recognizes captive portals. Performance is much better too. In addition, NetMotion Mobility is more flexible, allowing for the use of OTP authentication with force tunneling. Also, with NetMotion Mobility force tunneling is not a global setting. You can selectively apply force tunneling to users and/or groups as necessary.

Additional Information

NetMotion Mobility as an Alternative for Microsoft DirectAccess

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Enabling Secure Remote Administration for the NetMotion Mobility Console

NetMotion Mobility Device Tunnel Configuration

 

Leave a comment

5 Comments

  1. Dazza

     /  April 7, 2020

    Does netmotion mobility have the ability to split dns requests like Direct access does by use of the NRPT table. We are trialling Netmotion at the moment as part of a POC and cannot see a way to split dns traffic.E.g our punblic domain fqdn is the same as our internal domain fqdn and we would like certain hosts to be resolved via public dns and not by our internal dns servers?

    Reply
    • Absolutely. Starting with v11.50 you can tunnel traffic by hostname or FQDN using NetMotion Mobility. For example, if your internal and external domain name is example.com, you could choose to route all requests for example.com over the tunnel, but exclude things like http://www.example.com, mail.example.com, etc.

      Reply
  2. Dazza

     /  April 8, 2020

    Hi Richard – Thanks for your reply. We managed to pass through traffic to specific hosts/ip addresses, etc. The bit we are struggling with is the name resolution. E.g. The address given back to the client from the dns server is still the internal address, not the public address. So even when we pass through traffic to the attended host address (which works), we still have names resolution taking place by the internal dns server responding with the internal address (incorrect). I think what we are after is to have name resolution requests be excluded from the tunnel for specific destination hosts. This is in relation to Skype 2015 traffic when out of the office. E.g sip.domain.com should be resolved by its external dns record.

    Reply
    • Ok, that makes sense. I don’t believe there’s a way around this in the current release. However, this will be an option in the next release. Not sure when that is coming though. Hopefully soon. 🙂

      Reply
  1. DirectAccess Selective Tunneling | Richard M. Hicks Consulting, Inc.

Leave a Reply to Richard M. HicksCancel reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading