How to Access DFS File Shares over Cloudflare Tunnel

When I think of “Cutting-Edge remote access software” it’s difficult to include SMB in that conversation. DFS file shares feel like legacy technology with all the modern cloud storage solutions that exist today. Combine that with the massive increase in SaaS applications, and suddenly you might wonder why anyone uses DFS file shares at all.

The truth is that some organizations don’t move fast enough to abandon legacy technology. Other organizations use tools that don’t fit well into the cloud storage environment. In my case, it’s because I can. Honestly, it’s that simple. Why worry about cloud storage, if my laptop has an always on VPN. I pay next to nothing for my Home Lab storage, and I don’t need to access it from my phone. Why not see if we can make it work?

I’ve spent some time previously talking about Azure AD App Proxy, and Cloudflare Tunnels for providing secure access to on-premises web applications. Now it’s time to look at the more advanced features of Cloudflare Tunnel, to see what else we can configure. Then in a future blog post, I intend to cover Twingate, a ‘Zero-Trust Network Access’ (ZTNA) alternative to Cloudflare Tunnel, to determine which works better for the lab.


Please understand that the content herein is for informational purposes only. This existence and contents shall not create an obligation, liability or suggest a consultancy relationship. In further, such shall be considered as is without any express or implied warranties including, but not limited to express and implied warranties of merchantability, fitness for a particular purpose and non-infringement. There is no commitment about the content within the services that the specific functions of the services or its reliability, applicability or ability to meet your needs, whether unique or standard. Please be sure to test this process fully before deploying in ANY production capacity, and ensure you understand that you are doing so at your own risk.

Table of Contents

Understanding Split Tunneling
WARP Client Configuration
Cloudflared Server Settings

Understanding Split Tunneling

If you already understand Split Tunneling, feel free to skip ahead to the WARP Client Configuration…

Using a Split Tunnel with any remote access tool is really not a new concept, but that doesn’t mean it isn’t new to you. When you think about how network traffic is routed, it is important to understand that every network connection and device is looking to pass a packet along to the next hop. Whether it is a physical device like a switch or router, or it is a virtual device like a VPN ethernet connection, each device is looking to pass a packet on to the next network device.

A split tunnel then, means that traffic is routed through different network devices depending on properties of the packet or the destination of the packet. In the case of a VPN or remote access tool like ZTNA, a split tunnel usually refers to a method of separating network traffic bound for the private network from the traffic bound for the public network.

For Example:

  • If my VPN has a split tunnel configuration, it may have a rule that says “network packets headed for the IP range get sent across the VPN connection”. If is my ‘on-premises’ or private network, then any packets that are directed towards the on-premises network will be sent down the tunnel.
  • Alternatively, if a packet is headed for a normal internet IP address, then the packet will be sent across the internet connection instead of the VPN tunnel.

This is an important concept to understand for two main reasons:

  1. It is an important networking concept to understand in general, both for configuration and troubleshooting reasons. Understanding routing in general is critical, and Split-tunnelling a part of routing typically associated with remote access and VPN.
  2. In your Cloudflare configuration, you will have to choose whether you want an “Include” split tunnel, or an “Exclude” split tunnel before you can make any configurations.

Why might you choose one type or the other? Realistically, it depends on how you are trying to enforce protection.

“Include” Split Tunnel

An “Include” split tunnel will only allow the traffic that you configure to access the VPN/ZTNA tunnel. So if my ZTNA tunnel is configured for Include mode, then only the networks and IP ranges I specify will be included in the routing for the ZTNA tunnel. This lets the virtual network adapter know what is available over the tunnel, and what is not. Anything that is not Explicitly defined as being available over the tunnel, will be sent out the regular internet connection.

“Exclude” Split Tunnel

An “Exclude” split tunnel on the other hand, will require that all network traffic be sent over the VPN/ZTNA tunnel, EXCEPT for the IP ranges included in the exclude list. This type of split tunnel configuration assumes that everything be sent over the tunnel. The only network packets that don’t use the tunnel, are ones that are explicitly told not to.

Why Choose one over the other?

Split tunneling was created because as network traffic grew, network devices (like firewalls) were struggling to keep up with the amount of network traffic they were having to process. Split tunneling allowed for devices to pass network traffic over a different interface unless is specifically needed access to the VPN network, which reduced the demand on those edge network devices.

Modern ZTNA solutions have changed some of the arguments about split tunneling, and now the reasons to split traffic are not as cut and dry. There are more considerations when choosing how and when to split network traffic, and there isn’t a “one-size-fits-all” that works for everyone. Here are a couple use cases to help illustrate the point.

Example Use Cases for Split Tunneling

  • You have the ZTNA/VPN solution deployed. You have limited resources on the back end and want to ensure that your remote access solution doesn’t get overloaded with traffic. Configuring a Split tunnel to only INCLUDE traffic bound for the internal network, would mean that those internal network devices won’t have to work as hard to process the traffic. It is only processing traffic that is inbound for the specific network defined in the policy.
  • Your VPN/ZTNA solution includes features like private DNS, custom aliases and secure internet access. As a result, you want to ensure that all network traffic, including the internet traffic, is processed by your VPN/ZTNA solution. In this case you would configure the tunnel to EXCLUDE traffic that you did not want to send down the tunnel, as the default is to send EVERYTHING down the tunnel. This way you can ensure that all traffic is managed and filtered by your ZTNA/VPN solution except for the things that you want to exclude (like perhaps Microsoft Office Updates traffic…)
  • When using the VPN/ZTNA Tunnel, you might need to provide access to local printers or network devices. If you are managing this for a large business, it is challenging to manage an EXCLUDE rule for every single user, so you may only INCLUDE specific traffic to allow local LAN access for these network devices and printers automatically.

To be fair, there isn’t a “right” answer here. It’s up to you to understand what the requirements are, and design based on whatever use cases you are trying to solve. That is why it is important to understand how and why split-tunneling exists and when to use it. Understanding this will help in the next section.

WARP Client Configuration

Now we are ready to start looking at setting up SMB. I’m working from the assumption that you already have a file share available to use. If not, you’ll need to make one. I have a DFS Namespace that I am using as this is common in many businesses who leverage Windows Server OS for file shares. For my ‘on premise’ devices, this maps automatically via group policy, and now I want to make sure that I have it available over the VPN as well. Also be sure to have the correct permissions on the file share. If you cannot access the share on the network, you won’t be able to access it over the tunnel either.

There are 2 main settings that we need to configure.

  • Local Domain Fallback
  • Split Tunnels (Include or Exclude)

Now something else to note, is that I have my lab laptop joined to my local domain. I am signed in as a domain user. I say this because the DNS suffix for the domain is configured via GPO in my domain. This allows me to not need to use FQDNs for everything I am connecting to. If you are running into issues with this, then make sure you have the DNS suffix configured in your network settings.

Local Domain Fallback

Here is what Cloudflare has to say about Local Domain Fallback.

By default, Cloudflare Zero Trust excludes common top-level domains used for local resolution from being sent to Gateway for processing. These domains are resolved by the local DNS resolver configured for the device on its primary interface. Since these DNS requests bypass the Gateway resolver, they are not subject to Gateway DNS policies or DNS logging.

Cloudflare Documentation

Essentially, this allows you to specify DNS servers other than the gateway to attempt to resolve names against. Here is where you will want to add your on-premise DNS server(s).

  1. In the Cloudflare settings, go to Zero Trust -> Settings -> WARP Client. From there go to Profile Settings and click the three dots to configure whichever profile you are using. In my case, I’m just using the Default profile. (This setting will need to be configured for each profile you want to use these DNS settings.)
  2. Scroll down to Local Domain Fallback and click Manage. Fill out the settings for your internal domain and save changes. (You can use a comma to separate multiple IP addresses for DNS servers in the same domain.)
configure local domain fallback for dns servers to access dfs file shares
  1. This will add your local domain to the profile. This ensures that anything with the domain suffix you provide, will NOT use Cloudflare DNS servers, but rather the DNS servers you indicate. Add any more domains or DNS servers you want to include, then click back to Profile.
  2. Scroll to the bottom and save the Profile to commit the changes. It usually takes about 5 minutes or so for the profile to update on the workstations.

Split Tunnel Configuration

Next, we need to configure the Split Tunnel to include our specific protocols. This calls back to the beginning where we talked about Split Tunnels and when to use them. Presently, mine is configured as an INCLUDE split tunnel. Everything we specify in the next section will be sent down the Cloudflare network tunnel. This means that everything else will use my local network connection.

The only difference in this area for an Exclude Split, is that anything you add in this next section will NOT be sent down the Cloudflare network tunnel. Everything else will be sent to Cloudflare and routed appropriately.

Split Tunnel Settings (INCLUDE Configuration)
  1. In the Cloudflare settings, go to Zero Trust -> Settings -> WARP Client. From there go to Profile Settings and click the three dots to configure whichever profile you are using.
  2. Scroll down to Split Tunnels and note what your settings are. In my case, mine is set to Include IPs and Domains. Click Manage.
  3. In the list, choose an IP Address or Domain. The IP Address uses CIDR notation and can accept a range or a specific IP address. for DFS shares, you’ll want to include the actual domain as well as a wild card domain configuration.
ip address ranges and domains for split tunnel configuration for access to dfs file shares
  1. Once you have included everything you want to be sent to the Tunnel, save settings and click Back to profile.
  2. Scroll to the bottom and save the Profile to commit the changes. It usually takes about 5 minutes or so for the profile to update on the workstations.

Cloudflared Server Settings

The last piece we need to configure is to ensure that the server hosting our Cloudflared Tunnel, is configured to use QUIC as the primary protocol. SMB over the tunnel isn’t supported over the default protocol. There are 2 different ways to configure the tunnel to run over QUIC.

I’m including links to the documentation for each of these options because they are both clear enough to understand.

I can tell you a few things about my experience with both options.

Change the property in your Config File

Whether I did something incorrectly in the beginning or not I am not sure, but I did not get a config file created automatically. I had to manually create one. Not a big deal, the documentation is pretty clear about how to do it. Where I struggled was finding the <tunnel id>.json file needed for the config file.

The default location for this file is C:\Users\%USERNAME%\.cloudflared for the username used to create the tunnel initially. If you check this location, and don’t find it, you will need to do what I did ultimately which is to Run the Tunnel as a Service.

Otherwise, edit your config profile to include protocol:quic and save the config. Restart the service, and you should be set.

Run the Tunnel as a Service

When I ultimately decided to do this, it successfully created the <tunnel id>.json and config file I needed. The thing to understand is that this will generate a new Standalone tunnel in your Cloudflare console. I did not realize this initially when I started. This meant I needed to follow a few additional steps to bring it around correctly.

  1. Convert the Standalone tunnel to a managed tunnel in the Cloudflare console.
  2. Move Public Hostnames in the Tunnels configuration to the new tunnel.
  3. Move Private networks to the new tunnel.

This didn’t take too long, but it is something worth knowing as you may want to spin up a separate tunnel on a separate server if you are already using the original. After these steps though, the config file should be able to be edited to include protocol:quic and should work as expected.


There it is! This was a bit of a long one, but we got through it. This post calls back to my original reason for posting in the first place. I had some trouble finding some clear instructions on this process myself, so I wanted to organize it into a single document. Admittedly, not everyone will need something like this. DFS Servers are becoming a thing of the past, and other storage options are cloud native already. Even still, there is something to be said for always on access to your self-hosted storage. It provides a stopgap for anyone not interested in paying for cloud storage, especially if they already have plenty of storage in the lab available.

Through this experimentation I’ve become a big fan of the Cloudflare platform and options they are offering. I love when companies have a free tier for home lab and testing purposes. I also love that Cloudflare supports smaller businesses to have access Enterprise level tools at an affordable rate. It really demonstrates how Cloudflare takes security seriously.

Well I hope you found some value in this post. If you were like me and had trouble finding a clear solution, then I hope this helps. As always, let me know what you think and if this worked for you. Hit me up on Twitter @SeeSmittyIT to let me know what you thought of this post. Or if you are avoiding the bird site, I’m also posted up on Mastodon @[email protected]. Thanks for reading!


Curtis Smith works in IT with a primary focus on Mobile Device Management, M365 Apps, and Azure AD. He has certifications from CompTIA and Microsoft, and writes as a hobby.

View all posts by Smitty →