GRE over IPSec; IPSec encapsulated GRE

Guys/Gals

I am confused on how this works. A PC on the HQ LAN sends a packet to a PC on the BRANCH LAN. I am doing GRE over IPSec between the two. Let us ignore any L2/1 stuff for now.

I have tunnel say tunnel 0 with a command that says "tunnel source serial 0/0" and serial0/0 is my untrusted outside interface.

I also have a "crypto map GRETUN0" command applied on my serial 0/0 interface (IOS 12.4, btw).

The GRETUN0 map has a statement combining an extended acl "access-list 100 permit GRE any host x.x.x.x (BRANCH router's public IP)" which matches traffic leaving my router going to the IP of the BRANCH public IP address.

So my packet enters router IP table lookup says BRANCH LAN is reached via s0/0 on my HQ router. So HQ router looks at GRE tunnel and encapsulates the IP packet so that it will have source IP of tunnel 0 IP on HQ and destination of tunnel 0 IP on BRANCH. IPSec matches GRE traffic rule because of the crypto map statement on my s0/0 and encapsulates the GRE tunnel traffic with ESP header/footer and routes to BRANCH router.

Does this sound correct to you I have been struggling to understand GRE vs. IPSec vs. GRE over IPSec. the acl's really confound me.

I did this lab in GNS3 so if you want to see config let me know.

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

SysAdmin4066

GRE is a tunneling protocol. It offers very little security and is not adequate over a public network by itself. It's original use was to allow for the traversing of non IP traffic to be tunneled through IP networks.

IPSec is considered a tunneling protocol as well. It allows for "interesting traffic" to be encrypted and tunneled through insecure networks to protect confidentiality and integrity. IPSec is limited as it does not give an interface with which to work through. It is more like a net that you set on an interface and it catches all of the traffic you specify as interesting traffic. This is done with the ACL you mentioned. This does not allow you to use routing protocols with IPSec, as there is no interface in which to support neighbor relationships.

So the two were put together, i.e IPSec over GRE which gives you an interface to work with for neighbor relationships for routing protocols with GRE and encryption on the traffic traversing the GRE tunnel with IPSec. Basically you setup the GRE tunnel first, then you encrypt all traffic traversing that tunnel with IPSec's crypto map.

When I was learning the two, I learned them first separately, then put them together. So for example, I worked labs with nothing but creating GRE tunnels. I learned exactly what the purpose of the GRE tunnel was, it's limitations, its strengths and how to configure it correctly. Then I worked labs with nothing but IPSec tunnels. I learned its strengths, weaknesses and how to configure it properly. Then I combined the two and learned how they complemented each other. And dont forget the SDM dynamic. You'll need to know how to do both IPSec and GRE over IPSec via CLI and SDM to be successful with this exam, which the exam topics will tell you.

As for the ACL, think of that again as the net that catches the data that needs to be encrypted. The ACL is different depending on what application you're using, whether its just IPSec or whether its a GRE over IPSec tunnel. In the case of just IPSec, you're going to want to set the ACL to capture all IP traffic traversing your source interface going to the tunnel destination that you want encrypted. This means you'll have to know exactly what subnets you want encrypted.

The ACL is a bit simplified with GRE as you only need to permit GRE from source your GRE tunnel interface to destination the tunnel endpoint. This will encrypt all GRE traffic, which is what you want.

Basically though, the ACL spells out what traffic is "interesting" and should therefore invoke the tunnel and be encrypted. Generating "interesting traffic" is a step in the IPSec VPN tunell construction. The tunnel will not be built without first generating that traffic based on what your ACL says. So with just IPSec from CLI, I had to always ping from the source address to the destination address to invoke the tunnel. Otherwise, there is no tunnel built.

Have you been successful in any of your labs? There might be a problem with your ACL having a source of ANY in the real world, unless you want ALL traffic to be encrypted. With a GRE tunnel, you would just set the source as the tunnel interface source, whatever that is. That's the benefit of having a tunnel.

What lab materials are you using? I found the Cisco Press material to be very good in preparing for the practical application of the exam.

jeanathan

the IPSec VPN tunell construction

Oddly enough I think that is all that was confusing me. I keep thinking of IPSec as a protocol like rip, tcp, is-is, and ect... are protocols. Where GRE uses a "tunnel" interface every time I was seeing IPSec tunnel in the text It made me think of a GRE Tunnel interface.

I did, like you, a complex GRE lab then IPSec VPN lab and finally I just did a GRE over IPSec lab today. I got everything working.

It was just that as I tried to think like the router, and I was getting confused as to the exact order of how a packet is routed/encapsulated during the tunnel building processes.

So I think I understand now that all traffic in the routing table flowing to a destination via a physical interface that has a tunnel running across gets encapsulated by GRE.

C 172.16.0.0 is directly connected, Tunnel1

Then ISAKMP does its thing, followed by IPSec, and then finally the packet is forwarded out the physical interface thanks to my tunnel end point IP address.

The receiving router un-encrypts the IPSec tunnel traffic, then the GRE tunnel is un-encapsulated, then does what ever r&s is necessary.

I have the cisco press book, not a big fan of the layout, but the content is spot on. I have been using Train Signal too. I didn't feel comfortable taking the test on the 1st try with Train Signal. Labs are the way to go!

SysAdmin4066

You've got it! And you're right about labs. They are definitely the way to go, knowing how to configure these topics and actually doing them are slightly different and it takes repetition if you're not doing them in your everyday life. Before I started this exam, I hadnt built a VPN via CLI ever. I had administered them, sure, and I'd worked with Watchguards and Sonicwalls, but never via CLI. So actually doing it solidified the steps in my brain and helped me to understand looking at them even more. At work the majority of our devices are Enterasys, who bought cabletron back in the days. Definitely inferior to Cisco, but that's what I got. So things are done a little bit differently for certain things on routers and a lot differently for things on switches, but if you understand the concepts, you'll understand what you're looking at. The protocols dont change, just the methods of implementation. Hope all of this helped, the ISCW was my favorite exam so far. Not too difficult, and the labs were really fun.