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 <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
