Date: Fri, 2 Aug 2002 10:43:21 -0700 From: "Crist J. Clark" <crist.clark@attbi.com> To: Matthew Grooms <mgrooms@seton.org> Cc: freebsd-security@FreeBSD.org Subject: Re: esp tunnel without gif(4) [Was Re: vpn1/fw1 NG to ipsec/racoontroubles, help please ...] Message-ID: <20020802174321.GB6880@blossom.cjclark.org> In-Reply-To: <sd4a58ca.054@aus-gwia.aus.dcnhs.org> References: <sd4a58ca.054@aus-gwia.aus.dcnhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 02, 2002 at 10:02:38AM -0500, Matthew Grooms wrote:
> Eric,
>
> How traffic will be routed is defined by your near/far encryption
> domains that were configured via setkey/spdadd directives. These src/dst
> domains are compared to packet src/dst to determine if they need to be
> encrypted. The IPSEC peer gateway is also defined for each spdadd so
> that your gateway knows where to forward the packets after the
> ecrypt/encap step.
Yep.
> This works a bit different for gif enabled tunnels because the IPSEC
> peer gateways are actually defined by the private tunnel interface end
> points, not the publicly routable interfaces. Its also possible to use a
> mixture if giff'd and 'vanila' ESP tunnels. I am doing this right now so
> I have attached my config script as an example.
But why? Is there something this configuration buys you that you don't
get when all are "vanilla" ESP tunnels?
> <snip>
>
> echo Initializing IPSEC security policies ...
>
> # create tunnel device
> ifconfig gif0 create 2> /dev/null
>
> # public addresses ( external )
> gifconfig gif0 66.90.146.202 66.68.118.215
>
> # private addresses ( internal )
> ifconfig gif0 inet 10.22.200.1 10.1.2.1 netmask 255.255.255.0
>
> # delete all existing SPD and SAD entries
> setkey -FP
> setkey -F
> setkey -c << EOF
>
> spdadd 10.22.200.0/24 10.1.2.0/24 any -P out ipsec
> esp/tunnel/10.22.200.1-10.1.2.1/require;
> spdadd 10.1.2.0/24 10.22.200.0/24 any -P in ipsec
> esp/tunnel/10.1.2.1-10.22.200.1/require;
You seem to be doing this backwards from the usual way (or what I
think of as the usual way)... and I really do not understand why. You
are taking traffic from,
10.22.200.0/24 <-> 10.1.2.0/24
And encapsulating it in an ESP tunnel,
10.22.200.1 <-> 10.1.2.1
Which _then_ gets put into an (unencrypted) gif(4) tunnel,
66.90.146.202 <-> 66.68.118.215
When I think of gif(4) tunnels, I think of people doing,
10.22.200.0/24 <-> 10.1.2.0/24
In a gif(4) tunnel,
66.90.146.202 <-> 66.68.118.215
And then running ESP in _transport_ mode between those same two
endpoints. I could also see running a tunnel within a tunnel like
you have, but again, I would usually expect the ESP tunnel to be the
outer one.
> spdadd 10.22.200.0/24 10.20.0.0/16 any -P out ipsec
> esp/tunnel/66.90.146.202-65.118.63.252/require;
> spdadd 10.20.0.0/16 10.22.200.0/24 any -P in ipsec
> esp/tunnel/65.118.63.252-66.90.146.202/require;
>
> spdadd 10.22.200.0/24 10.21.0.0/16 any -P out ipsec
> esp/tunnel/66.90.146.202-65.118.63.252/require;
> spdadd 10.21.0.0/16 10.22.200.0/24 any -P in ipsec
> esp/tunnel/65.118.63.252-66.90.146.202/require;
>
> spdadd 10.22.200.0/24 10.23.0.0/16 any -P out ipsec
> esp/tunnel/66.90.146.202-65.118.63.252/require;
> spdadd 10.23.0.0/16 10.22.200.0/24 any -P in ipsec
> esp/tunnel/65.118.63.252-66.90.146.202/require;
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020802174321.GB6880>