Date: Fri, 3 Jan 2003 12:24:34 +0100 From: Paul Schenkeveld <fb-net@psconsult.nl> To: Pekka Nikander <pekka.nikander@nomadiclab.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change Message-ID: <20030103122434.A16996@psconsult.nl> In-Reply-To: <3E15604B.3040505@nomadiclab.com>; from pekka.nikander@nomadiclab.com on Fri, Jan 03, 2003 at 12:04:59PM %2B0200 References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> <3E15604B.3040505@nomadiclab.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 03, 2003 at 12:04:59PM +0200, Pekka Nikander wrote: > 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. Because of the way IPsec and ipfw/ipfilter interact, I've moved to the following workaround: ifconfig fxp0 $my_internal netmask $my_internal_netmask ifconfig gif0 create \ tunnel $my_external $peer_external \ $my_internal $peer_external Now I use transport mode instead of tunnel mode between the two external IP addresses: setkey -c << EOF add $my_external $peer_external ah spi1 -A hmac-md5 key1; add $peer_external $my_external ah spi2 -A hmac-md5 key2; add $my_external $peer_external esp spi3 -E blowfish-cbc key3; add $peer_external $my_external esp spi4 -E blowfish-cbc key4; spdadd $my_external $peer_external ipencap -P out ipsec esp/transport/$my_external-$peer_external/require ah/transport/$my_external-$peer_external/require; spdadd $peer_external $my_external ipencap -P in ipsec esp/transport/$peer_external-$my_external/require ah/transport/$peer_external-$my_external/require; EOF The 'ipencap' in the spadd lines causes only traffic in the gif tunnel to be affected by IPsec, you could also use 'any' here to encrypt/sign all traffic. Now all tunnel traffic (in and out) passed gif0 where I can use ipfw and/or ipfilter. Although this is not the solution to your problem, it shows a behaviour close to what you want I think. I'd love to see ipsec evolve in a way that I don't need gif tunnels anymore so I like the enc0 interface concept but then I'd suggest that IPsec automagically create route entries from the spadd lines such that also outbound traffic passes enc0. > 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 -- Paul Schenkeveld, Consultant PSconsult ICT Services BV 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?20030103122434.A16996>