RE: IPSec, GRE, and Transport Mode

From: Wade Edwards (wade.edwards@xxxxxxxxxxxxxxxxxxx)
Date: Wed Mar 13 2002 - 20:14:47 GMT-3


   
I would say that it is connection-less because it does not guarantee
packet delivery.

L8r.

 -----Original Message-----
From: Brian Lodwick [mailto:xpranax@hotmail.com]
Sent: Wednesday, March 13, 2002 4:36 PM
To: nshah@connect.com.au; neiby@ureach.com; ccielab@groupstudy.com
Subject: Re: IPSec, GRE, and Transport Mode

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