Tunnel Network vs Application Private Network

Sorry for the basic question but whats the difference between setting a private network under the tunnel and a private network application? I think I am fundamentally not understanding the differences between them and they both seem like they try to accomplish the same things.

From what I can tell it looks like when I set up a private network (eg 192.168.4.0/22) I get access to everything on the network. This seems to work fine. Is this basically like a VPN replacement? If so that makes sense.

Now If I only want to expose an app or two I would have thought all I needed to do is delete the tunnel network add an application with IP and port policies. This however does not seem to work. For example if I add a rule for my Homarr dashboard @ 192.168.4.50:7575 it does not load. Using the above private tunnel network though I can. Is there a reason why this not working? Let’s say this did work, would you say this is the preferred way of granting access since its way more fine grained?

Are we supposed to use one over the other or both in conjunction?



You got the idea right, if you want to expose the complete network then go with the private network option else if you only want to expose a single port for a domain/sub-domain go for public hostname but for the public domain option you are directly exposing your service to the world and you might have to restrict the access using “access rules” (if you want to restrict it).

Else with the private network option, I believe (I can’t completely recall as I used this a few months back) you have to use the CloudFlare warp client (on whatever device you are on) and then login to your <your_team_name>.cloudflareaccess.com from the client so that you’ll be authenticated to the CloudFlare’s global network and later you have multiple options whether to allow your private network’s traffic via cf’s network or not, I did it via using “split tunnels” option under the warp client settings (under the default profile but you can create your custom).

I believe (I can’t completely recall as I used this a few months back) you have to use the CloudFlare warp client

Correct. You need the WARP client basically for mTLS.

I’m more confused on what the difference between the private network tunnel configuration vs the private network application. I’ve updated the original post with some images so its a bit clearer.

Here is the difference, actually it is written in the dashboard itself.

ref: https://imgur.com/1hlhIIS

This however does not seem to work. For example if I add a rule for my Homarr dashboard @ 192.168.4.50:7575 it does not load.

If you can share your config and how you are running your homarr I can help with it.

Thanks for the help I’ll post when at my desktop later.

I understand your comments on the image but how is that different than the first image? The first image is under Access —> Tunnels —> Configure whereas the second image is for Access —> Applications. The configuration is completely different for both so there must be a use case I’m. It thinking of.

The use case is that whenever you add either your complete network or a single service via cf tunnel you can access those right away (you already know about the config/warp client setup for the private network one)

With regard to your concern about 2nd image, it is shown in the dashboard page itself: https://imgur.com/IeMAvjr

Basically, you can have a layer7 firewall for your applications

If you want to actually see that in practice try adding a few policies to both of these, you’ll understand a little better that way.

And that the relation b/w 1st image and the 2nd one.

In 1st image you create and configure your tunnel and set it to be public or private (via your cf team access only) and in the 2nd image you further configure who can access and at what level your tunnel applications (public) or tunnel network (private).

This works on the zero trust policy and should be used that way if you are trying to set it up for multiple people. By the term zero trust “each device/user provides its authenticity continuously in a zero trust setup” (there are more definitions to it).

If you want to understand more for this cf config, feel free to add your comments here, I’ll be happy to help as I struggled a lot when I tested these things myself and it was a little hard to get answers either here or in cf’s community forums.

Seriously thanks.

Everything makes sense but I can’t confirm which is killing me. If I add my network to the tunnel private network I can access everything. Ok cool. I would logically think I could add an application rule to block certain services by ip, port or whatever. This doesn’t seem to be the case.

Ok, so now if I delete the tunnels private network and whitelist an application by ip/port that should surely work right… nope.

For the tunnel configuration do you have to chose public or private?

You don’t have to necessarily go with the private network part until and unless you always want to access your service (or complete network) using ip addresses with services matching the port numbers.

If you only want to access your homarr dashboard outside of your homelab (I’m assuming that’s why you’re using homarr in the first place) then you can directly use a sub-domain/domain (assuming you own a domain and you either managing only dns of cf or your have set the complete ownership of your domain on cf, works either way) and that you can access publically. Note: This way you’ll only be mapping a single ip:port (a single service) to a sub-domain/domain

But if you want to go with a complete network, go with a private network and the only difference is the warp client (gateway).

I know you already understand these^ but wrote again for the context and better understanding.

Now if you ask that you delete the private network (which is not required in the first place if you are just trying to access your homarr service outside of your homelab via cf tunnel) your service is accessible as long as you’ve correctly setup the public hostname (again it can be a sub-domain/domain).

For tunnel configuration you can with either of the options depending upon your use case as described above^. Both the configs are not required at the same time until and unless you’ve a special case which covers both public access for a service and private access of a network.

If this still doesn’t answer your question, I would ask you to rephrase your query and provide a few more details of your setup.

Let’s ignore the public Homarr use case, I was just trying to come up with an example as I’m trying to understand. A better question would be to say if I was an organization and I granted access to employees (only warp client access) how would I do either of the following

- Whitelist access to a select number of service ips/ports

- Explicitly deny access to certain service ips/ports

For me it seems like if I add the network in the tunnel private config then everything is allowed regardless of application allow/block policies. If i don’t have any tunnel config (public or private) and only add application policies then I can’t seem to access anything.

No no, you are mixing things.

If you want to set up this for an organization then you can definitely restrict the access as well.

To make it easy to understand, let’s assume you have an aws vpc 10.0.0.0/16 (not the default one, assume you created a new one), right?

Now assume you created an instance in the same vpc with CloudFlare tunnel installed in it. To completely get the benefit of tunnel (or in general opening a connection from inside rather than outside by opening a port as it is generally done in cases where a VPN is used) I would suggest you to use the use data scrip for the instance to install cf tunnel and at same time setup a ssh server or for another check you can also create an nginx server.

Do note, do not add any incoming rules to the security group attached to this instance, only add outbound 0.0.0.0/0

Now once your instance is up and running, you can confirm whether your tunnel it up or not by checking the cf tunnel dashboard.

Once you confirm that the tunnel is up and running, now add your vpc’s address to your “private network” under the tunnel configuration.

Now suppose you want to ssh in your instance or access your private nginx server running locally on our instance, you need to turn on your warp client (on whichever device you are trying to access your services from) and login to your cf team in order to access your zero trust (or CloudFlare access).

Before you proceed make sure you also set this vpc’s network range under the “split tunnel” section of your warp client settings.

Once you do that, now you can just directly use any of the ip’s that comes under your vpc’s network with appropriate port mappings and it will be like as in your are inside your vpc accessing your services. But do not that all this traffic is routed via cf’s network.

Now coming to your query about how to restrict access. Make sure you’ve completed all these^.

And to proceed with, go to acces and “add an application” (in this case it will be self hosted) and soon as you do that you’ll have multiple options based on the fact that whether you want to restrict a particular ip:port mapping or the complete network and all the other required options are there once you start adding access policies as per your needs. For instance, you can restrict based on people (say) in your GitHub organization or in your google suite or google application access or emails ending with (say example.com). There are plenty of options you have to make sure that you can access your services normally before proceeding with access policies.

A bonus will be, now assume you’ve another vpc2 and your peer it with vpc1 then one case is that you can ssh in the machine (we discussed^) and directly access resources in peered vpc as well (assuming you’ve not set any complex restrictions based on sg level or subnet level etc.) OR another way is go to your tunnel “private network” config and add this vpc2’s network their as well and you can directly access your services then even from the vpc2.

Once you so this^ you can proceed with the access part, it is not too difficult but having a working setup before you put any access policies will make your understanding a little more easier, I would suggest you to give this a try.

Thanks. I’m going to play around with this today to better understand. :folded_hands:

Ok everything you said made sense. The one key piece I was missing and why nothing was working as expected:

By default, all WARP devices enrolled in your Zero Trust organization can connect to your private network through Cloudflare Tunnel. You can configure Gateway to inspect your network traffic and either block or allow access based on user identity and device posture.

Once I enabled the gateway and TLS decryption I was then able to properly deny access to my resources.

Kind of odd that its a blocklist as opposed to an explicit whitelist but doesn’t affect me much.