From owner-freebsd-stable Tue Nov 19 13:19:55 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 549A237B401 for ; Tue, 19 Nov 2002 13:19:52 -0800 (PST) Received: from grumpy.dyndns.org (user-24-214-34-52.knology.net [24.214.34.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BF5643E97 for ; Tue, 19 Nov 2002 13:19:51 -0800 (PST) (envelope-from dkelly@grumpy.dyndns.org) Received: from grumpy.dyndns.org (localhost [127.0.0.1]) by grumpy.dyndns.org (8.12.6/8.12.6) with ESMTP id gAJLHggx065120; Tue, 19 Nov 2002 15:17:42 -0600 (CST) (envelope-from dkelly@grumpy.dyndns.org) Received: (from dkelly@localhost) by grumpy.dyndns.org (8.12.6/8.12.6/Submit) id gAJLHfji065119; Tue, 19 Nov 2002 15:17:41 -0600 (CST) Date: Tue, 19 Nov 2002 15:17:41 -0600 From: David Kelly To: Guido van Rooij Cc: Scott Ullrich , "'Archie Cobbs'" , "'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> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021119185535.GC43039@gvr.gvr.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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