Solved: IPSEC & GRE

ccnavinoth1151987 · ‎02-17-2015

Could anyone please help me with the detail explanation about?

GRE over IPSEC vs IPSEC over GRE?
If possible please share me some example with the IP header (like source ip can visible & Tunnel IP encapsulated) with detail example like a source to destination more thank full….
Which Tunnel gets up first GRE or IPSEC?
How IPSEC works with multicast protocol?
GRE tunnel how it’s works in the cloud? ISP has to be done at their end
GRE tunnel how the trace works because while tracing only shows the next hop ip(destination)?
IPSEC Tunnel mode which header will be visible, I seen new ip header would be added so what info available in that header?
IPSEC transport mode which header can be visible, what are the info in available in the header?

Marcin Latosiewicz · ‎02-21-2015

1) IPsec over GRE is a rare case, Cisco supports this only for GETVPN deployments.

2) Have a look here:

http://www.cisco.com/c/dam/en/us/td/i/100001-200000/140001-150000/148001-149000/148908.ps/_jcr_content/renditions/148908.jpg

3) I'm assuming we're still talking about GRE over IPsec....That's a complicated one, the bring up the tunnel you need a certain set of control plane checks (tunnel interface is up, route to destination is known etc.) for the tunnel to become up, in which case, in control plane the GRE tunnel interface needs to be up before IKE starts negotiating IPsec. From data plane perspective IPsec tunnel need to be established first before GRE packets are able to be encapsulated into IPsec SAs.

4) Pure IPsec - it's hard but NOT impossible to make it work, at least the theory, because certain implementations will just not support mcast over pure IPsec, but remember that pure IPsec works with traffic selectors, while mcast works with interfaces (a gross oversimplification).

That's one of the reasons technologies like GRE over IPsec and VTI are so popular, they allow virtual interfaces to exist to pass mcast through with same control as with physical interfaces.

5) Rephrase that, please.

6) Rephrase that one too, please.

7 & 8) IPsec adds header (protocols 50 and 51) has to use an IP header of their own indeed. Typically the source and destination will be the tunnel source and destination (ESP, tunnel mode). You can check the difference between tunnel and transport for AH and ESP. There are also technologies, like GETVPN, which copy over the original IP information into the header.

Have a look here:

http://www.cisco.com/c/dam/en/us/td/i/000001-100000/80001-85000/81001-82000/81613.ps/_jcr_content/renditions/81613.jpg

View solution in original post

Marcin Latosiewicz · ‎02-21-2015

1) IPsec over GRE is a rare case, Cisco supports this only for GETVPN deployments.

2) Have a look here:

http://www.cisco.com/c/dam/en/us/td/i/100001-200000/140001-150000/148001-149000/148908.ps/_jcr_content/renditions/148908.jpg

3) I'm assuming we're still talking about GRE over IPsec....That's a complicated one, the bring up the tunnel you need a certain set of control plane checks (tunnel interface is up, route to destination is known etc.) for the tunnel to become up, in which case, in control plane the GRE tunnel interface needs to be up before IKE starts negotiating IPsec. From data plane perspective IPsec tunnel need to be established first before GRE packets are able to be encapsulated into IPsec SAs.

4) Pure IPsec - it's hard but NOT impossible to make it work, at least the theory, because certain implementations will just not support mcast over pure IPsec, but remember that pure IPsec works with traffic selectors, while mcast works with interfaces (a gross oversimplification).

That's one of the reasons technologies like GRE over IPsec and VTI are so popular, they allow virtual interfaces to exist to pass mcast through with same control as with physical interfaces.

5) Rephrase that, please.

6) Rephrase that one too, please.

7 & 8) IPsec adds header (protocols 50 and 51) has to use an IP header of their own indeed. Typically the source and destination will be the tunnel source and destination (ESP, tunnel mode). You can check the difference between tunnel and transport for AH and ESP. There are also technologies, like GETVPN, which copy over the original IP information into the header.

Have a look here:

http://www.cisco.com/c/dam/en/us/td/i/000001-100000/80001-85000/81001-82000/81613.ps/_jcr_content/renditions/81613.jpg

Richard Burts · ‎02-22-2015

I think I understand 6. I think the context of the question is the assumption that trace route will show each hop along the path to the destination. But it does not work that way when part of the path is over a GRE tunnel.

To explain the issue let us think of a source host "S" sending trace route to destination host "D". Let us assume that S connects to router R1 which connects to router R2 which connects to router R3 which connects to router R4 which connects to D. Let us also assume that a GRE tunnel has been configured between R1 and R4 and that the trace route will go over that GRE tunnel.

The trace route from S will get a response from R1 and from R4 but will not get response from R2 or R3. This is because the trace route packet leaving R1 will be encapsulated in GRE. So what R2 sees (and also R3) is just a GRE packet to forward and not a trace route packet to which they should generate a response.

Another way of looking at this question is to remember that trace route works by controlling the Time To Live. But when R1 builds the GRE frame which will transport the trace route it puts a normal TTL and not the controlled TTL used by trace route. So R2 and R3 will not experience the TTL decrementing to zero which triggers the trace route response.

HTH

Rick

HTH

Rick

ccnavinoth1151987 · ‎02-23-2015

Hi Marcin,

Thanks for the response..

So GRE tunnel should come up first am i right ? we always having issue with DMVPN , Either Tunnel will n't up or BGP wil not up but ISP IP able to reach , tried to do the trace destination ip since we are using vrf the trace also not going..

One more question ; IPSEC tunnel mode vs transport mode

i understand the headers but what inside to the header? , can u please explain me & below is my undersatnding

1))))Tunnel mode: {New ip header || ESP|| GRE|| IP || IP/TCP || data} ,,,

In new ip header what ip would be available? whether only tunnel source (ISP) & tunnel Destination of (ISP) or both source and destination should be private ip of source & destination

2))))Transport mode: {Original IP header || GRE || IP(original) || IP /TCP|| Data}

so original ip header only will have the physical ip of ISP interface ???

Marcin Latosiewicz · ‎02-24-2015

GRE tunnel interface may be up without IPsec (unlike VTI), but on the actual data path, you need to have your IPsec tunnel up before GRE packets can flow.

i.e you do control plane checks before determining whether data plane can flow.
Among those checks are: is GRE tunnel interface up? Is the IPsec SA up? etc etc

I think the transport mode picktogram is a bit off, but essentially you save 20 bytes of header, and yes you source and destination IP will be copied over from GRE source and destination - which in case of public IP addresses are the same IPs.