Date: Tue, 19 Nov 2002 15:17:41 -0600 From: David Kelly <dkelly@hiwaay.net> To: Guido van Rooij <guido@gvr.org> Cc: 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 packets seen on wrong interface by ipfw (was Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw?) Message-ID: <20021119211741.GA65003@grumpy.dyndns.org> In-Reply-To: <20021119185535.GC43039@gvr.gvr.org> References: <2F6DCE1EFAB3BC418B5C324F13934C9601D23C35@exchange.corp.cre8.com> <20021119110336.GA12956@gvr.gvr.org> <200211190754.29355.dkelly@HiWAAY.net> <20021119150826.GA42097@gvr.gvr.org> <20021119161129.GA63943@grumpy.dyndns.org> <20021119185535.GC43039@gvr.gvr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 19, 2002 at 07:55:35PM +0100, Guido van Rooij wrote:
> On Tue, Nov 19, 2002 at 10:11:29AM -0600, David Kelly wrote:
> >
> > At some point since early October when this system was previously
> > updated these IPsec packets started appearing on the wrong interface in
> > ipfw. Currently only one end of my link is updated, the other end is
> > running with the same configuration it has used for the past 9 months.
> > With configured (but apparently unused) gif and everything.
>
> What do you mean with wrong interface?
I have de-tunneled packets with address in 192.168.100.0/24 seemingly
being delivered to 10.0.0.0/24 on my external public interface. Or at
least according to ipfw. By blocking these packets from my external
interface my VPN does not work. Making a pinhole in the firewall allows
the VPN tunnel between two private nets to operate.
The Big Issue is that it requires a pinhole in my firewall rules. A new
pinhole which was not required in early October. Or the 9 months prior.
> What I did was remove the ipsec history check in ip_input().
> What happens in you case is that ip packet come in, are fed into
> ipfw, then they are decrypted in esp_input() and then fed into the
> ip subprotocol directly from esp_input(). The code I removed
> only appears in the first call to ip_input(), but the code would not
> have any effect in that case.
>
> The only way that this removal could have an effect is when esp_input()
> called xxx_input() which in turn calls ip_input() again.
> Since you are not using a tunneling device, this does not happen.
I don't know what the difference is between gif tunnel and an IPsec
tunnel as created with this (real addresses removed) /etc/ipsec.conf:
flush;
spdflush;
spdadd 10.0.0.253/24 192.168.100.253/24 any -P out ipsec
esp/tunnel/24.xx.xx.xx-24.yy.yy.yy/require ;
spdadd 192.168.100.253/24 10.0.0.253/24 any -P in ipsec
esp/tunnel/24.yy.yy.yy-24.xx.xx.xx/require ;
And once again this is a snapshot of the start of my ipfw list, up to
divert, where I was trapping for bad addresses but have had to add
line 550 to allow my VPN traffic. Rule 600 got a couple hits after
reboot before I manually re-added 550:
00100 1394 292206 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any
00400 0 0 deny ip from 10.0.0.0/24 to any in recv fxp1
00500 0 0 deny ip from 24.xx.xx.0/24 to any in recv fxp0
00550 3378 499132 allow ip from 192.168.100.0/24 to 10.0.0.0/24 in recv fxp1
00600 83 6972 deny ip from any to 10.0.0.0/8 via fxp1
00700 0 0 deny ip from any to 172.16.0.0/12 via fxp1
00800 327 27468 deny log ip from any to 192.168.0.0/16 via fxp1
00900 0 0 deny ip from any to 0.0.0.0/8 via fxp1
01000 0 0 deny ip from any to 169.254.0.0/16 via fxp1
01100 0 0 deny ip from any to 192.0.2.0/24 via fxp1
01200 0 0 deny ip from any to 224.0.0.0/4 via fxp1
01300 400 131200 deny ip from any to 240.0.0.0/4 via fxp1
01400 200895 106311298 divert 8668 ip from any to any via fxp1
OK, there there is a new one at line 800. Apparently a 2-ping per minute
health monitor I have running on the VPN host is being blocked but when
the ping originates inside the 10.0.0.0/24 net it gets thru. 10.0.0.8
can ping 192.168.100.50 but the host which tunnels to the remote 192 net
can not.
Others report the version prior to this restores proper operation. I'll
try it soon. I've used up my reboot quota today:
* $FreeBSD: src/sys/netinet/ip_input.c,v 1.130.2.41 2002/11/10 13:10:39 maxim Exp $
What ever is going on the above change seems to have unintended
consequences.
I believe in this lengthy discussion we have concluded that packets
emerging from a tunnel should not appear as if they came from the
interface said tunnel is routed thru?
And that packets emerging from a tunnel should not necessarily be
subject to ipfw at all unless a tunnel device such as gif was used? If
the de-tunneled packets leave the machine via an interface then ipfw
applies as always on that interface.
--
David Kelly N4HHE, dkelly@hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.
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?20021119211741.GA65003>