Date: Mon, 16 Apr 2001 12:14:05 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Brian Candler <B.Candler@pobox.com> Cc: Lowell Gilbert <lowell@world.std.com>, Rasputin <rara.rasputin@virgin.net>, freebsd-security@FreeBSD.ORG Subject: Re: Interaction between ipfw, IPSEC and natd Message-ID: <200104161914.f3GJEMh06453@cwsys.cwsent.com> In-Reply-To: Your message of "Mon, 16 Apr 2001 11:23:58 BST." <20010416112358.A13561@linnet.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010416112358.A13561@linnet.org>, Brian Candler writes: > > Some forms of IPSEC have fundamental problems with packet rewriting, > > which means that NAT is extremely hard to use in an IPSEC environment. > > Notably, end-to-end IPSEC modes are broken, although router-based > > tunnels can be a problem depending on whether the NAT rewriting occurs > > before or after the IPSEC headers are applied. > > > > Even without NAT, though, firewalls are a little tricky to configure > > for IPSEC packets. This is because the firewall can't see the > > protocol ports (or even the protocol, for that matter) in the packet, > > Ah, it seems I wasn't clear :-) It's actually a very simple scenario, and I > do not need IPSEC packets to be routed through the firewall at all. There > are cleartext sessions which need NAT to be able to browse the outside > Internet, and then cleartext packets which are IPSEC-tunnelled from one > private network to another, like this: > > Internet Internet > ^ . . . . . . . . . . ^ > | , IPSEC tunnel ` | > +----------+ +----------+ > | Firewall | | Firewall | > +----------+ +----------+ > | | > ---+--- ---+--- > Office1 Office2 > 10.0.1.0/24 10.0.2.0/24 > > Now, I have done a bit of experimentation and found the following. > > 1. Packets which are diverted to natd are reinjected into the ipfw ruleset > at the following rule (actually 'man 8 natd' does say this). The packets > do retain their 'in via <interface>' tag. 'man 4 divert' documents the > mechanism which makes this possible. > > 2. Incoming IPSEC packets pass _twice_ through the ipfw rules: once in > their encapsulated form (protocol 50), and when decrypted they pass > through the whole ruleset again, retaining their 'in via <interface>' tag. > > The second rule makes things a bit of a mess. For starters, you need two > rules to permit IPSEC traffic through, one in encrypted and one in decrypted > form: > > add 1000 allow esp from <tunnel-rem> to <tunnel-local> in via fxp0 > add 1010 allow ip from 10.0.1.0/24 to 10.0.2.0/24 in via fxp0 > > Now, it seems ipfw cannot tell the difference between a packet which came > 'in via fxp0' in the clear, or 'in via fxp0' as IPSEC which was successfully > decrypted and authenticated. > > It is not clear what happens if someone spoofs a packet with a 10.0.x source > and dest address and injects it into the outside interface of the firewall; > hopefully the IPSEC policy (/require) catches this case and drops the > packet, but I would feel much happier with an explicit ipfw antispoofing > rule. I've noticed this with IP Filter as well. For applications where this is a critical issue, I use the pipsecd port, allowing me to filter on the external interface (xl0, fxp0, etc), e.g. AH and ESP, and the tun(4) interface that pipsecd is attached to, e.g. TCP, UDP, ICMP. I realise that this was discussed on this list within the past 6 months and that one the KAME developers (KAME is obviously IPv6 focused) indicated that IPv6 addressing would not allow for IPSec packets being filtered on an interface because IPv6 addresses span all interfaces. (I realise I'm not quoting this exactly, or may have even got the quote completely wrong however that's what it boils down to IPv4 users trying to use KAME IPSec). As far as solutions go, I don't have one, other than continue to use pipsecd for situations that need this kind of filtering. Just sort of thinking out loud here, would some kind of daemon (or other facility), that would attach itself to a tun(4) (or other) interface, like pipsecd does, but use the kernel's IPSec facility to encrypt and encapsulate the packets instead of its own, then inject them into the external interface be of use? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC 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?200104161914.f3GJEMh06453>