1️⃣ Gateway Traffic Egress Policies

Good day, everyone. Hello. My name is Tim Obezuk and welcome back to Cloudflare TV. This week is a special programming segment because we're in the middle of Cloudflare One Week, where we're announcing new innovations for products and partnerships and features within the Cloudflare One space, which is our global Networking as a Service. As I mentioned, I'm Tim Obezuk. I'm one of the product managers for Cloudflare's Zero Trust Suite. And I'm joined with Ankur Aggarwal, who is also one of our product managers for Browser Isolation. Today, this segment, this is about dedicated egress IPs from Cloudflare's Zero Trust Network and Cloudflare Gateway. And we're going to be talking about that throughout this session. But, before we get started, I'd just love, Ankur, for you to briefly introduce yourself. Sure. Yeah. Thanks for that intro, Tim. My name is Ankur Aggarwal, product manager for Gateway, Cloudflare Gateway. It's the secure web gateway that's a part of our Zero Trust Suite of products here at Cloudflare. We'll kind of dive a little bit into just Cloudflare One in general, Zero Trust, and then we can start kind of diving deeper and eventually kind of get to dedicated egress and egress policies, which we want to talk about today. Thanks, Ankur. Yeah, so to get started, let's talk briefly about Cloudflare One and Zero Trust and what we're building here. And I think it's talking about dedicated egress IPs is really fitting into the history of why we're building a Networking as a Service, because with Cloudflare One, we're building a network to replace all those historical Band-Aid boxes, like secure web gateway boxes, DLP boxes, VPN boxes, and build a single service network, Internet-scaled to protect... allow people to protect their networks in this new world where businesses don't, like all of the data and the networking within the business doesn't live within the walls of the perimeter or the castle-and-moat style architecture. We have users connecting to services in SAS applications, and all of the sensitive corporate data is going out there. Businesses are always communicating with each other over cloud networks or local networks or roaming devices these days. So this old model of having this wall around your network doesn't make sense in this modern era of users working everywhere, data being everywhere, applications being everywhere. Yeah, and Ankur, do you want to jump in there? So like with that kind of transformation that a lot of corporate networks are going through, what we start to see is you really need to build security into kind of an Internet-scale platform, which Cloudflare has and has built up over time. We originally started building our network to support our reverse proxy services and our CDN business, and it turns out that when you start putting a bunch of servers and data centers that are close to users to serve content quickly, what you can also do with that is, or what you ended up actually doing is you ended up putting servers just close to users, and with that you can start applying the security policies and routing your users' traffic more quickly because essentially you're connecting to the user much sooner, you're able to make that routing decision much quicker, and then you're able to ride that Cloudflare Backbone that we've built up over time. Now that's kind of just the underpinnings of what Cloudflare is built on. And with Cloudflare One, it's really about replacing those legacy devices and boxes and then with that pairing, the Zero Trust and identity security policies that you're able to apply to all of your users and your network access. So Cloudflare Gateway essentially fits within the Zero Trust Suite by acting as that kind of robust policy engine for your Zero Trust kind of network. So you essentially have three major components of Cloudflare Gateway. You have DNS and then you have Secure Web Gateway, which within it has network policies and then HTTP policies. Now each one of those allow administrators to apply very strong kind of controls or loose or really granular controls, however they kind of want to control it, of how they want to treat their users and their users' traffic. So if you start just with DNS, you can filter by content categories, domains, security categories, all these sorts of things. And those categories are within our network and HTTP policy builders as well. And what's nice about that is it's consistent across the board, so you can easily pick and choose and apply policies and everything kind of just looks the same. Now when it comes to onramps, you can send us traffic via either that WARP client that we have that you can install in your user's machine that supports all the major OSs that are available today. You can send us traffic via say a proxy endpoint. This is something that you would typically deploy in, say, a pack file down to the end user machine and then we can apply those strong kind of inspection policies within HTTP. And then the other options are GRE and IPsec, that's essentially sending us your network traffic. And then we can apply things like our network policies to that as well as that HTTP inspection. And what's kind of really neat about that HTTP inspection point is that we actually decrypt the traffic, we inspect kind of the payloads and then we re encrypt it and send it on. So typically what we're looking for there is you can turn on things like AV scanning, up and coming DLP and a few other kind of URL and MIME-type controls. In the future, we really want to lean forward towards more inline CASB use cases. And today you can do kind of the identification of them and we'll surface them within our analytics so you can create access rules around them. But we want to expand that capability even further with our Vectrix integration of just CASB alone. So kind of more on that soon. Actually, tomorrow. Yeah. And it's interesting like from a conceptual perspective where users used to have a VPN serving as a roaming client connecting back to an on-premise VPN server, then daisy chaining, or another patch cable to a secure web gateway, another cable to a DLP platform and then out to the Internet gateway and out to the Internet. That model was just disrupted with just having Cloudflare's network providing all of those functions at the closest edge location in a single metal before it goes out to the Internet, which this, this paradigm is sort of a good place to jump into how routing works and why we're talking about dedicated IPs, dedicated egress IPs today, because if I have my data center and I have the Internet gateway, that's something I would get out of the box with the on-premise service, generally, since I only have one IP address for my network or something like that. So let's jump into how routing works with Cloudflare Gateway today and why we're talking about dedicated egress IPs today. Sure, yeah. So today when you send us your traffic, one, you can resolve DNS queries – it's a whole another component – and then within the secure web gateway function, you essentially proxy traffic to us. And because the traffic comes to us, we essentially re-IP it and send it on to its source if it's allowed by your policies, if you have some policies that are, of course, either say, a deny, or send to an isolated browser, or any number one of kind of your action options. I guess the other one to call out here is an SSH inspection. So we're able to actually inspect and log your SSH commands and give you that in robust kind of logging that you can verify. But the gist of it is basically, you send us traffic, we re-IP it, we send it on. And today we lean heavy towards preserving your privacy. So all of the IPs that we use and egress from are a kind of a generalized pool of IPs that are at each one of our data centers and shared across all of our Zero Trust customers. What's nice about this is you can't be fingerprinted by your IP anywhere out on the Internet. You're just given an IP that's shared across the board there. - Now... - Critical for sale as well. So we don't need to worry about how many megabits each tenant or use gets, it's just leveraging our full network. Exactly. And they're able to just get an IP at the colo they connect in every time. Never have to worry about where they're connecting in or whether there's capacity or not. It's just, you connect in and it just works every time. Now that's great on the privacy end of things, but we have a large subset of customers that also want to be able to egress via a known, dedicated IP address. This known dedicated IP address allows them to kind of allow-list that IP in any sort of, say, third-party services or on their internal networks. And the reason why this is important is there are certain third-party providers which use this IP authentication as truly the only method to verify or really apply kind of a defense in depth of whenever they have one of their customers accessing their systems. So a lot of security teams really still hold on to this concept and really kind of cherish having that IP allow list in there and that ACL control. And honestly, like it is just yet another kind of thing that you can configure to apply that defense, which I totally understand and I think it's critically important, especially for certain network types. Now, the... Ankur, I was just going to say that it's interesting because a lot of our customers who come into Cloudflare One with the Secure Web Gateway are also embarking on their Zero Trust journey and using Cloudflare Access to authenticate every single request through their identity provider and tokens. And this is a great way for those customers who are on their own Zero Trust journey, but still need to work with third parties who aren't yet all the way down that path to be able to go on that path themselves while still supporting their work, working with their vendors while they're while they're catching up. Exactly. And we understand that everyone's at their own kind of step in this journey. No one can kind of go out the gate and say, hey, we want to do all the fanciest things from day one. Like that's just not feasible. And typically, you know, a business unit, one business unit might get there, but then others might still have their own timeline. So it's great to kind of offer that flexibility. So then customers are able to kind of pick and choose what best meets their kind of architecture and their needs. So these dedicated egress IPs are... just want to dive a little into what they really are. So they are dedicated IPs that are dedicated directly and strictly to that single customer account, and they're available for any one of our enterprise customers today. And what's neat about these is you will always get assigned at least a pair. So we'll set one up in any city of your choosing that Cloudflare has a data center and then we'll set up a second one just so you always have kind of that resiliency and reliability to guarantee that you're always routing through one of those IPs. And so if I if I have users in the United States, but we need to make sure they egress through a European data center, for example, we would internally hop them through that without them needing to configure anything. Correct. Yeah, so we would essentially route the users to the closest dedicated egress IP without any configuration. So if, say, a customer was to onboard and they say they had a center of gravity in, say, L.A., one in New York and one in Munich, we could put an IP in each three of those cities, so then each of those users would be able to get the most performant kind of experience while they're browsing the Internet. Now, say you had a user that was maybe in Dallas, they would get routed to one of L.A. or New York, depending on which one was closest. So your roaming users would still be covered and still be able to egress using that dedicated egress IP. But of course, like if you needed to add more, you could add more. You could scale this up or down, however you'd like it. Right. And if, let's say, I'm eggressing or trafficking toward the same IP, would I need to worry about DDoS hitting any one of these? No, that's actually, that's the nice thing about this is typically we see customers moving from say on-prem VPN appliances over to Cloudflare and during that kind of transition, we know it's really important to have that DDoS protection when you are hosting your VPN appliance, because it's often you will host it on a few IPs from your say slash 24, slash 22 that you're announcing and say, you'll put your VPN lines between, behind those like two or four IPs, whatever those are. And because those IPs are now publicly available on the Internet to reach your VPN gateway, you still have to protect them from DDoS attacks or any number of anything that can really come over the Internet there. Because these IPs are now provisioned by Cloudflare for the dedicated egress IPs, these don't need any sort of DDoS protection to be purchased by the customer because these are IPS that are owned by Cloudflare, leased to the customers. We inherently protect them full stop. So, we're not passing along any costs there at all. Like we're, you know, this is something our company has done since day one really, as we try to essentially not charge customers for any sort of DDoS. That's not how we're built. Yeah. And I'm especially excited about dedicated egress IPs with Gateway. And this comes back to Cloudflare One in general and how having an integrated solution delivers more value and ease of use for customers. Because a request I regularly heard, as I am the product manager for our Browser Isolation product, is how can I get all of our remote browsers, all of our traffic from remote browsers to come from a single egress IP so we know it's from our browser traffic since you can't tell it's a remote browser connecting from the server side? And... in any other company, we'd have to build something bespoke, but because of the deep and native integration between Gateway and Browser Isolation, one, all the remote browsers benefit from the visibility and logging of traffic egressing through Gateway. But now we also got static and dedicated egress IPs, so the remote browser's for free, which I very much appreciate. So thank you and your team for working on that Ankur. Yeah, that's definitely the neat thing about working Cloudflare is we aim to essentially integrate everything on that same server, on the edge. The only time we're ever routing off that server is if we're ever say eggressing from a different point than we've ingressed. It's not because we're routing to, say, execute some other logic or some other service. We truly aim to do everything on that first server it came in on. Great. So Ankur, do you want to let us know what's next for the world of eggressing from Gateway? Yeah. So with dedicated egress IPs, they're wonderful, you get that consistent IP. And as customers started to pick these up and use them, one, they started to realize that one, these IPs apply to all traffic that's proxying through your account. So what we wanted to do is we wanted to lean forward and give customers a way to specify when these IPs are used. So not that they just apply to all of the traffic proxying through your account, but that they can apply to, say, granular, say subsets of them. So, for instance, I want to use my dedicated egress IP when I'm routing to my internal wiki, but I don't want to use the dedicated egress IP when I'm going to Facebook.com because I don't really care if my users are going to social media sites or Facebook or whomever, ESPN. I just want them to be able to access those web pages, get there using our standard privacy-preserving egress IPs, but still get that dedicated egress IP when I'm accessing those internal resources. So yeah, that's great from an operational security perspective because you can rely on this just for the sensitive service that still requires IP ACLs but not provide visibility to whatever else you're looking at on the Internet. Exactly. And we want to also provide a lot of flexibility here. So we want you to be able to say, I want to hit certain destination hosts, IPs, you can do it by user. So we want to make sure our customers have the total flexibility of when and where to deploy these IPs. One of the kind of interesting use cases that kind of came up as we were talking to customers about this was we had a large kind of media conglomerate bring up this use case of verifying their layouts for their advertisements. And essentially they, their specific use case was they had a... they wanted a way to verify the layouts of their advertisements in Mexico. And typically the way they would solve this is they'd either have people from their office in Mexico, in Mexico City, either pull up the page, verify it, or they would utilize this VPN that they had specifically for this purpose to log in and go egress in Mexico City and check if the type, the layouts are as intended. And with egress policies, you can simply just put that domain behind a kind of a test domain or a custom domain like, say, mexico.advertisementlayout, you know, whatever the rest of the domain is. And then it will route out Mexico City if you added a dedicated egress IP there. So that gives you the advantage of just having your team being able to just hit it based on a domain, as they do with their regular kind of security policies applied without ever having to worry about managing another service. And then also, I guarantee you, your security team will not be happy about having to manage multiple VPN products. Yes. Yeah. The VPN products and having them, that is a very large market with a lot of different players in that space. Yeah. Cool. Is there anything else we should talk about today, Anker? I think that's all I wanted to share with dedicated egress and dedicated egress policies. Something to note is if you're an enterprise customer today or would like to become an enterprise customer, please reach out to our sales team or your account team and then we can go ahead and also enable this dedicated egress feature for you. All right. Awesome. Well, thank you for sharing that insight, Ankur. I'm very excited to test out dedicated egress IPs myself. Audience I really appreciate your time watching us talk about dedicated IPs today. We're going to return back to our regularly scheduled programing now. But do keep an eye on the schedule for Cloudflare TV. In about an hour and a half, we'll have Abby, Noelle and Dave diving into updates relating to our Microsoft Intune integration. So they'll be live in about an hour and a half if you'd like to tune in for that. Thank you, everyone. As I mentioned to be my name's Tim Obezuk and I'm a product manager for Browser Isolation, joined by Ankur Aggarwal, a PM for Cloudflare Gateway. It's been a pleasure talking to you about dedicated IPs today. Bye everyone. The real privilege of working at Mozilla is that we're a mission-driven organization. And what that means is that before we do things, we ask what's good for the users as opposed to what's going to make the most money. Mozilla's values are similar to Cloudflare's. They care about enabling the web for everybody in a way that is secure, in a way that is private, and in a way that is trustworthy. We've been collaborating on improving the protocols that help secure connections between browsers and websites. Mozilla and Cloudflare have collaborated on a wide range of technologies. The first place we really collaborated with the new TLS 1.3 protocol, and then we followed it up with QUIC and DNS over HTTPS, and most recently the new Firefox Private Network. DNS is core to the way that everything on the internet works. It's a very old protocol and it's also in plain text, meaning that it's not encrypted. And this is something that a lot of people don't realize. You can be using SSL and connecting securely to websites, but your DNS traffic may still be unencrypted. When Mozilla was looking for a partner for providing encrypted DNS, Cloudflare was a natural fit. The idea was that Cloudflare would run the server piece of it and Mozilla would run the client piece of it, and the consequence would be that we'd protect DNS traffic for anybody who used Firefox. Cloudflare was a great partner with this because they were really willing early on to implement the protocol, stand up a trusted recursive resolver and create this experience for users. They were strong supporters of it. One of the great things about working with Cloudflare is their engineers are crazy fast. So the time between we decide to do something and we write down the barest protocol sketch and they have it running in their infrastructure is a matter of days to weeks, not a matter of months to years. There's a difference between standing up a service that one person can use or ten people can use, and a service that everybody on the Internet can use. When we talk about bringing new protocols to the Web, we're talking about bringing it not to millions, not to tens of millions. We're talking about hundreds of millions to billions of people. Cloudflare has been an amazing partner in the privacy front. They've been willing to be extremely transparent about the data that they are collecting and why they're using it. and they've also been willing to throw those logs away. Really, users are getting two classes of benefits out of our partnership with Cloudflare. The first is direct benefits. That is, we're offering services to the user that make them more secure and we're offering them via Cloudflare. So that's like an immediate benefit the users are getting. The indirect benefit the users are getting is that we're developing the next generation of security and privacy technology, and Cloudflare is helping us do it, and that will ultimately benefit every user, both Firefox users and every user of the Internet. We're really excited to work with an organization like Mozilla that is aligned with the user's interests and in taking the Internet and moving it in a direction that is more private, more secure, and is aligned with what we think the Internet should be. We have seen malicious foreign actors attempt to subvert democracy. What we saw was a sophisticated attack on our electoral system. The Athenian project is our little contribution as a company to say, How can we help ensure that the political process has integrity, that people can trust it, and that people can rely on it? It's like a small family or community here, and I think elections around the nation is the same way. We're not a big agency. We don't have thousands of employees. We have tens of employees. We have less than 100 here in North Carolina. So what's on my mind when I get up and go to work every morning is, What's next? What did we not think of and what are the bad actors thinking of? The Athenian Project, we use that to protect our voter information center site and allow it to be securely accessed by the citizens of Rhode Island. It's extremely important to protect that and to be able to keep it available. There are many bad actors out there that are trying to bring that down and others trying to penetrate our perimeter defenses from the Internet to access our voter registration and/or tabulation data. So it's very important to have a elections website that is safe, secure and foremost accurate. The Athenian project for anyone who is trying to run an election, anywhere in the United States, is provided by us for free. We think of it as a community service. I stay optimistic by reminding myself there's a light at the end of the tunnel. It's not a train. Having this protection gives us some peace of mind that we know if for some reason we were to come under attack, we wouldn't have to scramble or worry about trying to keep our site up, that Cloudflare has our back.