DirectAccess in split mode: How to route clients traffic to the one specific Source-IP-Firewalled webhost on public internet? RRS feed

  • Question

  • Hi,

    We have some third-party webservice that allows access only from predefined IP addressess. Is there any way to define that DA-clients route traffic through DA-server back to the internet webhost?

    I would like to keep Split mode rather than change to the Force tunnel mode. There is only one service that needs predifined IP.

    How about some proxy.. is configuration available in split mode..


    Monday, November 27, 2017 2:08 PM

All replies

  • You can define the site's hostname in your NRPT and assign it your corporate DNS servers. That will force any request for that namespace over the DirectAccess connection. Be advised this doesn't always work correctly and that you may need to define an internal proxy server for this to work correctly, but I've done this before and it does work. :)
    Monday, November 27, 2017 9:39 PM
  • Yes, this is a pretty common request and can definitely be accomplished. There are two things necessary to make this work:

    1. Name resolution - as Rich stated, you need to create an inclusion in the NRPT so that the public DNS name of that web service resolves inside the DirectAccess tunnels.

    2. Routing - you need to make sure that your DA server knows how to route the traffic appropriately. On a single-NIC DA server this usually doesn't require any additional config, but on a dual-NIC DA server it means you need to add a static route for the public IP address(es) of that public web service in as internal routes on your DA server. This is exactly the same process you would have taken when you initially setup your DA server with routes for all of your internal corporate subnets. The DA server must consider this traffic to be "internal", so that it passes the user's request along to the internal network, where it will naturally route outbound from there using your datacenter's public IPs, which are the IPs that are whitelisted by the third-party webservice.

    One additional note: Some of these webservices don't allow ping replies (ICMP) on their public IPs, in other words if you ping the public DNS name of that service, it will resolve to an IP but you will never get ping replies. If this is the case (I run across this every time I work with Okta), then your IP-HTTPS connected clients will be able to contact that web resource just fine through the DA tunnels, but your Teredo-connected clients, if you have any, will fail to connect because Teredo requires the ability to ping the resources that it is communicating with. So in organizations that want to use a service like this (like Okta), we must ensure that all of the DA clients connecting to our DA server are using IP-HTTPS, essentially just meaning that we disable Teredo on the clients in their environment. Depending on how your DA server is setup, you may have Teredo disabled/unused anyway in which case this would not be an issue you would have to consider.

    Thursday, December 7, 2017 2:08 PM