Local vs remote traffic handling / split-horizon DNS?

I have a set of servers inside my network that I would like to be able to access from outside my network, and the Argo Tunnel seems to be a good idea. But unless I’m reading the documentation wrong, it seems like the cloudflared client handles all of the authentication and that all traffic would go through Cloudflare regardless of if I’m in the local network or not.

Is there some documentation on how cloudflared handles situations like these and if I can configure some sort of split-horizon DNS based on local vs. not local connectivity?

You can in your own DNS… it violate the ZTNA, but if it resolves locally it wouldn’t go to Cloudflare and thus won’t be subject to security inspection policies. Assuming your internal network is more trusted or more secure is an option, but not one that I’d recommend. <source: am the insider threat>

I have a similar question. If I use Cloudflare for all my servers inside my own network, will all traffic be routed through Cloudflare? Client -> Cloudflare -> Server -> Cloudflare -> Client instead of Client -> Server -> Client?

And will I therefore be charged for traffic to and from my own servers when I’m on the same network?

Is split horizon DNS the proper “solution” to this “problem”?

Thought I’d chime back in here with a quasi-solution to this, at least for SSH. In my ~/.ssh/config file I’ve defined the SSH host which I’ve preceded with a Match command that runs a very simple bash script.

Match host the-host !exec "ping -t 1 -o dns-internal-test.internal &>/dev/null"
    ProxyCommand /path/to/your/cloudflared access ssh --hostname %h

Host the-host
    HostName the-host.example.com
    User username
    ForwardAgent yes
    IdentityFile /path/to/ssh/key

dns-internal-test.internal is a locally resolvable DNS name that the local DNS server can resolve. Don’t put an IP address here, because there is a chance your local IP addressing scheme is the same as a possible remote site, especially if you’re on something like 192.168.1.0/24. If the address resolves and is therefore pingable, then cloudflared isn’t invoked. But if that address doesn’t resolve and is therefore not pingable, the server is not local and cloudflared is invoked.

Hope this provides some help!

Split-horizon DNS will get you part of the way there, but there is also some additional tinkering that you have to do to make it work as you’d expect. As I wrote in my reply above, SSH requires some additional configuration in the ~/.ssh/config file for cloudflared to be invoked in a certain situation.

As for other things, like web apps, split-horizon DNS will get you part of the way. Say you have an app running at webapp.example.com, which is at 192.168.1.2. Your local DNS server has to be able to resolve webapp.example.com IN A 192.168.1.2. (That also means that if you have HTTPS enabled, you have to get a certificate through some other means, because if you only have the Cloudflare origin server SSL certificate, you’ll get a certificate error.) On Cloudflare, you have to have example.com as one of your zones, and either use something like Argo Tunnel or put in the publicly accessible IP address to that server for it to work, so webapp.example.com IN A [public IP address] or webapp.example.com IN CNAME [argo-tunnel-guid].cfargotunnel.com..

Hope that helps.