We are testing DTTS and so far it’s working great at blocking unwanted applications. One issue we’ve noticed that is when users connect to legitimate work VPN’s, external browsing gets blocked. Our theory is that it’s because when we connect to Global Protect, it sends down some new DHCP servers (our internal ones) and then the client start resolving DNS through those servers. So we can browse networks that are being sent through the VPN tunnel (corporate 10.x.x.x), but although we can resolve google.com, etc, we can’t reach them because DTTS is unaware of those sites being resolved because the resolution is happening on 10.0.0.12 instead of the pfSense server. If that assumption is correct, is there a workaround for this? Thanks
Hi welcome to the forum @Steffan_Vigano
So DTTS would have no effect over traffic destined over the VPN tunnel, so I’m wondering if the tunnel is successfully being established at all. Here’s what I would check.
- If your VPN is connecting via DNS, make sure it’s being allowed (see the MyTools log)
- If your VPN connects via an IP, you’ll need to create an enabler rule for the destination IP and any ports that your VPN app is using. From the MyTools log select the Traffic Log to see any blocked IP ports.
Create a new Enabler rule for the publlic IP that your VPN server is running on and enable it in your policy(ies)
Also see adam:ONE Operational Instructions and Guidelines for general guidance.
So further testing by myself and colleagues confirms that we’re all seeing the same thing. Once we connect to the VPN (via hostname) the connection is fine, but we can no longer browse anything outside of our internal network via the VPN tunnel. Some sites that were already resolved while not connected to the VPN, still work. But anything new does not. Oddly, even some of the sites that were resolved by the pfSense DNS server also stop working. Not sure if that’s related to very short TTL’s or what. For example, I can see the MyTools site while not connected to the VPN, but as soon as I reconnect to VPN, I can lo longer reach that site. Same with basic pings to that site. I can resolve and ping it when not connected. But when I connect, I can only resolve it (likely cached) but not ping it.
Looking at DNS servers, I do see both the VPN supplied DNS server internal to our network, and the DNS server of the pfSense segment that DTTS is running on.
It sounds like your VPN is a split tunnel and your DNS is going to a remote server when connected to the VPN but regular Internet traffic is still routing via your local connection.
Because DTTS relies on DNS queries, and now is not seeing them this would explain the behaviour you are seeing.
There’s a few options. First is to have the VPN a full-tunnel, but then you loose the adam:ONE features unless you have it on the remote site.
In which case you may want to look at this article Active Directory Configuration which talks about how to configure an environment with AD and DNS.
The other option is to set the VPN server to not supply DNS so that the client end continues to use their local DNS server (adam:ONE in this case).
Makes sense that split tunneling would break functionality now that I think it through and test it more. Unfortunately, since this is a guest network, the VPN settings for various scenarios are out of our control. So sadly, because we host so many guests that are on “working vacations”, it looks like DTTS is not a viable option for us. Please do let us know if something changes with the architecture/design that might prompt us to circle back, as we do like the overall concept.