You are on page 1of 13

Transport mode and GRE tunnel

Phuc Le 13 posts since Feb 13, 2011


Transport mode and GRE tunnel Nov 18, 2012 10:07 PM

Dear Sir/Madam,

I understand that using transport mode does not encrypt the IP header, but only the payload.
Is that's why it is recommend to incorporate GRE tunnel with transport mode to enhance
security? Can you please explain how. Please see url below.

For example, DSD recommend to use Control 0495 at http://www.dsd.gov.au/


publications/Information_Security_Manual_2012_Controls.pdf.

Can someone kindly explain why?


Tags: gre, dmvpn, tunnel, ip, and, mode, tranport

Peter Paluch 6,729 posts since Jul 29, 2005


Transport mode and GRE tunnel Nov 19, 2012 12:02 AM

Hello,

GRE has absolutely no impact on security - it is itself an unprotected tunneling protocol


that does not protect the tunneled data in any way. GRE is often combined with IPsec
because of two main reasons: it is capable of tunneling any protocol within an IP-based
tunnel, and is capably of carrying multicast traffic. IPsec alone supports only unicast IP
traffic. Therefore, if different types of traffic are to be carried over an IPsec tunnel, they are
first GRE-encapsulated (thereby putting the passenger protocol into a unicast IP header

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
1

Transport mode and GRE tunnel

+GRE header) and then protected using IPsec. Note that here, I am talking about a specific
sequence of operations: first, GRE, then, IPsec.

The Control 0495 says, in particular: "Agencies choosing to use transport mode should
additionally use an IP tunnel for IPsec connections." As you have pointed out, in the
transport mode, the IP header of the original packet is retained and is not encrypted. The
original header can be "obfuscated" by putting the entire IPsec datagram in an additional
GRE tunnel tunnel, assuming that the device performing the GRE tunneling is different from
the IPsec endpoints. However, this does not really protect the original header, just makes
it a payload of the GRE packet - however, it is not encrypted and deep packet inspection
would easily reveal all the details. I therefore assume that the Control 0495 only tries to hide
the original IP header from basic router and firewall implementations. Note that here, the
sequence of operations is different: first, IPsec, then, GRE.

I would say that the real benefit of Control 0495 is somewhat questionable.

Please feel welcome to ask further!

Best regards,
Peter

Phuc Le 13 posts since Feb 13, 2011


Transport mode and GRE tunnel Nov 19, 2012 4:50 PM

Dear Peter,

I appreciated your quick response and thank you very much.

What happens when the same scenario above is implemted with DMVPN:

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
2

Transport mode and GRE tunnel

1. does it change the sequence of operations: first IPSEC, then, GRE: then NBMA ? Is
this order correct?

2. does the GRE packet now becomes the payload of the NBMA packet, therefore it
gets encrypted, and a new IP header contains the NBMA src ipaddress and dst ipaddress is
added to the front of the GRE packet. Does this scenario now protects the original header?

Thank you kindly Peter

Regards
Phuc Le

Phuc Le 13 posts since Feb 13, 2011


Transport mode and GRE tunnel Nov 19, 2012 10:11 PM

Dear Peter,

I am not sure because I marked your answer as Correct, does that mean this question is
closed.
Apologies, I am new to this tool.

You've gave an awesome answer as it was detailed and informative. So thank you very
much

I have another follow up question:

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
3

Transport mode and GRE tunnel

What happens when the same scenario above is implemented with DMVPN:

1. does it change the sequence of operations: first IPSEC, then, GRE, then NBMA ? Is
this order correct?

1. does the GRE packet now becomes the payload of the NBMA packet, therefore it
gets encrypted, and new a IP header contains the NBMA src ipaddress and dst ipaddress is
added to the front of the GRE packet. Does this scenario now protects the original header?

Thank you kindly Peter

Regards
Phuc Le

Peter Paluch 6,729 posts since Jul 29, 2005


Transport mode and GRE tunnel Nov 19, 2012 11:28 PM

Hello Phuc,

You are welcome! Regarding marking the answer as correct: on this forum, there is really no
concept of a "closed" thread. Marking the answer as "correct" means that you consider the
answer to be a complete solution to your problem, and the thread will be visibly indicated to
include a solution (a green tick and a description of "Answered"). However, you can always
post new questions to such thread and anyone can further answer the additional questions,
and you may mark any number of answers as also being "correct".

What happens when the same scenario above is implemented with DMVPN:

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
4

Transport mode and GRE tunnel

The DMVPN order of operations is first GRE, then IPsec.

does the GRE packet now becomes the payload of the NBMA packet, therefore it gets
encrypted, and new a IP header contains the NBMA src ipaddress and dst ipaddress is added
to the front of the GRE packet. Does this scenario now protects the original header?

Yes, this would be a correct description. I have seen the DMVPN being implemented
typically in IPsec tunnel mode (as opposed to transport mode). The encapsulation order
then looks like this:

1. Original header | Payload - this is the packet as sent by a computer inside a DMVPN site
2. Outer header | GRE | Original header | Payload - this is the packet immediately after GRE
encapsulation)
3. Outer header | ESP | Encrypt(Outer header | GRE | Original header | Payload) - this is the
IPsec protected packet

Note that there are in fact three IP headers here, with one IP header basically duplicating
itself because both GRE encapsulation and IPsec tunnel mode always add a new IP header,
even though the addressing is identical (because both tunneling mechanisms are typically
performed on a single node). However, the original IP header is protected.

In IPsec transport mode, the order of operations looks as follows:

1. Original header | Payload - this is the packet as sent by a computer inside a DMVPN site
2. Outer header | GRE | Original header | Payload - this is the packet immediately after GRE
encapsulation)

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
5

Transport mode and GRE tunnel

3. Outer header | ESP | Encrypt(GRE | Original header | Payload) - this is the IPsec
protected packet

Here, the IPsec does not add a new IP header and instead it reuses the outer IP header as
added in the second stage. The original IP header is still protected, though.

Please feel welcome to ask further!

Best regards,
Peter

Phuc Le 13 posts since Feb 13, 2011


Transport mode and GRE tunnel Nov 20, 2012 2:53 PM

Dear Peter,

You've again answered my question promptly and exceeded my expectation.


I like the fact you took time to give a very detailed explanation, which helped me to
understand now.
So thank you very much.

So in summary, when transport mode is coupled with GRE in an DMVPN implementation,


then the original header is encrypted. Whereas if transport mode is used with GRE in a
native IPSec, then the original header is obfuscated, thus deeply hidden away, but not
encrypted.

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
6

Transport mode and GRE tunnel

I understand that the reason why Transport mode is preferred over Tunnel mode in
DMVPN is because it reduces overhead, thus saving 20 bytes over Tunnel mode. Is this a
understanding correct.

Have a nice weekend

Thank you very much Peter.

Regards
Phuc

Peter Paluch 6,729 posts since Jul 29, 2005


Re: Transport mode and GRE tunnel Mar 1, 2013 5:53 AM

Hello Phuc,

So in summary, when transport mode is coupled with GRE in an DMVPN implementation, then
the original header is encrypted.

Yes, that is correct. In DMVPN, the order of operation is always GRE first, IPsec second.

Whereas if transport mode is used with GRE in a native IPSec, then the original header is
obfuscated, thus deeply hidden away, but not encrypted.

This is not that clear because the order of operations is not clear from this short description.

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
7

Transport mode and GRE tunnel

If speaking about GRE over IPsec IPsec over GRE then the order is IPsec first, GRE
second. This order will result in these operations:

1.) Original header | Payload ! before IPsec


2.) Original header | ESP | Encrypt ( Payload ) ! after IPsec in transport mode
3.) Outer header | GRE | Original header | ESP | Encrypt ( Payload ) ! after GRE

Here, the original header is obfuscated but not encrypted.

If speaking about IPsec over GRE GRE over IPsec then the order is GRE first, IPsec
second. The order will be:

1.) Original header | Payload ! before GRE


2.) Outer header | GRE | Original header | Payload ! after GRE
3.) Outer header | ESP | Encrypt ( GRE | Original header | Payload ) ! after IPsec transport
mode

Here the original header is encrypted.

Best regards,
Peter

EDIT: Thanks to berney! He spotted the wrong order of operations in my original version of
this post. Correcting now. See berney's comment at

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
8

Transport mode and GRE tunnel

https://supportforums.cisco.com/message/3865700#3865700

Phuc Le 13 posts since Feb 13, 2011


Transport mode and GRE tunnel Nov 25, 2012 2:38 PM

Dear Peter,

Thank you very much for your time and efforts in assisting me to understand this topic.
Your contribution is greatly appreciated.

It makes sense logically for each respective scenario

I am from Australia. Were are you based?

Regards
Phuc Le

Peter Paluch 6,729 posts since Jul 29, 2005


Transport mode and GRE tunnel Nov 25, 2012 4:35 PM

Hello Phuc,

You are very much welcome!

I am from Australia. Were are you based?

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
9

Transport mode and GRE tunnel

On the opposite hemisphere, in Slovakia, Central Europe.

Best regards,
Peter

Phuc Le 13 posts since Feb 13, 2011


Transport mode and GRE tunnel Jan 8, 2013 7:05 PM

Dear Peter,

I would like to say happy new year.

Regards
Phuc

Zhong Feng 2 posts since Sep 9, 2012


Transport mode and GRE tunnel Feb 25, 2013 1:00 AM

Hi Peter,

Please correct me if I am wrong,


1. but why I feel that in how the packets encrypted, it should be this way:
GRE over IPSec:
1.) Original header | Payload ! before GRE
2.) Outer header | GRE | Original header | Payload ! after GRE

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
10

Transport mode and GRE tunnel

3.) Outer header | ESP | Encrypt ( GRE | Original header | Payload ) ! after IPsec transport
mode

IPSec over GRE:


1.) Original header | Payload ! before IPsec
2.) Original header | ESP | Encrypt ( Payload ) ! after IPsec in transport mode
3.) Outer header | GRE | Original header | ESP | Encrypt ( Payload ) ! after GRE

2. Do you mind to share in which senario we should use GRE over IPsec, and which senario
we should use IPsec over GRE?

Please advise,

Thanks.

berney

Peter Paluch 6,729 posts since Jul 29, 2005


Transport mode and GRE tunnel Mar 1, 2013 5:50 AM

Hello Berney,

1. but why I feel that in how the packets encrypted, it should be this way:
GRE over IPSec:

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
11

Transport mode and GRE tunnel

1.) Original header | Payload ! before GRE


2.) Outer header | GRE | Original header | Payload ! after GRE
3.) Outer header | ESP | Encrypt ( GRE | Original header | Payload ) ! after
IPsec transport mode

IPSec over GRE:


1.) Original header | Payload ! before IPsec
2.) Original header | ESP | Encrypt ( Payload ) ! after IPsec in transport
mode
3.) Outer header | GRE | Original header | ESP | Encrypt ( Payload ) ! after
GRE

Yeah, yes, you are correct here. I must have been tired or brain-dead or something when
explaining those pesky what-over-what combinations. Good catch! Rated as deserved, and I
am correcting my previous post so that no one else will get confused.

2. Do you mind to share in which senario we should use GRE over IPsec, and which senario
we should use IPsec over GRE?

To be honest, I have never seen IPsec-over-GRE. I do not think that this combination is
particularly useful because IPsec by itself is capable of carrying IPv4/IPv6 traffic only,
and encapsulating the resulting IPsec datagram into a GRE packet provides no additional
functionality, apart from possibly hiding the original IP header beneath a new IP header.
When talking about IPsec and GRE cooperation, I always think in terms of GRE-over-IPsec
tunnels.

Best regards,
Peter

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
12

Transport mode and GRE tunnel

Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
13

You might also like