Date: Mon, 18 Nov 2002 08:54:29 +0200 From: Ari Suutari <ari.suutari@syncrontech.com> To: greg.panula@dolaninformation.com, David Kelly <dkelly@HiWAAY.net> Cc: FreeBSD-stable@FreeBSD.ORG Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? Message-ID: <200211180854.29349.ari.suutari@syncrontech.com> In-Reply-To: <3DD4F4D1.83C77B0@dolaninformation.com> References: <200211142157.57459.dkelly@HiWAAY.net> <3DD4F4D1.83C77B0@dolaninformation.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
=09I think that this is caused by changes in ip_input.c,
=09version 1.130.2.40:
"MFC: 1.214:
Get rid of checking for ip sec history. It is true that packets are not
supposed to be checked by the firewall rules twice. However, because the
various ipsec handlers never call ip_input(), this never happens anyway.
This fixes the situation where a gif tunnel is encrypted with IPsec. In
such a case, after IPsec processing, the unencrypted contents from the
GIF tunnel are fed back to the ipintrq and subsequently handeld by
ip_input(). Yet, since there still is IPSec history attached, the
packets coming out from the gif device are never fed into the filtering
This fix was sent to Itojun, and he pointed towartds
http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction.
This patch actually implements what is stated there (specifically:
Packet came from tunnel devices (gif(4) and ipip(4)) will still
go through ipf(4). You may need to identify these packets by
using interface name directive in ipf.conf(5)."
=09This means that packets decapsulated from ipsec
=09packets are passed again to ipfw rule processing.
=09Things used to be like this some releases ago.
=09Although this might break some rulesets I like it
=09since it gives better security for some of my cases.
=09
=09=09Ari S.
On Friday 15 November 2002 15:21, Greg Panula wrote:
> David Kelly wrote:
> > Ran cvsup this morning (11/14/2002), built world, installed world, bu=
ilt
> > and installed new kernel, forgot mergemaster, rebooted, and my VPN to
> > another FreeBSD box was not working. Did not update the other box.
> >
> > Discovered I had not done mergemaster on the problem box so did that
> > and rebooted again. Still have the same problem.
> >
> > What I have found is packets that are supposed to be on fxp0 are bein=
g
> > killed by ipfw for appearing on fxp1 by this rule. fxp1 is my exteral
> > NIC connected to the ISP:
> >
> > 00600 14 1122 deny ip from any to 10.0.0.0/8 via fxp1
> >
> > But if I add this rule in front of the above (so I don't have to rety=
pe
> > the above to add it back) then all is working as it once did:
> >
> > 00550 2 168 allow ip from 192.168.100.0/24 to 10.0.0.0/24 in recv
> > fxp1
> >
> > The above are prior to my divert rule.
> >
> > Much later in my ruleset (after divert to natd) I was allowing these
> > packets via fxp0, the internal interface. Some are still going that w=
ay.
> >
> > The distant end is still 4.6-STABLE and shares practically the same
> > ipfw ruleset and everything. Rule 600 doesn't cause a problem there.
> > Wasn't a problem before the latest update for 4.7-stable.
> >
> > No doubt I'm lost as to how IPsec packets traverse thru these layers.
> > When setting the system up was surprised to find nothing came thru
> > gif0. At least nothing ipfw sees.
> >
> > --
> > David Kelly N4HHE, dkelly@hiwaay.net
>
> gif tunnels aren't really needed for passing IPSec traffic between
> locations. I have stopped using them.
>
> You might try adding an allow rule for esp traffic just before your rul=
e
> 600.
>
> Something like:
> ipfw add 550 allow esp from <local> to <remote> out via fxp1
> ipfw add 555 allow esp from <remote> to <local> in via fxp1
> or
> ipfw add 550 allow esp from any to any via fxp1
>
> If you are using gif tunnels for passing your ipsec traffic thru you
> might want to try not using them. I ran into some similar funkyness a
> while back. Packets traverse the gif tunnel, get decrypted and then ge=
t
> rejected by the firewall rules for the external interface.
>
> If you would like a quickie example of ipsec tunnel setup between two
> freebsd boxes, let me know.
>
> Sorry, I couldn't really answer why you're setup doesn't work after
> upgrading to 4.7.
>
> greg
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
--=20
Ari Suutari / Syncron Tech Oy
Lappeenranta, Finland
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?200211180854.29349.ari.suutari>