Date: Tue, 19 Nov 2002 16:24:56 +0100 (CET) From: "Patrick M. Hausen" <hausen@punkt.de> To: Guido van Rooij <guido@gvr.org> 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: <200211191524.gAJFOurn016546@hugo10.ka.punkt.de> In-Reply-To: <20021119150826.GA42097@gvr.gvr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ;-))
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.
Regards,
Patrick M. Hausen
Technical Director
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Scheffelstr. 17 a Tel. 0721 9109 -0 Fax: -100
76135 Karlsruhe http://punkt.de
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?200211191524.gAJFOurn016546>