Data tunnel connectivity - Cisco Tutorial

- [Instructor] In this lesson we're going to talk about the data tunnel connectivity. So this may be very fundamental for some people, but I want to make sure that we provide a ground-up understanding of what's happening on. So when we think about it, when connectivity between a PC and a server, it's going to travel across the traditional LAN over here on the right and the LAN on the left. But then we're going to travel across the... From the PC and it's going to reach the edge of R2. Now, R2 is then going to look into its OMP database, and it's going to know that it needs to forward it off to R1. Now it will look for R1's appropriate T lock entries. And then based off of that it will add onto the tunnel header and for that packet. Now the great thing about what's happening right now is all the forwarding decisions is based off the tunnel header. So that is only the information that is exposed in the underlay. So when we think about that transport, the transport does not have any knowledge about what is the original packet header as far as the source and destination IP addresses or the QOS settings or even what is in the payload because that is all encrypted. Now, once it gets to the edge of R1, R1 is going to remove that tunnel header, and it's going to forward it out to the service side VPN interfaces, in which point is going to move on to the server. So one of the other things we want to talk about is what are acceptable tunnel layouts? This is a common question I get. And so when we think about it, it doesn't really matter how we provide the connectivity between our edge devices as long as we can get that tunnel established. So at the very top we've shown, you know, a basic scenario where you'll take that preliminary layer two connection that the service provider might hand off to you and just plug that straight into the edge router, and that would be our way of providing the connection. And as long as they're providing the appropriate routing in their network to get from the left side to the right side and the right side to the left side in that underlay network, we will be in good shape. Now if you have some sites that are behind a customer premise equipment device, right, where you're getting that connection handoff from a managed service provider circuit, that's fine too. Again, we only really care about getting that SD-WAN tunnel from edge to edge. And if they want to put a firewall in place, that's fine because we can do things like network address translation as well as just as long as we get the necessary ports across for establishing that SD-WAN tunnel, we're in good shape. We can allow that to happen. And the last scenario I just shown just basically has a large number of things in there. So we've got some layer three switching in the edge device. It could be layer two switching. It doesn't really matter, again, as long as we can get connectivity across those data connection ports down at the bottom from edge to edge, we'll be in good shape. And I just got done talking about NAT. So let's talk about network address translations because this is another kind of touchy situation. So there's a couple different ways or classifications we'll give to an edge device, but let's go through what they are. So the first one is known as static NAT, also full cone. And basically this is going to be a one-to-one mapping of the public IP addresses towards the private IP addresses. And so when we're talking about static NAT, it doesn't really matter who initiates the connection, it can come from outside a device or come with inside of the private network. We can establish that connectivity because we're doing a static one-to-one NAT. And just to demonstrate we'll initiate communication from our host, and we'll notice that the source port on the public and the private side are exactly the same, just as the destination port is exactly the same. And this is one of the beauties about doing static NAT is life is very simple with that. You just have to make sure you have enough IP addresses for your public space to kind of maintain that. There is also a little bit more manual configuration with this scenario. Now the next common type is dynamic port address translation, also known as PAT, port address translation, or overload. We also could refer to this as symmetric NAT. So in this case, what will happen is no external host will be able to establish a connection. That just is not going to be allowed to start off with. But once we actually have initiated a connection from the inside, or private side to the public, we'll build up a dynamic translation table. Now the key thing to point out here is that the source port will change when it gets translated. And that's how the actual network address translation device is able to maintain who actually from the inside is able to do this. Now what this benefit of the solution is is allows you to have multiple hosts on the inside of your network while you basically are only maintaining one IP address for that communication with multiple devices. But this is called symmetric NAT or dynamic port address translation. All right, so the next type we're going to talk about is address restricted cone. And this is basically going to be based on static NAT, but we're adding some additional filtering. So to kind of put this in context, the external host, by default, they will not be able to establish any form of communication with the inside host. It's just not going to be allowed. Now I want to realize that now the devices in the public space will not be able to initiate and establish a connection to in the private space because the mapping of the insight port to the unique outside ports does not exist. Only connections that have initiated from the inside will be able to have connectivity from the outside with this type of NAT. But once we have actually sourced a initial form of communication from the host, what we will allow that to happen is we will allow return traffic from the actual public side host across any port, so any port. So in this case we initiated traffic from port 80, but the web server is able to respond and provide the traffic in 443 without the actual host PC requesting that. And this is one of the benefits towards having the address restricted cone. It's the same thing as NAT, but we require the communication to be initiated from the inside the private space before allowing outside connectivity from the public. And it's only going to be to the host he has communicated with. And the last type we're going to talk about is port-restricted cone NAT. And so this is going to be basically taking the same constructs of address restricted cone and adding another level. So you could say it's based on static NAT with really additional filtering. So the same construct that's going to work here where, to start with, we will not allow any communication from any outside host, okay? Now, once we have actually sourced some traffic from the inside or the private IP space, then we will allow return traffic only on that port. So all the other ports will not be allowed. So in the example that I gave just just a couple minutes ago where we set the traffic out through port 80, the web server said we're going to respond in 443 to start with, that will not be allowed. So in order for 443 to be responded with, he will have to reply through his traditional HTTP that you need to do a redirect. And then he will need to do a second path across 443 in order for the web server to respond back. And so this again is, again, a second way of providing a little bit more restrictive filtering on the address restricted cone. All right, so let's talk about where those types could actually are compatible and not compatible. So to start with, at the very top where we have no NAT, and no NAT is going to allow you to bring up a successful tunnel. If you have no NAT and any of those four types, you will be able to bring up a successful tunnel. If you have full cone to full cone, successful tunnel. If you have a full cone with either port-restricted or address-restricted, you'll be able to bring up a tunnel. And if you have full cone with symmetric, and that's the port address translation, that's the many to one where we dynamically change the ports as traffic goes outbound through the firewall, we'll still allow that connection. Now you could go through the process of having port-address restricted to port-address restricted and that will be successful. But basically if you have symmetric, you have to be careful because symmetric will not be able to form with port-address restricted or another symmetric, and that deals with who is able to initiate the communication. Now one thing I kind of want to point out is, even if you have those two sites, you could still deploy 'em in your topology. And so basically you can maintain that through the hub site. And let me kind of elaborate or draw that out for what that means. So we could have like R1, which will act as our hub, for better purposes. We could have R2 and R3. And so we'll say R1 is full cone, and we'll say R3 is symmetric. And let's go ahead and say that R2 is going to be port restricted, okay? So to start with, as I said earlier, what will happen is R2 will be able to establish a tunnel with R1, and R3 will be able to establish a tunnel with R1. But on that chart, R2 and R3 will not be successful because they will not be able to make it past that type of NAT address translation to get the tunnel mappings brought online. It's just a nature of the beast of what the firewall's going to do or the the network address translation function is going to do. It won't allow the communication to happen. So that tunnel will never be able to establish. However, if you are advertising a default route or something more like the enterprise-free fixes of whatever's behind R3 and R2, so maybe it's a 10.0.0.0/8 if all your corporate addresses are in that, this will provide enough connectivity for R3 to forward the pack to R1, R1 can look at its routing table. It'll have the more explicit route to R2 and forward the path to that. And that's a way that you can still maintain connectivity between these sites where they have that type of connection model. So hopefully that makes sense of what I'm talking about, where you can maintain that connectivity between those two devices. So what I just drew out is handled right here where we can maintain that connectivity through other sites where you're advertising the route prefixes through them, right? And that could be directly through summarization or you could do manipulation in a route policy. And this concludes this lesson. Thank you.