Professional Documents
Culture Documents
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.
Hello,
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
1
+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.
Best regards,
Peter
Dear Peter,
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
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?
Regards
Phuc Le
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
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
3
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?
Regards
Phuc Le
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
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.
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
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.
Best regards,
Peter
Dear Peter,
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
6
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.
Regards
Phuc
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
If speaking about GRE over IPsec IPsec over GRE then the order is IPsec first, GRE
second. This order will result in these operations:
If speaking about IPsec over GRE GRE over IPsec then the order is GRE first, IPsec
second. The order will be:
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
https://supportforums.cisco.com/message/3865700#3865700
Dear Peter,
Thank you very much for your time and efforts in assisting me to understand this topic.
Your contribution is greatly appreciated.
Regards
Phuc Le
Hello Phuc,
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
9
Best regards,
Peter
Dear Peter,
Regards
Phuc
Hi Peter,
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
10
3.) Outer header | ESP | Encrypt ( GRE | Original header | Payload ) ! after IPsec transport
mode
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
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
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
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
13