Gif IPTunnel networkA-to-networkB not work

[Lars Eggert]

Oldach, Helge wrote:
> 
> You must have the networks connected (on the public side), but when 
> using IPSec your gif tunnel won't really be used. It is just sort of 
> a "placeholder" to get the routing correct.

It is not a good idea to use gifs in parallel with IPsec tunnel mode.,
to do this routing trick. Please see the "options FAST_IPSEC & tunnels"
thread on net@ from circa 4/1/2003.

Basically, that approach creates two parallel virtual topologies, one
out of IPIP tunnels, and one out of IPsec tunnel mode SAs. People often
do this, because they want to route traffic into an IPsec tunnel, and
the SA itself doesn't have a route entry, since they aren't devices.
When using IPIP tunnels with tunnel mode, they abuse the route created
by the gif device for routing, but packets will be hijacked by the
tunnel mode SA, so they never actually enter gif processing (IPsec does
the IPIP encapsulation internally.)

Using IPIP tunnels with transport mode is valid, since packets will
actually flow through the gif device, and get IPsec'ed after they are
IPIP encapsulated. (In multihop topologies, they'll then need to be IPIP
encapsulated again - the virtual network needs both virtual link and
network layers.)

It doesn't give you the full expressiveness of IPsec selectors, but it's
good enough for many VPN schemes (and routing works!)

See
ftp://ftp.rfc-editor.org/internet-drafts/draft-touch-ipsec-vpn-05.txt.
It is currently under in the IESG timeout before going to Informational.

Lars
-- 
Lars Eggert <larse at isi.edu>           USC Information Sciences Institute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3529 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20030827/1394c177/smime.bin