Date: Fri, 03 Jan 2003 13:36:28 +0200 From: Pekka Nikander <pekka.nikander@nomadiclab.com> To: Paul Schenkeveld <fb-net@psconsult.nl> Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change Message-ID: <3E1575BC.6000001@nomadiclab.com> In-Reply-To: <20030103122434.A16996@psconsult.nl> References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> <3E15604B.3040505@nomadiclab.com> <20030103122434.A16996@psconsult.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Schenkeveld wrote: > Because of the way IPsec and ipfw/ipfilter interact, I've > moved to the following workaround: ... > Now I use transport mode instead of tunnel mode between the two > external IP addresses: ... > Although this is not the solution to your problem, it shows a > behaviour close to what you want I think. Thanks for the suggestion, but I'm afraid that it won't work for me. Namely, my ISP has a NAT box between my home server and the rest of the internet. Fortunately I do have a permanent one-to-one mapping at the NAT box so that I can run ESP over it, and with manually set up tunnel ESP it works. Not nice, but it works. I'm afraid transport mode wouldn't work, but maybe I should try it. > 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. I think that generating routing table entries from SPD is probably a better idea than my original idea of doing it the other way around. I think that it would be even possible to do that in the user land, having some process listening to a PFKEY socket and adding and deleting routes as it sees tunnel mode SPD entries coming and going. --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?3E1575BC.6000001>