WEBVTT 00:00:01.000 --> 00:00:07.000 Alright, and to wrap up this discussion on GRE and IPsec, we need to talk about GRE over IPsec. 00:00:07.000 --> 00:00:10.000 So this is about combining the two of them together. 00:00:10.000 --> 00:00:12.000 Why do we want to combine the two together? 00:00:12.000 --> 00:00:14.000 Well, let's think about this for a second. 00:00:14.000 --> 00:00:22.000 We know that IPsec is really, really, really, really, really, really, really, really great at protecting our traffic. 00:00:22.000 --> 00:00:23.000 We know that. 00:00:23.000 --> 00:00:29.000 But we know that it doesn't support anything other than IPv4 and IPv6 unicast traffic. 00:00:29.000 --> 00:00:35.000 So I can't run something like OSPF or any type of dynamic routing protocol 00:00:35.000 --> 00:00:42.000 or any other type of service or feature that relies on things like multicast or broadcast or anything like that. 00:00:42.000 --> 00:00:48.000 It has to be IPv4 or IPv6 unicast traffic. 00:00:48.000 --> 00:00:55.000 But what we can do, but GRE, on the other hand, supports a whole bunch of different types of protocols. 00:00:55.000 --> 00:01:01.000 But it's really, really, really horrible at protecting traffic. 00:01:01.000 --> 00:01:05.000 So what if we combine the two together, get the best of both? 00:01:05.000 --> 00:01:09.000 What if we take a GRE tunnel and create it? 00:01:09.000 --> 00:01:12.000 So that way there we have that for multi-protocol support. 00:01:12.000 --> 00:01:18.000 And then what if we wrap that whole GRE tunnel in IPsec? 00:01:18.000 --> 00:01:20.000 What if we did that? 00:01:20.000 --> 00:01:24.000 Then we get GRE over IPsec. That's what we get. 00:01:24.000 --> 00:01:29.000 So GRE tunnel is used for the routing and the transporting of all different types of protocols and traffic. 00:01:29.000 --> 00:01:33.000 And we just wrap all of that up in IPsec. 00:01:41.000 --> 00:01:44.000 Oh, here's our configuration. 00:01:44.000 --> 00:01:46.000 GRE configuration. 00:01:46.000 --> 00:01:48.000 Look at that GRE config. 00:01:48.000 --> 00:01:55.000 It is the exact same config we had before, except for the IP address is different. 00:01:55.000 --> 00:02:00.000 172.16.1.2 and 172.16.1.1. 00:02:00.000 --> 00:02:04.000 We had like 20, I think, 20.1 and 20.1.2. 00:02:04.000 --> 00:02:08.000 So other than that, it's all the same. 00:02:08.000 --> 00:02:11.000 So GRE is configured exactly like we talked about it before. 00:02:11.000 --> 00:02:13.000 Okay, what about IPsec? 00:02:13.000 --> 00:02:16.000 So phase one IPsec, no difference. 00:02:16.000 --> 00:02:19.000 So R1 phase one looks like this. 00:02:19.000 --> 00:02:24.000 It's going to have to match on the other side, modify the password IP address, right? 00:02:24.000 --> 00:02:25.000 There's branch. 00:02:25.000 --> 00:02:27.000 It's phase one configuration. 00:02:27.000 --> 00:02:28.000 So no difference there. 00:02:28.000 --> 00:02:29.000 You already know how to do GRE. 00:02:29.000 --> 00:02:32.000 You already know how to do phase one ISACAP. 00:02:32.000 --> 00:02:34.000 No difference here with GRE over IPsec. 00:02:34.000 --> 00:02:35.000 Thank goodness, right? 00:02:38.000 --> 00:02:41.000 Now let's talk about phase two IPsec. 00:02:41.000 --> 00:02:42.000 So what do we need to do here? 00:02:42.000 --> 00:02:44.000 Now we need to create our transform set. 00:02:44.000 --> 00:02:46.000 So we create our transform set. 00:02:46.000 --> 00:02:48.000 We create our access control list. 00:02:48.000 --> 00:02:50.000 Now here's something that's different. 00:02:50.000 --> 00:02:54.000 The access control list, look at this, permit GRE any, any. 00:02:57.000 --> 00:02:59.000 Permit GRE any, any. 00:03:00.000 --> 00:03:07.000 So I am no longer worried about the actual ACLs of the users. 00:03:07.000 --> 00:03:11.000 All I'm worried about here is all GRE traffic. 00:03:11.000 --> 00:03:19.000 So whatever is going to be GRE encapsulated is now allowed to go through my IPsec tunnel 00:03:19.000 --> 00:03:20.000 and be encrypted. 00:03:20.000 --> 00:03:25.000 So what I'm going to do now is I'm going to create a new transform set. 00:03:25.000 --> 00:03:29.000 And I'm going to go through my IPsec tunnel and be encrypted. 00:03:43.000 --> 00:03:51.000 I want to pause for a moment and let you know that you could actually use transport mode here. 00:03:51.000 --> 00:04:00.000 If you use transport mode, if and only if you change your access control list, 00:04:00.000 --> 00:04:06.000 what you would have to do in this case is instead of saying GRE any, any, 00:04:06.000 --> 00:04:12.000 you specify the IP addresses of the GRE tunnel. 00:04:12.000 --> 00:04:16.000 What is the source public IP address? 00:04:16.000 --> 00:04:20.000 And what is the destination public IP address? 00:04:20.000 --> 00:04:31.000 So in this case, I believe the source would be if you change this to 203.0.113.91, I believe. 00:04:31.000 --> 00:04:44.000 And then if you change this one here to 198.51, in our case, .100.46. 00:04:44.000 --> 00:04:48.000 Yep, so you could say host, and you could say host, or you could say that address plus 0000. 00:04:48.000 --> 00:04:49.000 It's up to you. 00:04:49.000 --> 00:04:54.000 But permit GRE traffic from this to this, then you can use transport mode. 00:04:54.000 --> 00:04:55.000 Why? 00:04:55.000 --> 00:04:58.000 Because this now allows you to reuse this header right here. 00:04:58.000 --> 00:05:10.000 Reuse this header for IPsec instead of having a GRE header and an IPsec header like you would have in tunnel mode. 00:05:10.000 --> 00:05:16.000 But if you use GRE any, any, it automatically uses tunnel mode for you. 00:05:16.000 --> 00:05:17.000 It will not let you use transport mode. 00:05:17.000 --> 00:05:23.000 So if you type in transport mode there, and then your ACL is any, any, it will go back to using tunnel mode automatically. 00:05:23.000 --> 00:05:25.000 It will just change it back for you. 00:05:25.000 --> 00:05:27.000 All right, so those are two different options you have. 00:05:27.000 --> 00:05:34.000 So if you don't want to have a GRE header and an IPsec header that are the exact same IP addresses, 00:05:34.000 --> 00:05:36.000 then you change that to transport mode. 00:05:36.000 --> 00:05:42.000 You set up the actual IP addresses of the interfaces on the public network as the source and destination, 00:05:42.000 --> 00:05:45.000 and then you get to reuse the GRE header for IPsec. 00:05:45.000 --> 00:05:47.000 And I'll show you a picture of that here momentarily. 00:05:47.000 --> 00:05:52.000 Actually, let's do it right now just so you can visually see that. 00:05:52.000 --> 00:05:53.000 It is right here. 00:05:53.000 --> 00:05:55.000 There you go. 00:05:55.000 --> 00:06:04.000 So you'll see in tunnel mode we have our original IP header and then our GRE header, 00:06:04.000 --> 00:06:06.000 and then you have a new IP header. 00:06:06.000 --> 00:06:11.000 But the thing is, is that the source and destination here are the exact same. 00:06:12.000 --> 00:06:16.000 And the destination, oh, yeah, the source and destination are the exact same, exact same. 00:06:18.000 --> 00:06:27.000 So if we use transport mode instead, then notice the GRE header is no longer here because it's reused here instead. 00:06:29.000 --> 00:06:32.000 So we basically save, what, 200 bytes. 00:06:32.000 --> 00:06:34.000 Sorry, 20 bytes, not 200. 00:06:34.000 --> 00:06:36.000 20 bytes in this case. 00:06:42.000 --> 00:07:00.000 And then we have our crypto map, IPsec VPN crypto map. 00:07:00.000 --> 00:07:03.000 There's our crypto map configuration. 00:07:04.000 --> 00:07:11.000 And then over here on branch, same thing, just as we talked about. 00:07:11.000 --> 00:07:14.000 So the PRI just would have to be changed, and if you wanted to do transport mode, 00:07:14.000 --> 00:07:17.000 then you have to change the ACL to support that. 00:07:17.000 --> 00:07:21.000 And then now we don't apply it to the tunnel interface. 00:07:21.000 --> 00:07:23.000 Okay, this is where people make mistakes. 00:07:23.000 --> 00:07:25.000 You don't apply it to the tunnel interface. 00:07:25.000 --> 00:07:27.000 You apply it to the physical interface. 00:07:27.000 --> 00:07:28.000 Why is that? 00:07:28.000 --> 00:07:32.000 Because your router needs to make sure it's doing things in the right order. 00:07:32.000 --> 00:07:40.000 So I have traffic that arrives at this router, and it's destined to branch. 00:07:40.000 --> 00:07:49.000 So the router does a routing table lookup, and it realizes that it has to send it out the GRE tunnel interface. 00:07:49.000 --> 00:07:51.000 So what does it do? 00:07:52.000 --> 00:07:54.000 It encapsulates it. 00:07:54.000 --> 00:07:55.000 How? 00:07:55.000 --> 00:07:58.000 It encapsulates it like this. 00:07:58.000 --> 00:08:03.000 So what is this GRE IP header that's going to be listed? 00:08:03.000 --> 00:08:10.000 It's going to be source, this interface, destination, this interface. 00:08:10.000 --> 00:08:16.000 Whereas the original IP header is destination, this interface. 00:08:16.000 --> 00:08:22.000 Whereas the original IP header is the private IP addresses from source to destination. 00:08:22.000 --> 00:08:24.000 Not private IPs of the tunnel, right? 00:08:24.000 --> 00:08:30.000 Private IP of the PCs and servers that are trying to talk to each other. 00:08:30.000 --> 00:08:35.000 So in our original packet, private IPs of the devices trying to communicate, 00:08:35.000 --> 00:08:42.000 and then in the GRE header, public interface of each end of the tunnel. 00:08:43.000 --> 00:08:51.000 Now, we take that GRE encapsulated packet, and we send it to the physical interface, 00:08:51.000 --> 00:08:53.000 to send it out the physical interface. 00:08:53.000 --> 00:09:00.000 And now that we're going out the physical interface, it's an IPSec enabled interface. 00:09:00.000 --> 00:09:02.000 So what does that mean now? 00:09:02.000 --> 00:09:07.000 It means we now wrap the GRE packet in IPSec. 00:09:07.000 --> 00:09:09.000 That's what we're doing. 00:09:10.000 --> 00:09:16.000 So now we can encapsulate the GRE packet. 00:09:16.000 --> 00:09:20.000 If we're using tunnel mode, then what would we do? 00:09:20.000 --> 00:09:23.000 We add it on our ESP headers, our ESP trailers, our ESP auth, 00:09:23.000 --> 00:09:28.000 and we create a new IP header while preserving just GRE header and this original IP. 00:09:28.000 --> 00:09:35.000 But the source and destination of that IPSec tunnel is the same source and destination as GRE IPSec. 00:09:35.000 --> 00:09:36.000 So it's kind of waste. 00:09:36.000 --> 00:09:38.000 It's kind of redundant, but it's okay. 00:09:38.000 --> 00:09:39.000 It's only 20 bytes. 00:09:39.000 --> 00:09:42.000 It's really not that big of a deal in the grand scheme of things. 00:09:42.000 --> 00:09:47.000 But if you're using transport mode instead, then once you wrap it with the ESP header, 00:09:47.000 --> 00:09:52.000 the ESP trailer, the ESP auth, then you create a new IP header, 00:09:52.000 --> 00:09:58.000 which is the source and destination of those physical interfaces. 00:09:59.000 --> 00:10:06.000 Now the traffic is protected as it crosses. 00:10:06.000 --> 00:10:13.000 So now even your OSPF packet, your OSPF packet that needs to go from R1 to branch 00:10:13.000 --> 00:10:18.000 through the GRE tunnel gets generated by the router, sent out to the router, 00:10:18.000 --> 00:10:20.000 and then it's sent out to the router. 00:10:20.000 --> 00:10:25.000 Your OSPF packet that needs to go from R1 to branch through the GRE tunnel 00:10:25.000 --> 00:10:29.000 gets generated by the router, sent out to the tunnel interface, 00:10:29.000 --> 00:10:31.000 but gets to the tunnel interface, what does it mean? 00:10:31.000 --> 00:10:33.000 What does the tunnel interface really mean? 00:10:33.000 --> 00:10:35.000 It means encapsulated with a GRE header. 00:10:35.000 --> 00:10:37.000 And then what interface do you send it out of? 00:10:37.000 --> 00:10:38.000 Oh, the physical interface. 00:10:38.000 --> 00:10:40.000 Okay, send it to the physical interface. 00:10:40.000 --> 00:10:42.000 Oh, look at that, IPSec. 00:10:42.000 --> 00:10:47.000 Let's wrap it up now in IPSec header information, and then we'll send it out, 00:10:47.000 --> 00:10:52.000 all encrypted across the public Internet until it reaches the other side. 00:10:52.000 --> 00:10:56.000 The other side gets it, takes off the IPSec information, 00:10:56.000 --> 00:11:01.000 then tears apart the GRE information, then looks at the original IP header, 00:11:01.000 --> 00:11:05.000 and then routes it through the rest of the branch office. 00:11:05.000 --> 00:11:06.000 That's it. 00:11:06.000 --> 00:11:07.000 There you go. 00:11:07.000 --> 00:11:09.000 That is a tunnel, right? 00:11:09.000 --> 00:11:11.000 There is no tunnel. 00:11:11.000 --> 00:11:14.000 It's all encapsulation. 00:11:14.000 --> 00:11:18.000 Verification, so show interface tunnel like we saw with GRE. 00:11:18.000 --> 00:11:21.000 With IPSec, show crypto ISA camp security association. 00:11:21.000 --> 00:11:23.000 Show crypto IPSec security association. 00:11:23.000 --> 00:11:25.000 Verify phase 1, phase 2. 00:11:25.000 --> 00:11:26.000 Nothing's changed. 00:11:26.000 --> 00:11:27.000 It's all the same. 00:11:27.000 --> 00:11:28.000 It's great. 00:11:28.000 --> 00:11:30.000 When you learn GRE and then you learn IPSec, 00:11:30.000 --> 00:11:34.000 then it's so easy to combine them together because there's a few minor things that we said we changed, 00:11:34.000 --> 00:11:40.000 like the access control list. 00:11:40.000 --> 00:11:43.000 And so that brings us to the final discussion here that's so important. 00:11:44.000 --> 00:11:45.000 And that is what? 00:11:45.000 --> 00:11:52.000 Remembering that when you do this, you are adding on a lot of information. 00:11:52.000 --> 00:12:01.000 And therefore, your packet size has to decrease because this is your new packet. 00:12:01.000 --> 00:12:04.000 This is your new packet. 00:12:04.000 --> 00:12:06.000 That can't be greater than what? 00:12:06.000 --> 00:12:08.000 1,500 bytes. 00:12:08.000 --> 00:12:11.000 So what does that mean? 00:12:11.000 --> 00:12:21.000 That this gets smaller and smaller, the data that any end user device can send. 00:12:21.000 --> 00:12:28.000 So if this was 1,500 bytes, well, that's no good because as soon as you add this on, this on, it breaks down. 00:12:28.000 --> 00:12:32.000 So typically, how much data is actually being transmitted? 00:12:32.000 --> 00:12:34.000 Well, you've got 1,460. 00:12:34.000 --> 00:12:35.000 You've got 20. 00:12:35.000 --> 00:12:36.000 You've got 20. 00:12:36.000 --> 00:12:37.000 That's typically. 00:12:38.000 --> 00:12:45.000 So already, in a 1,500-byte packet, there's only like 1,460 of data in it. 00:12:45.000 --> 00:12:50.000 And typically, even less, a little less than that because of other headers and other information that get applied. 00:12:50.000 --> 00:12:54.000 But let's just say 1,460. 00:12:54.000 --> 00:12:56.000 So now with GRE, you've got to add what? 00:12:56.000 --> 00:12:59.000 You've got to add four bytes for this one. 00:12:59.000 --> 00:13:07.000 You've got to add 20 bytes for this one. 00:13:07.000 --> 00:13:09.000 So how much data now? 00:13:09.000 --> 00:13:12.000 Well, subtract 20 and subtract four. 00:13:12.000 --> 00:13:16.000 So really, a client, if we subtract 20 off of this now, we're down to what? 00:13:16.000 --> 00:13:18.000 1,440. 00:13:18.000 --> 00:13:28.000 Now we're down to 1,436. 00:13:28.000 --> 00:13:31.000 When you start putting it all together. 00:13:31.000 --> 00:13:33.000 And let's not forget, we've got a new header here. 00:13:33.000 --> 00:13:36.000 That's another 20 bytes, let's say, if you're using tunnel mode. 00:13:36.000 --> 00:13:39.000 So the size of that has got to go down 20. 00:13:39.000 --> 00:13:42.000 1,460. 00:13:42.000 --> 00:13:44.000 And what about all of this? 00:13:44.000 --> 00:13:45.000 All of this, right? 00:13:45.000 --> 00:13:46.000 Variable again. 00:13:46.000 --> 00:13:47.000 We don't really know. 00:13:47.000 --> 00:13:53.000 I mean, we saw that we could look at our IPSec tunnel and kind of get an idea of what it is. 00:13:53.000 --> 00:13:59.000 But let's say for safety sakes, let's say we've got to drop another 100 off. 00:13:59.000 --> 00:14:03.000 Let's say all of that combined equals 100. 00:14:03.000 --> 00:14:09.000 So this plus this plus this is, let's say, 100. 00:14:09.000 --> 00:14:14.000 So now we're at 1,316 when it's all said and done. 00:14:15.000 --> 00:14:24.000 Because 1,316 plus 20 plus 20 plus 100 plus 20 plus 4 plus 20 equals 1,500. 00:14:24.000 --> 00:14:26.000 So there you go. 00:14:26.000 --> 00:14:29.000 So what size is this now? 00:14:29.000 --> 00:14:31.000 The packet is what? 00:14:31.000 --> 00:14:37.000 Or the maximum amount of data that anybody can send is like 1,316. 00:14:37.000 --> 00:14:43.000 And then once we add it all together, we ultimately get a number that is less than 1,500, which is what we want. 00:14:44.000 --> 00:14:51.000 So just like before, what happens if a router receives a 1,500-byte packet? 00:14:51.000 --> 00:15:00.000 Well, it has to fragment it because it will not be able to send it out the interface after doing all of this. 00:15:00.000 --> 00:15:08.000 So it's imperative that in environments where we're doing encapsulation, like GRE encapsulation, IPSec encapsulation, 00:15:08.000 --> 00:15:16.000 we are mindful that the size of the encrypted packet is going to potentially exceed 1,500 bytes. 00:15:16.000 --> 00:15:24.000 So it's imperative that all of our end-user stations, all of the traffic that is being generated is much smaller. 00:15:24.000 --> 00:15:31.000 So by adjusting our MTUs, lowering MTUs, so on an interface, lowering it, 00:15:31.000 --> 00:15:40.000 or even you have the ability for TCP to adjust the maximum segment size for TCP as well on your Cisco routers. 00:15:40.000 --> 00:15:49.000 So on the exam, if they say, hey, you need to ensure fragmentation doesn't occur for TCP, 00:15:49.000 --> 00:15:52.000 well, obviously both of those are options. 00:15:52.000 --> 00:15:57.000 But what if all of a sudden IPMTU wasn't there because they're trying to test you on, 00:15:57.000 --> 00:16:04.000 do you understand that for just TCP traffic you could just do the maximum segment size, which would be this size here. 00:16:04.000 --> 00:16:12.000 That's your segment size, segment size, whereas the IPMTU is what? 00:16:12.000 --> 00:16:16.000 That's your packet size, right? 00:16:16.000 --> 00:16:18.000 So keep that in mind for the exam. 00:16:18.000 --> 00:16:20.000 Just pay attention to words, pay attention to the details. 00:16:20.000 --> 00:16:32.000 And if they say, hey, you need to adjust the MTU for all IP traffic, IPMTU, just TCP, then do your TCP, adjust MSS, 00:16:32.000 --> 00:16:35.000 whatever they tell you to do. 00:16:35.000 --> 00:16:41.000 And so now the host is going to have to make sure it's building properly sized packets. 00:16:41.000 --> 00:16:43.000 And we rely on a feature called the PathMTU Discovery, 00:16:43.000 --> 00:16:46.000 which should be on the scope of the course and certification exam. 00:16:46.000 --> 00:16:51.000 But if you want to learn more about PathMTU Discovery, just look it up, do a little bit of searching on it. 00:16:51.000 --> 00:16:58.000 But essentially what it does is if a client sends out a packet that is too big and a router has to fragment it, 00:16:58.000 --> 00:17:04.000 the router will respond back to the client and essentially say, hey, no, that is going to have to be fragmented. 00:17:04.000 --> 00:17:05.000 Here's the MTU. 00:17:05.000 --> 00:17:10.000 Therefore, build something that is smaller than this MTU or this MTU or smaller. 00:17:11.000 --> 00:17:17.000 And then the client can retransmit, start over, and go ahead and transmit at the lower MTU. 00:17:17.000 --> 00:17:18.000 But that only works with TCP. 00:17:18.000 --> 00:17:20.000 That wouldn't work with UDP or anything else. 00:17:20.000 --> 00:17:23.000 It just works with TCP, that PathMTU Discovery. 00:17:23.000 --> 00:17:24.000 But it's pretty cool. 00:17:24.000 --> 00:17:27.000 Not something that's part of the exam, but you get the idea. 00:17:27.000 --> 00:17:33.000 So the key here is just to make sure you recognize that they could possibly, during some GRE discussion or IPSEC discussion 00:17:33.000 --> 00:17:38.000 or just on the exam, question you or test you about the fact that all of this encapsulation going on, 00:17:38.000 --> 00:17:43.000 what could possibly happen, fragmentation, how do you alleviate that fragmentation, 00:17:43.000 --> 00:17:45.000 bam, stuff like that right there. 00:17:45.000 --> 00:17:49.000 There's your answers. 00:17:49.000 --> 00:17:50.000 All right, so there you go, folks. 00:17:50.000 --> 00:17:58.000 You now have a solid understanding of GRE, IPSEC, site-to-site VPN tunnels, and GRE over IPSEC. 00:17:58.000 --> 00:18:03.000 And I encourage you to make sure you're well familiar with the configuration of that stuff for the certification exam 00:18:03.000 --> 00:18:08.000 because if it comes up and you actually have to do it, I want you to make sure that you can actually do it, 00:18:08.000 --> 00:18:17.000 get through it, get it done, and just be satisfied that you knew everything you could about GRE and IPSEC as I described it to you.