Date: Tue, 19 Nov 2002 20:00:12 +0100 From: Guido van Rooij <guido@gvr.org> To: "Patrick M. Hausen" <hausen@punkt.de> Cc: David Kelly <dkelly@HiWAAY.net>, Scott Ullrich <sullrich@CRE8.COM>, 'Archie Cobbs' <archie@dellroad.org>, "'greg.panula@dolaninformation.com'" <greg.panula@dolaninformation.com>, FreeBSD-stable@FreeBSD.ORG Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? Message-ID: <20021119190012.GD43039@gvr.gvr.org> In-Reply-To: <200211191524.gAJFOurn016546@hugo10.ka.punkt.de> References: <20021119150826.GA42097@gvr.gvr.org> <200211191524.gAJFOurn016546@hugo10.ka.punkt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 19, 2002 at 04:24:56PM +0100, Patrick M. Hausen wrote:
> Hello!
>
> Guido wrote:
>
> > > The problem is that while ESP packets arrive to be processed by
> > > IPsec just fine thru my ipfw rules, when the packets are de-encrypted
> > > and re-inserted into the kernel they appear to ipfw to be coming from
> > > my external interface (the one they arrived on via ESP). tcpdump can't
> > > find them (decrypted) on the external interface.
> >
> > THe reason tcpdump cannot find them on the external interface is because
> > they are coming out of your gif interface. In case ipfw thinks they are coming
> > from your physical external interface, ipfw has a bug that needs to be fixed.
>
> I had exactly the same problem a while ago, when I implemented
> a VPN/firewall setup for two offices of one of our customers.
> This was around the time of 4.4-RELEASE.
>
> ESP packets arrive on external interface and get passed to ipfw
> - so far so good. I had a rule that skipped diverting to natd
> for ESP - worked, too.
>
> Then the packet gets decrypted and reinserted into the ipfw chain
> rule chain again. And - this is what complicated matters immensely
> - the packet is still being flagged as coming from the external
> network interface ("in via fxp0" for example) instead of coming
> from the gif interface ("in via gif0").
>
> This made it impossible to implement NAT, VPN _and_ filtering
> on one box, since you could not use anti-spoofing rules
> ("deny from rfc1918 to any in via external_if"). The decrypted
> packets were coming with source and destination from private
> address space, so you had to pass that and hope your ISP
> didn't have any holes allowing source routing or similar tricks.
>
> After talking to Luigi on BSDCon Europe 2001 I ended deploying
> two boxes per side. External one in bridge mode doing the filtering
> and internal one in router mode doing VPN and NAT.
> So I could configure rather faschist packet filters on the outside
> and then safely assume "everything coming in will be OK" on the
> inside box.
> Used PCs were cheap and from the talk with Luigi I got the
> impression that there was a design issue that made it
> impossible to have the packets appear to be coming "in via gif0".
>
> Now you tell it may be a bug in ipfw - finally there's a light ;-))
Yes, I think there is a problem here in the ipfw code.
Let's examine the GIF/ESP setup people described here.
Let's examine the following situation:
interfaces: fxp0, gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 192.168.100.1 --> 192.168.100.2
inet 10.0.0.1 --> 10.0.1.1 netmask 0xffffff00
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
Then suppose I have ESP betwee 10.0.0.1 and 10.0.1.1.
When I sent a packet to 10.0.1.1, the following happens:
An IP packet is generated, then a new IP header gets added by gif0,
then it is encrypted and finally it is sent out.
When a packet is received, it is first decrypted, then fed into the gif
device and the resulting IP packet gets processed again by ip_input().
I suspect that ipfw somehow records the incoming interface, but never resets
it to gif0 when it hits the gif device. I think ipfw should use the
'normal' way of determening the interface, which is to inspect
m->m_pkthdr.rcvif.
If it doesn't inspect this but adds its own rcvif pointer somewhere, it
should reset this pointer whenever a subprotocol handler (e.g. gif for
IP in IP packets) is called. Basically a packet coming out of such an
interface is to be treated as any other packet entering the system.
That is also the reason that the gif device sets m->m_pkthdr.rcvif
to be the particular device instance the packet arrived on and puts
the packet on the ipintrq like any other driver for a physical interface
would do.
>
> I always envied Linux users with Free/SWAN, since they seem
> to have decrypted ESP packet payload coming from interface
> "ipsec0" or similar and can tune their firewall rules accordingly.
Which is also bad because you have no clue on which real interface the
packets came from.
-Guido
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021119190012.GD43039>