0:02Hi everyone. How's everyone doing? You've got your second, third, fourth coffee of the day. There is a matcha bar I've heard downstairs. You're all awake because I'm not. You'll have to wake me up. So this will be an interactive session. Hopefully I hate to talk for more than five minutes straight. So please indulge me into some sort of conversation. My name is Nikitsa. I'm a product manager for Cloudflare Tunnel, Cloudflare Mer... workers, VPC, Cloudflare One Appliance and so and so and so. Who here knows what Cloudflare Mesh is? Raise your hands. Okay, we've got a few hands. Who used Cloudflare Mesh? Okay, in production. Okay, the goal of this session is for you to try Cloudflare Mesh today once I step off the stage.

0:56I want you all to try and install it and test it in your environments because it's a cool product. Who here uses Tailscale? Raise your hands. Okay. Why? If you're using Tailscale, chances are Mesh is gonna interest you, especially if you have workloads hosted at Cloudflare, right? If you're using developer platform, if you're already using Cloudflare Tunnel, if you are using For reasons I do not know, but people are using WAN still, Mesh is going to be an interesting product for you. But the one thing that makes Mesh a very timely product, we launched this in April this year, is because agentic connectivity.

1:43And I managed to narrowly avoid saying AI, LLM or agent in my previous session for 45 minutes. That is not going to happen here. We are going to talk agentic stuff. So I do apologize for that. But if you have AI workloads or agentic workloads, right? The previous authentication model and the previous networking firewall strategy does not really work. If you have a person clicking the buttons, you can show them an authentication screen. You can put it behind Cloudflare Access. an idp you can mint their identity through some sort of idp right agent unless you are creating agents as employees in your hr systems which i've heard some people do not sure it's the right approach but you know the idea is out there um you are probably not having an agentic identity in your systems so how do you actually verify which agent that is, who is the owner of that agent and which permissions, which scopes this agent should have in this particular environment.

2:57So the problem of agent identity is a really big problem. If you know Ann Mink or Kenny Johnson, PM4Access, and you are interested in this problem space, go talk to them. They have a really cool solution that's coming later this year. I'm more with what is happening on layer 4. So if you have machine -to -machine traffic, server -initiated traffic, you still may have agentic stuff happening in between those two nodes. You may have an open claw. You need that open claw to access Postgres somewhere else. How do you make sure that this open claw doesn't do dodgy stuff in other parts of your private network?

3:44right that is my biggest concern so when open claw became a thing people without asking us or without reading any of our documentation just naturally arrive to the answer that the best thing to protect open claw is cloudflare tunnel you put cloudflare tunnel in front of open claw you close all of the inbound ports so now nobody can um potentially exercise any malicious against your private OpenClaw instance. But that only protects your OpenClaw from public internet. It doesn't protect your private networks from OpenClaw itself, right? So Mesh is a potential answer to these things. So you may have had VPN. That's good for users as long as you deploy per app policies.

4:34You may have had jump host, bastion host, you need to SSH into server machine, into Metal, into VM, Kubernetes container, whatever you have. Engines don't play well with VPN because it's all or nothing in most cases. You don't want to expose everything that you have to agents. They are not deterministic. They can hallucinate, as Michelle said on the previous session, so they can be trusted. You probably don't want an engine to try to SSH into your production environment and do something. You don't even want that to, you know, to access your production database. Like, they can just run a delete SQL query and you go and figure out where your backup is for that. Some people are then doing what is called pure zero trust, which means expose all of your stuff on public internet, publish it as public endpoints, and then protect this with zero trust policy engine.

5:34Engines cannot go. behind the paywall behind the logging page screen unless you give this some sort of browser rendering capability and tunnel doesn't help either because tunnel only off ramps traffic so tunnel does not support server initiator traffic so if you have machine running open claw that machine will be protected from public internet as I said but it won't be able to access private network just because you are running open claw there so We need some sort of different pattern in there, which supports bi-directional connectivity, preferably protocol agnostic, at least for layer seven protocols, and allows you to exercise policy controls against any type of network traffic that exists in your environments.

6:26So we're not gonna expose anything publicly. We're not gonna hand over the keys to our entire private network. if it's a VPN, to an engine. So what are we gonna do? We are gonna protect the fastest growing, the scariest scenario that exists in your private networks. So AI agents do stuff, people in your companies ship whatever they want in under three hours. Your security teams are probably horrified because now we need to detect where these apps are. they are hosted and where corporate data ends up and you don't want to have that so what if the policy control was the network itself um mcp servers is another example of that same problem mcp server essentially stands between something that is very important in your production environment and something that lives on the internet or at least uh in your client endpoint that needs some sort of mediated access so you can trust the identity of the user or the server machine that tries to get into your, say, ICD or runbook in a wiki or internal API, right?

7:43So we have three products. They are connectivity products. We actually have more, but to simplify, let's talk about these three. So Tunnel is great when you are exposing public applications to the Internet. It supports Layer 7 traffic. really well use it for http applications and apis that you need to expose on the public internet or you need to put them behind cloudflare access that is the most elegant and simple solution out there cloudflare mesh is what we're talking about right now is a bi -directional connectivity for devices and service containers vms it's a layer -free connector mask fully post -quantum encrypted end-to-end if you attend that Sharon's session about post-quantum cryptography yesterday, you know that every single thing that ships in Cloudflare 1 is post-quantum encrypted end -to -end.

8:32We are using exactly the same client endpoint agent called Cloudflare 1 client, also previously known as warp, to power mesh connectivity, but we extended that warp CLI to become a subnet router. So not only the device that runs warp CLI gets access to your private network, it's also everything that lives inside the same private network that can access your other private networks through that Mesh node as a gateway. And if you install Mesh node in your VPC gateway, you don't even need to configure return routes. It will just work. And then Cloudflare 1 is for situations when you need one gig plus throughput, or for example, you need to manage LAN and DHCP in a retail branch.

9:21So you need some low -level networking capability that is really not natively available in a Layer 3 or a Layer 7 connector. So that is when you start deploying one.

9:34So, everything in your network becomes a Mesh participant. Every single device that runs Cloudflare 1 client or a Mesh node gets a private IP. By the end of this year, every single device... that runs in your Cloud Flava network will also get a private host name and you don't need to host DNS for this. This is called MeshDNS. And they can start a conversation using these IPs in TCP, UDP, ICMP, you name it, without you having to configure a single route. Because Warp CLI creates a virtual network interface on your device that runs Warp CLI and alters your routing table to tunnel traffic for all... routes that exist in Cloudflare 1 without you having to lift a finger. So all the traffic that you want to send to Cloudflare, which probably should be the majority of your traffic, the only exception to this should be stuff that literally lives inside the same container, for example, get sent to Cloudflare Mesh, and that means that it gets sent to Cloudflare Gateway, which means that all of your network, firewalls, DNS, HTTP policies get automatically applied to this traffic without you having to configure anything.

10:52If you already have gateway, the moment you create a mesh node, that mesh node is also subjected to all of your gateway policies. We have shipped selector that allows you to create custom tailored policies that target specifically mesh nodes. And we have also added extensive logs in network session logs. So now you know which mesh node or receive the traffic which mesh node and which replica of a mesh node receive the traffic and if you are using workers vpc to talk to mesh nodes you also get which worker script with name and id originated this traffic for you so it is based on cloudflare one client but there are two different applications so i'm nikita i'm going to use my laptop so i'm going to install cloudflare one client because my identity should of Nikita.

11:41If I'm doing Cloudflare mesh node it's probably some sort of headless environment that is Linux or container based. It shouldn't have an identity of a person, it should have a machine identity. So currently as of today all mesh nodes they have separate IDs but they share the same identity. So the way for you to configure policies is to use IPs. Very soon you will be able to give each separate mesh node its own identity it target each mesh node individually by its name or id using gateway policies and as always with cloudflare it's all terraformable it's api first and we have cfcli which you can ask your agent to use to configure all of this in literally under three minutes like the other day i've asked cfcli to spin up a completely new fresh account which mesh nodes with log push pushing my network session logs from mesh into r2 bucket and it was all working in under three minutes like it's as easy as that cool so the beauty of cloudflare one is that you don't need to choose in this specific moment which ramp you are going to use if you are already using tunnel raise your hands quiz using tunnels very good so if you are already using tunnel you are probably already having some gateway policies in there when you plug in mesh node in there the same policies apply so you

13:12can pick and choose which connectivity strategy you want to have and all of the policies that live in cloudflare will apply to all of this traffic so mesh is best for connectivity between containers connectivity between clouds connectivity between developer platform and whatever on -prem environment you have it creates your own private net without you having to manage address space or DNS for that environment. So you can connect things that physically live in many different locations and they will form part of the same mesh network. The cool thing that we really want to do is we will do mesh DNS, but I will talk about that in a few minutes. So how do you actually spin this up?

13:58It's as easy as you go into a Cloudflare dashboard, Networking Mesh. create a new node at the participant. You get a token generated. For people who use Cloudflare Tunnel, you are very familiar with this setup. Mesh gets exactly the same token, hash of your account tag plus secret, and you execute on the mesh node, warp .cli, connector, new, and that token. From that moment onwards, mesh node gets an IP from cgnet range that is configured in your account, and it can immediately talk to any other nodes from the same system. in that range. What is really cool about Mesh is that workers and developer platform can become part of that private mesh network too. So you can use workers VPC and you can tell workers VPC using the binding whether you want to give access to the whole Cloudflare 1 network, so all mesh nodes or clients, all tunnels to your worker and to a great...

14:58as well so for example if you want to apply gateway policies on aggress traffic to public internet and you are using workers you can send traffic from worker to the cf1 network binding which is the match binding and your gateway policies will be applied and this traffic will be locked in your logs so you can filter aggress traffic from your workers durable objects and containers using this which is really cool um we want to do the reverse of that which is be the biggest thing we'll launch next year so your workers durable objects containers will get a private ip and private host name that is part of the same mesh network so this compute feels like it's a local compute to your environments that you host in other clouds in your on -prem and you don't need to either host dns or figure out overlapping ip spaces or how to DHCP this. We are taking care of all of this.

15:54So you can have two nodes talking to each other with overlapping IP space and they will be able to talk to each other without you having to do anything except for installing mesh nodes in two places. So you have either one VM or one container in AWS, another one in GCP. You add a route and they can talk to each other. That's it. You can set this up in five minutes. This is entirely private trust. It does not go on public internet. All of the traffic between two mesh nodes transits through Cloudflare backbone. It's all post-quantum encrypted. It does support high availability. You can have up to five replicas per mesh node. It's active-passive. And you can attach the whole subnets to the nodes, as well as hostname rounds for both public and private traffic that supports wildcards.

16:46So essentially, you can express policies like this mesh node needs support this slash 16 and this mesh node needs support needs to support this slash 24 and it will just work on all of the devices that are connected to cloudflare one regardless of how you connect it can be endpoint client can be one can be pack files it works with everything at the same time you can say this mesh node should be an exit node for for example google .com because for some reason google .com expects your traffic to come from your ip that is one ip you add cost-name route to your mesh node and now anyone in your cloudflare1 network when they request google .com they will go to that node and the traffic will exit with your ip not with cloudflare ip gateway egress ips are also supported so if you have a requirement that all of your traffic should leave a public internet on a specific ip that you expect but you don't want to bring it on cloudflare network we can lease you that IP, it will be attached to your Cloudflare One account and Meshnodes, as all other Cloudflare One products, will also guarantee that this traffic leaves on the public internet using these egress IPs.

17:59And it works for workers as well. So if you attach CF1 network binding and you have egress IP configured in your account, all traffic that comes from a fetch in the worker will leave Cloudflare and go on public internet using that egress IP. so works for everything pretty much you can put a private mcp server behind it with access to whatever information application storage compute you have and you can configure gateway policies who exactly can access and do what with this application for example you can configure a policy that this group of users can have read access to this this group of users can have right access to this this group of users doesn't even get to resolve this dns entry so they don't even know that this internal application exists in your network all of this can be expressed with gateway and because it's a cloud native thing it also works with whatever containerization solution you use i strongly recommend using mesh in a kubernetes sidecar scenario because you get to keep your pods and containers as they are.

19:14You put sidecar in front of them. Mesh in containers handles source nutting, so you don't need to configure return routes for Docker containers. And that way, you can scale horizontally without having to manage IP space in your containers whatsoever. You just think about sidecar as some sort of little concentrator that routes traffic to other pods, and it just works out of box. We have open source. the image as well for this. It's in GitHub, in SendDockerHub as well. So installing it takes probably five, seven minutes and we have really good developer docs for this. So go try it out. The way we do hostname routing is interesting. I did explain it on the previous session, but just so that it's not a surprise for you. When you attach a hostname route to a mesh node, we don't know which actual IP is servicing this application.

20:07until this DNS record resolves. So for example, you get db.internal. That db.internal is hosted somewhere in your private network and you have a DNS server for this. So we don't know which IP, for example, 10 .0050 is servicing this. So we can't return it back to the agent. What we are doing is we are sending back a token IP, a placeholder IP from a public Cloudflare-owned slash 20. range that is then proxy in traffic for this specific user for this specific hostname to the actual destination of the exit point and it works beautifully with both private applications and public applications and you don't need to configure any policies for this token ips if you have a gateway policy either for db .internal or for that ip 10 .0050 both will apply so you get the luxury of configuring nobody can access this host by the IP, but the specific user groups can access this application by this host name, even if you block the IP that is actually listening, that the service listens on.

21:22SourceNUD works in containers. We will ship SourceNUD in probably a month or two for all of the nodes. It will be a flip switch. So... Anybody understands what source that is? Okay, so when you use Cloudflare Tunnel, when packet hits Cloudflare D that is running on the host machine, we terminate that session, we clone that packet, and we send it into your private network with the source IP of the host machine that runs Cloudflare D. That allows you to avoid configuring the return route for an actual device that sits behind Cloudflare D. Because if you don't have that, For example, I come from a different private network. That IP doesn't exist in the network where Cloudflare tunnel is. So the actual device behind a mesh node or behind a Cloudflare tunnel doesn't know how to send traffic back there.

22:12SourceNet uses the IP that already exists in that network, and then that packet gets sent to the right sender. So SourceNet works out of box and containers, and you will be able to flip the switch on any mesh node in a few months so that you... don't have to configure return rounds at the expense of losing in your own logs the real IP of the sender, of course. You will see the real IP of the sender and the real identity of the sender in gateway network session logs, but inside that private network that is source netted, you will see the IP of the host machine, so you'll have to correlate your logs with gateway network accession logs to understand who sent this. But for the sake of simplicity, this setup usually works for most customers. The policy plane is exactly the same, and every single feature that works for Cloudflare One client for Linux works for Mesh out of box. You can even do device posture checks.

23:06I don't know why anybody would do device posture checks on server machines, but if that's your thing, go and do this. It works out of box. DLP as well. If your agent tries to send credentials or financial information with something... to public internet, gateway policy will drop that.

23:29So, start with connectivity. Just make one mesh node talk to another mesh node. You can do this in under five minutes. You will get the IP that you ping. Once you have a successful ping, you know that these two nodes can talk to each other. And then you can explore the full capabilities of Cloudflare One and SASE. platform and configure exactly which policies, which primitives you want to use to segment your traffic and secure your company or your environment, your CI, CD. You don't need to do this on day one. The beauty of this is connectivity takes five minutes and then you can add policies on top of it when the time counts.

24:15Network session logs will have the identity, the destination time, and every time. else you will see bytes transferred as well. So there won't be a situation where connectivity is a black box and you don't know how traffic is flowing through Cloudflare. You will see exactly where it entered with which identity and where it exited with which identity and this is available today. And you can use lock push to send this to your scene, data lake, whatever you have. So there are a couple of mistakes just keep that in mind. If you are trying to use Cloudflare Tunnel as a side gateway or as concentrator, jam clause, bastion, don't do this because it's one direction and tunnel was never supposed to do that job. Even if it can send TCP and UDP, don't do this. Don't forget to configure return routes if you don't want to use source NAT, otherwise devices won't know how to return traffic.

25:06Don't confuse routes with replicas. This is interesting one. The concept of replica is kind of unique. cloudflare tunnel and cloudflare mesh other providers allow you an hour one as well allow you to put a priority weight and a region on a route so your routing table is not deterministic it is dynamically evaluated and picks the healthy note right we do the reverse your route is always deterministic if you attach 10.10.10.10 to one mesh node, it doesn't matter whether that mesh node is online or offline. So how do you make it highly available?

25:53You spin up multiple replicas of that mesh node, which serves exactly the same tunnel, essentially, and that is how you make it highly available. Don't look for priorities and weights and regions for a mesh. Think about this as replicas. Replicas are femoral. They are clones of your tunnel or of your mesh. and you use routes to configure how traffic flows there. Split tunnel is a feature that allows you to configure which traffic should stay in your network and use your default network interface and which traffic should go through Cloudflare. This is very useful if you have other applications that live inside the same container or inside the same network that you don't want to flow through Cloudflare. Our network is 50 milliseconds away max from anything, some situations, if the same application lives on the same server, why would you send it all the way back if this is privileged access that you have already granted, right? So you can exercise this.

26:48And then CF1 network binding is the easiest way to grant access to your entire private network, to your worker durable object and by extension container. Ask yourself the question, do I trust people who have access to deploy workers in my... account to have access to all applications you can configure gateway policies to say that this worker or default binding cannot reach that segment of your network but zero trust should be by default right deny by default and only allow what you need to allow so be very careful with the binding that just opens your whole network up um takes five minutes to to build uh go try it out documentation is all there and we give 50 seats and 50 nodes for free to everyone when the time comes it's currently in beta when we go ga there will be some sort of usage based billing but we will give terabyte or more free traffic to everyone monthly so you can keep using it for free that's it any questions