- From: Brian Candler <B.Candler@xxxxxxxxx>
- Date: Wed, 28 Dec 2005 14:38:17 +0000
The IPSEC documentation at
pretty weird. It suggests that you encapsulate your packets in IP-IP (gif)
encapsulation and THEN encapsulate that again using IPSEC tunnel mode.
e.g. notice where it shows
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
('ipencap' is IP protocol 4, aka RFC 2003 encapsulation). The diagram
beneath makes this double-tunnelling explicit.
This is a really strange approach which is almost guaranteed not to
interoperate with other IPSEC gateways. (It might be useful if you were
using etherip encapsulation and attempting to bridge two remote networks,
but that's not what it's doing either. In any case, if you're encapsulating
with a different protocol then you only need IPSEC transport mode, not
ISTM that this chapter should be rewritten to use IPSEC tunnel mode solely.
Do people here generally agree? If so I'll try to find the time to modify
freebsd-net@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction
- Next by Date: Re: IPSEC documentation
- Previous by thread: ng_iface+ng_netflow trouble
- Next by thread: Re: IPSEC documentation