Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 03 Jan 2003 12:04:59 +0200
From:      Pekka Nikander <pekka.nikander@nomadiclab.com>
To:        Eric Masson <e-masson@kisoft-services.com>
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change
Message-ID:  <3E15604B.3040505@nomadiclab.com>
In-Reply-To: <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com>
References:  <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Eric Masson wrote:
> Seems pretty close to what OpenBSD has implemented, except they don't
> use the stock loopback interface.
> 
> Their enc(4) driver is a software loopback interface :
> http://www.openbsd.org/cgi-bin/man.cgi?query=enc&sektion=4&arch=i386&apropos=0&manpath=OpenBSD+Current

Thanks for the pointer!

> It's used in src/sys/netinet/ipsec_input.c to impersonate the incoming
> interface just as you did in your patch.
> 
> I'd like to know whether there would be any interest in associating a
> different interface to each incoming SPD entry or just use only one
> interface for all incoming SPD entries ?

Well, IMHO the best way would be to have a separate interface
for each tunnel end point.  That would allow most fine grained
control, and would be easiest to understand.

Perhaps something like the following:

   ifconfig enc0 up
   ifconfig enc0 192.168.0.129 netmask 255.255.255.0
   ifconfig xl1  192.168.0.130 netmask 255.255.255.128

   setkey -c << EOF
   spdadd 192.168.0.0/24   192.168.0.128/25 any -P in
          ipsec esp/tunnel/XXX-YYY/require;
   spdadd 192.168.0.128/25 192.168.0.0/24   any -P out
          ipsec ESP/tunnel/YYY-XXX/require;
   EOF

Even better would be if you could use just on IP address
instead of having a separate address at the tunnel
interface and another one at the internal network interface,
but I'm not sure if that would work.

When IPsec is not used or properly configured, the enc
interface could be just a black hole, discarding any
packets that are not processed and tunneled by IPsec.

With the received packets, the IPsec code would need to
go through the configured enc interfaces, and find one
where the source address would match...

Now, all this has one not-so-good design aspect:  in a way
you need to configure the tunnel twice: once the enc
interface, IP addresses and routing etc, and a second time
set up the proper IPsec SPD entries.  Perhaps the enc
interface could be even more intelligent, and set up default
SPD entries based on routing tables???

--Pekka Nikander


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E15604B.3040505>