Cisco Customer Success - Video

Multicloud Defense - AWS Ingress Reverse Proxy

Playback confirmation!

Do you want to resume playing from last left location?

Chapter 1 Thumbnail
00:06
Welcome and objectives
Chapter 2 Thumbnail
01:16
Deploy AWS ingress gateway
Chapter 3 Thumbnail
04:05
Validate gateways and load balancers
Chapter 4 Thumbnail
06:20
Configure web servers and reverse proxy services
Chapter 5 Thumbnail
11:10
Create ingress policies and listeners
Chapter 6 Thumbnail
14:27
Test HTTPS and TCP proxies; analyze logs
Chapter 7 Thumbnail
17:20
Wrap-up and next steps

Transcript

And welcome back. In today's video, I hope you've I I actually hope you've been watching some of the previous videos because everything kind of builds up, right? And we're gonna.00:06Put together a lot of the stuff that we've learned up to this point to create a bigger video that shows a more kind of realistic process. So what we're gonna do today is we're going to on our if you look at our diagram, we have an example.00:15Yeah, spoke VPC in this case cause we are in AWS and we have a Linux VM out there. What I want to do is kick up a simple web server on this box, and I want to deploy a fleet of ingress gateways that kind of sit in the same VPC services VPC as our egress gateways.00:31That will provide a reverse proxy type functionality for us.00:52We will make sure from the internet that we can actually access that new web server through that reverse proxy, and this will include all the rules and policies to kind of supplement and support this. So the 1st thing I want to do is go into AWS and we'll deploy our ingress gateway. So I'll go to infrastructure.00:56And gateways, and we'll add a gateway here. We're going to go through the same process. I will call this AWS ingress East two, just to kind of match our naming for the egress gateway.01:16I'll keep it just eight virtual CPU for now. We'll scaling wise, we'll do a minimum instance of one and we'll say, well, we're willing to scale out to three gateways or let the SAS controller scale this out to three gateways per availability zone. The load balancer health check port will leave as the default, which is 65534.01:33And then all of these additional profiles for now, I'm just gonna leave blank. We'll click next. So ingress gateway, we'll leave that. Gateway image group is gonna be recommended and we'll just go with 2406 ten, which is the current recommended version.01:53The policy rule set, I'm just gonna say create a new one. This will create a new standalone policy. If I really wanted to, I could go in and actually create a grouped policy that will apply, but I'm just gonna leave it as this for now. We will say.02:11East two is our region. It should pick up our services VPC. So this SE demo AWS East two. So we'll go ahead and say we'll deploy within there the key pair, we're gonna leave the same.02:28Gateway I M role is gonna be my YouTube. Actually, was it something different in here?02:45Let me.03:09Really quickly, actually go into here. Let's look at our one of our egress gateways, and we'll look at.03:12I think it's under Json MCD gateway role, so we'll select that gateway role that just assigns the appropriate permissions to the gateway itself. We have our security groups already defined because we orchestrated this, so we'll click next.03:28We're going to, keep our public IPs. We're not using global accelerator or ILB right now. We'll let it validate the ask here and we should be good.03:48So we'll click finish Yeah I don't know why this has happened before. We'll just kind of monitor and make sure that that gateway deploy is ok. So we do see AWS ingress East two.04:05Everything's here, so we should start to see this enabled. So now what we want to do is validate it looks like our gateway built out, so let's take a look at the gateways, and we do see the ingress gateway.04:23We have three running. If we start from here, this is what's kind of interesting, right? Is it deploys a public facing NLB, which gives us a persistent FQDN that we can point like our C name records to. So if we're hosting like websites, I could have like, you know, web server one.cisco.com.04:40It has a cname record pointed to this gateway endpoint, which again is associated with the public facing NLP. And again, if we look through the details here, very similar to what we saw with the egress gateway, we have three instances running active. Again, the load balancer's gonna be spring traffic.04:59Checked across all of those. And if we take a look within AWS.05:19We should see the ingress gateways, which we do. And if I scroll down to load balancers, we now see two load balancers. We see the ingress load balancer, which is a public facing NLB, and then the egress load balancer, which was a GWLB a gateway load balancer. So if we look at.05:26This.05:46Network load balancer. We can see there's NO listeners yet. We'll come back to this. When I program a rule into the multi cloud defense policies, those will create listeners within this public facing NLB. We didn't necessarily have that with the GWLB because the gateway load balancers should.05:47It's gonna forward all ports and protocols, but with a public facing NLB, we are going to programmatically put in these listeners within this load balancer, which is one of the reasons we, we also deploy the load balancers part of the gateway deployment.06:07Network mapping, it's gonna be present on all the availability zones we have gateways in, resource map, this is or should show us. I think this is wrong. Let's oh because there's NO listeners, we don't have any targets yet. So once, let's actually go program some rules and then we'll come back here and validate this.06:20So, with regards to this web server, let me edit this. We'll get some squigglies going. So we do have the TGW, it is attached. These web servers, what's actually neat about it is I'm gonna create two. I've got an Apache server.06:40That is running on port 80, and then I'm gonna kick up a quick little it's a Python, having it right incursive so it doesn't stop me, and it's running on 8080. So what I wanna do is on these new, let's just pretend these are the ingress gateways now.07:02Is I want to come through and I want to create these listeners, and what I want specifically is I'm gonna create one listener over here that's gonna listen on 04:43. We'll actually terminate that it'll have a certificate, but I want to.07:22Create a proxy from 04:43 to 80, and this will just run plain old HTTP proxy. We'll create another listener that is an 8080 proxy that will forward to this Python web server on port 8080, and this will just.07:40Should be a plain old TCP proxy. And there are some benefits to, to proxying like TCP, HTTP, we're gonna automatically send keep alives on both sides of that connection. But I just want to kind of showcase what we can do with multi cloud defense, and its reverse proxy type functionality. So.08:00That said, let's pivot out of the diagram. I'm going to head over to multi cloud defense. We're gonna go under policies, and the 1st thing I want to do is create an address. So we have an address that the server's already a member of, but that's for the egress traffic. That's why it's a type of source test. There.08:18This is another address type which is a reverse proxy target, and this is important.08:38So this reverse proxy target's gonna give us the ability to use this node or this workload as a back end target for this proxy. So we'll call this Linux web server. For type, I can do IP FQDN or it could be an application. So if we had like multiple web servers all serving the same website.08:43And we had a like AWS.09:04ALB, I could use that ALB as my target for those disparate web servers. I'm gonna use IP and FQDN, we'll say IP address here, and I'm just gonna paste in for now the IP of this.09:07So I'll say paste, save, addresses in there so we can see Linux web server, we have it as a target. So now I will go to services and we're gonna create two of these. So remember, we're gonna have one for 443 going to AD and another one for AD AD.09:24So this 1st one we'll call 443. You can see I've done this for other, other demos before. 04:43 to 80. Whoops. Try that again. 04:43.09:42To 80, Scroll slowly this time. So the listener decryption profile, this is like if we, if we want to do decryption for encrypted flows, we could do that. I'm gonna use it just because we're gonna terminate SSL on the gateway and then the back end connection will be on 80. So I'm gonna say, hey, I'm gonna go ahead.09:58Use the sample certificate for ingress that we have. We will go through certificates in another video. Client CA decryption, if we wanted to kind of do TLS mutual off, I could also authenticate the clients that are trying to access this. I'm not gonna worry about that right now.10:18I am gonna use 04:43 as the destination port, so this is what I'm gonna open the proxy on, on the gateway public side. It's gonna be TCP based. Sni's kind of cool. We're not gonna use it right now, but I could use it if I had like multiple websites coming in on 443I could use the different snis to go to different backend target.10:35So like this one could be web server one.cisco.com and then another one could be web server two.cisco.com, but they were going to two entirely different backends. That's where the SMI routing would come into play, and I just entered those here.10:55Ignoring L seven DOS for now, I'm gonna target the backend port of 80. The protocol I'm gonna use to proxy through is HTTP. HTTPS wouldn't work because we, you know, the backend's not actually receiving at that secure sockets layer.11:10So just native HTTP application layer, and then Linux web server is gonna be our target. I'm gonna create another one and it's going to be 8080 to 8080.11:25We will come over here. I'm not gonna do any decryption here, but I'm gonna do 8080 TCP, going to 8080. This is just gonna be a TCP standard TCP proxy.11:42And we're gonna go to the Linux web server and we'll click save. So now I have two different reverse proxy services that are available to use within policies. So let's go to policies, rule sets. We'll go to the ingress policy, and we'll create two rules. So the 1st one's gonna be.12:0004:43 to 80.12:20We'll say reverse proxy. Reverse proxy is the service, so we should see 04:43 to 80. The source, I'm just gonna I could I could really limit who could access this but I'm gonna say anybody on the internet can get to, it's gonna terminate at the gateway because remember the, you know, the.12:24People on the internet don't know to go to 10182205. They're actually gonna be going to a public facing either IP address or FQDN, so that's gonna terminate at the gateway, at the individual gateway. But the the ultimate target is going to be that backend Linux web server.12:44And I'm gonna go ahead and allow log. I'm not gonna do any advanced services yet. We'll click save. We'll create one more here. This is gonna be 8080 to 8080, the Linux server, reverse proxy.13:00We'll do the same thing, Select our service, source is gonna be internet. We're going to allow log, and we will save. Shows us our deltas here.13:16We'll click save, and what should happen, this might actually take a minute because it is building out the proxy side, so I will wait for, I don't know, two or 3 min here, hopefully speed up the video through the power of editing and then we will rejoin once this is.13:31Is active. And we're back. So we can see that the policy's now updated, so let's take a quick look back at our load balancer here. We'll go back to listeners, refresh, and we see the SAS controller for multi cloud defense.13:51Programmatically added TCP UDP forwarders for 80 84 43. So they are forwarding to the back end target group, which is gonna be the three of those ingress gateways. So again, they're terminating on port 8080 04:43. So that all looks good. Our resource map should.14:08Now be complete, everything looks movie point out. So now we will go back to multi cloud defense. Let's go to investigates. We'll set at all events here. I'm going to limit this to our ingress gateway and then we are gonna do some testing.14:27Actually let me open up infrastructure, open a new tab. We will grab this gateway endpoint. So the 1st one we'll test is our Apache server, so we'll say HTTPS.14:47Plug that in, and we can see it works. So the HTTP, S two port 80 forwarding seems to be working. Let's go back to our logs here. We can see we do have some logs.15:09Load the latest events. We can see, and this isn't the best view, let me go to, I like to see the front end backend connections which shows under traffic summary. So I'll click on logs here, and this is what I wanted to see. So we we now have the ability to see.15:27You know, my IP from where I'm logging in from, it going to 101-84-0809, which is this is gonna be one of the three gateways that we've deployed, and then we're terminating port 04:43. We can see it's going to ten 18205, which is our Linux server on port 80.15:45So if I clicked on this.16:05We could see everything associated with that. We could see the instance details, we could see all the TCP flags that were associated with this. So everything looks good on the HTTP proxy. Let's kick up our web server on the Python side to do some testing.16:06So I started a, a simple web server on port 80. What I'll do now is I'll take the same URL. I will take out the S and we will add 8080 in here and we can see that we get that, I should be able to see yep.16:26That we we've connected, so I should, yeah, I should be able to go to SSH, authorized keys, download everything. So again, just simple web server using Python, but we can see that it's working as intended. Let's validate that it went through the proxy. So I will go back here.16:45Click the X, come back up. We can see we have some more events, so we'll click on that. And again, I can see that we have some 8080, again, my IP to one of the gateways cause it was proxy or load balanced.17:01From the public facing NLP to those gateways terminating on port 80, and then the gateway to server connection is going from the gateway IP, which these match to ten 18205 on port 8080, and again we could look at all the details, which rules we actually hit.17:20But this is a very basic use case for a lot of customers who want to use our ingress gateway. They want that reverse proxy type functionality that they can leverage in order to, you know, host these publicly available services from.17:37Behind multi cloud defense. The benefit being that I'm just doing basic L3L4 firewalling right now, but in a later video, what we're gonna do is we're gonna fold on some additional security features like we did for the egress policies. So we'll look at things like web application firewall. We have the.17:52Ability to fold those extra protections in on a rule by rule basis much like we did with the egress functionality. So stay tuned in a future video where we'll go through that.18:12As always, if you found this video useful, keep a key eye on this channel as we will be releasing more and more content around the deployment and uses of multi cloud defense and how you can use it to protect your cloud infrastructure. Thank you for watching.18:22We look forward to seeing you in the next video.18:33

About this Video

Author : Cisco Customer Success

Uploaded : July 13, 2026

SecurityMulticloud Defense
AI summary icon

AI summary

Discover how Cisco Multicloud Defense deploys an AWS Ingress Gateway to publish a Linux web server through reverse proxy. Configure TLS termination and TCP proxying, define Addresses, Services, and Policies, and build 443-to-80 and 8080-to-8080 listeners. See automatic Network Load Balancer programming, scalable gateways, and end-to-end validation in Traffic Summary logs, events, and AWS.

  • Learn to deploy an Ingress Gateway and scale across availability zones with a public FQDN.
  • Learn to create Reverse Proxy Services with certificates, TLS termination, and optional SNI routing.
  • Learn to verify front-end and back-end flows using logs and programmatic NLB listeners.