How is a GRE tunnel applied to a physical interface?

[Mark Mattix]

Within a tunnel's configuration we use the commands, source and destination for the tunnel but how does the physical interface know to use the tunnel? Do the tunnel's source settings override the physical interface? If we only configure a tunnel with the correct source would that interface then send all information out encapsulated in GRE?

If we also configure IPSec on the interface and specify a crypto map to only encrypt the matching traffic would this matching traffic only use the GREtunnel or is all information regardless if it's encrypted in IPSec also be encapsulated in GRE?

Also, I read here: https://supportforums.cisco.com/docs/DOC-3067

"Bind crypto map to the physical (outside) interface if you are running Cisco IOS  Software Release 12.2.15 or later. If not, then the crypto map must be applied to the tunnel interface as well as the physical interace."

Why was it necessary to apply the crypto map to both the physical and tunnel interfaces, and why is it not necessary with newer IOS versions?

Thanks for any help!  -mark

[Javier Portuguez · Accepted solution]

Hi Mark,

When you define the tunnel source in the tunnel interface, the Router adds the IP address of the specific interface (loopback or physical) to the GRE packet generated by the tunnel interface.

This is useful when you need to route a GRE tunnel across the Internet, but the tunnel interface has a priivate IP, so you use the external interface (with a public IP) as the tunnel source.

When the remote GRE endpoint receives the packet, looks for the tunnel interface that has it as the tunnel destination and decaps the packets, then it gets the GRE packet and routes it to the specific tunnel interface.

Since 12.4 you only need to apply the crypto map to the interface defined as the "tunnel source", usually the one connected to the Internet, where all the VPN tunnels are landed. The reason for that is because the VPN termination endpoint is the physical interface and not the tunnel interface.

The reason why you had to add the crypto map to to both is not clear to me, since I did not support old code versions.

Remember than when you set up a GRE/IPsec tunnel, in the crypto ACL you define the tunnel source and the destination IPs.

Hope to help.

Portu.

Please rate any helpful posts

Message was edited by: Javier Portuguez

[Javier Portuguez]

Mark,

In case you do not have any further questions, please mark this post as answered.

Portu.

[Mark Mattix]

Thank you for your reply Javier, it was very informative. I'm just trying to understand now what a packet would look like when using GRE and IPSec.

| IP Header | Ah Header | ESP Header | GRE Header | IP Header | IP Payload = ACTUAL DATA | ESP Trailer |

Where does EIGRP fall within this packet? Would EIGRP be within the IP Payload and encapsulated in IPv4? Or is EIGRP not encapsulated in IP and thus why we need GRE to encapsulate it? I will check into these other options as well, thank you all for the information!

[olpeleri]

Hello Mark,

| IP Header | Ah Header | ESP Header | GRE Header | IP Header | IP Payload = ACTUAL DATA | ESP Trailer |

AH header would be very uncommon and will require a recirculation of the packet in the crypto engine [ you divide the crypto perf per 2 if supported by the Crypto engine]

| IP Header | ESP Header | GRE Header | IP Header | IP Payload = ACTUAL DATA | ESP Trailer |

EIGRP would be handled by the IP header+ Ip payload encapsulated after the ESP payload.

If you wanna have a look, you should use ESP-null in your lab, then we just add a ESP header/trailer without encrypting the content.

Cheers,

[Mark Mattix]

I did some reading on EIGRP and is it correct that the EIGRP Header and Payload (TLV) are encapsulated in an IP packet and addressed to the address, 224.0.0.10? Is this the reason why multicast traffic must be encapsulated first in GRE to travel over the internet?

When I set up a site to site VPN using GRE tunnels and an IPSec config on the interfaces would this be considered, IPSec over GRE, or GRE over IPSec? I don't understand that difference.

On the example packet I posted above, is the public address that's routed over the internet part of the IPSec packet/suite? I guess a better question is, what portions of the packet make up IPSec and which portion is just regular IPv4 addressing?

I've been wrong in thinking that GRE and IPSec go hand in hand when infact it's possible to only use IPSec and no type of tunnel. If IPSec is set up on the interfaces and the tunnels are configured at both end points, what does your information first get encapsulated by, GRE or IPSec? In your example packet format Olpeleri, is looks like the IP packet is first encapsulated in GRE then encapsulated by IPSec. Is this correct? If so when information leaves our LAN and heads to the internet, does it first go through the tunnel to be encapsulated by GRE then out the physical link that adds the IPSec encapsulation?

Sorry for all these questions, I'm just trying to learn how this works! Thanks again for the help!

[olpeleri · Accepted solution]

Mark Mattix wrote:
I did some reading on EIGRP and is it correct that the EIGRP Header and Payload (TLV) are encapsulated in an IP packet and addressed to the address, 224.0.0.10? Is this the reason why multicast traffic must be encapsulated first in GRE to travel over the internet?
Olivier Pelerin> This is correct


When I set up a site to site VPN using GRE tunnels and an IPSec config on the interfaces would this be considered, IPSec over GRE, or GRE over IPSec? I don't understand that difference. 
Olivier Pelerin> See the diagram below - this explain GRE over IPSEC. That's a diagram I did here for a training 

On the example packet I posted above, is the public address that's routed over the internet part of the IPSec packet/suite? I guess a better question is, what portions of the packet make up IPSec and which portion is just regular IPv4 addressing?

Olivier Pelerin> the diagram below should answer that


I've been wrong in thinking that GRE and IPSec go hand in hand when infact it's possible to only use IPSec and no type of tunnel. If IPSec is set up on the interfaces and the tunnels are configured at both end points, what does your information first get encapsulated by, GRE or IPSec? In your example packet format Olpeleri, is looks like the IP packet is first encapsulated in GRE then encapsulated by IPSec. Is this correct? If so when information leaves our LAN and heads to the internet, does it first go through the tunnel to be encapsulated by GRE then out the physical link that adds the IPSec encapsulation?

Olivier Pelerin> Correct. GRE first then encryption




Sorry for all these questions, I'm just trying to learn how this works! Thanks again for the help!

[red = encrypted]

[Mark Mattix]

Thank you for your help and time Olpeleri! I understand this a lot better now!

[olpeleri]

Mark,

gre over ipsec with crypto maps should not be used any more. Tunnel protection with an ipsec profile is the way to go. It simplify your config and it allows more possibilities when designing vpn's

An example: http://www.net-gyver.com/?p=93

If you run even a recent code, we are adapting automatically the IP MTU of the tunnel [ including ipsec overhead and GRE encap]

Cheers,

Olivier Pelerin

TAC Escalation VPN

CCIE Security#20306

[Javier Portuguez]

I totally agree with Olivier. You could even consider Flex VPN as an option.

FlexVPN at a glance

Thanks.