From: Brian Lodwick (xpranax@xxxxxxxxxxx)
Date: Wed Mar 13 2002 - 19:35:42 GMT-3
This same question came up just a little while ago.
When using IPsec ESP in Tunnel mode it will append a new IP header (and an
ESP header) to the front of the original IP packet in addition to encrypting
everything from the ESP header in.
When using IPsec ESP in Transport mode it will not append an additional IP
header to the front of the original IP packet. It will only encrypt the
packet from the ESP header in (and ofcourse will add an ESP header in
between the original IP header and the upper-layer protocol information).
So if you were using IPsec ESP in transport mode (no GRE tunnel) and the
source address of a packet was 10.0.0.1, because it was from one of the
hosts within your internal network the packet would never return, and like
the guy below said the real address of the host would be exposed.
If you are encapsultating the original IP packet inside of GRE (then
encrypting the GRE packets by using IPsec) GRE will append an additional IP
header to the front of the original IP packet, and the source address will
then become whatever the source address of the GRE tunnel is. In this case
there is no reason to use IPsec ESP Tunnel mode to append another IP header
on the front because GRE has done that work already.
in short the reason is that IPsec ESP Tunnel mode appends a new IP header
onto the front of the original IP packet.
GRE also appends a new IP header to the front of the original IP packet, so
there is no need to add additional work for the routers by wrapping layer 3,
3 times.
New IPsec question of the day for those interested:
Is IPsec ESP in Tunnel mode connection-oriented or connectionless?
>>>Brian
>From: "Nick Shah" <nshah@connect.com.au>
>Reply-To: "Nick Shah" <nshah@connect.com.au>
>To: "John Neiberger" <neiby@ureach.com>, <ccielab@groupstudy.com>
>Subject: Re: IPSec, GRE, and Transport Mode
>Date: Thu, 14 Mar 2002 08:38:20 +1100
>
>When using IPSEC in tunnel mode, the original IP header is encrypted. This
>is good in a way, since it protects the inside of the network, by
>encrypting
>the original source ip address and dest. ip address. The world can see only
>the source and dest. of 2 ipsec peers (not of the communicating devices).
>
>In transport mode, the end user would be initiating the VPN with an IPSEC
>terminating device, so the IP address of client would be the address of teh
>VPN initiator, exposing the actual ip address to the public.
>
>You can prolly use tunnel mode when providing LAN-2-LAN connectivity,
>essentially hiding the addresses of vpn clients.
>
>Dont know of any gotchas, purely functional differences, and can be
>justified only in real world.
>
>hth.
>Nick
>
>-----Original Message-----
>From: John Neiberger <neiby@ureach.com>
>To: ccielab@groupstudy.com <ccielab@groupstudy.com>
>Date: Thursday, 14 March 2002 6:00
>Subject: IPSec, GRE, and Transport Mode
>
>
> >I'm looking at an example on CCO that is encrypting a GRE
> >tunnel, but this is the first time I've noticed the addition
> >of 'mode transport' in the configuration.
> >
> >I was under the impression that transport mode was for use only
> >when the tunnel endpoints were creating the traffic. Does that
> >apply here because the router endpoints are creating the GRE
> >packets and are therefore the end hosts? That kind of makes
> >sense.
> >
> >What would be the functional different in this case between
> >tunnel mode and transport mode? If we're using a GRE tunnel,
> >would there be any significant difference? Any gotchas
> >regarding either method with GRE?
> >
> >Thanks,
> >John <-- IPsec neophyte
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:04 GMT-3