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