From owner-freebsd-net@FreeBSD.ORG Sat Feb 22 22:48:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C7B4186 for ; Sat, 22 Feb 2014 22:48:03 +0000 (UTC) Received: from smtp.novso.com (smtp1.novso.com [193.189.104.85]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C4ED514F1 for ; Sat, 22 Feb 2014 22:48:02 +0000 (UTC) Message-ID: <1393109280.11968.3.camel@fr-wks3.corp.novso.com> Subject: Re: IPsec filtertunnel broken on FreeBSD 10 From: Nicolas DEFFAYET To: freebsd-net@freebsd.org Date: Sat, 22 Feb 2014 23:48:00 +0100 In-Reply-To: <5304DA80.6010403@yandex.ru> References: <1391725273.22934.16.camel@fr-wks3.corp.novso.com> <1392417340.10711.5.camel@fr-wks3.corp.novso.com> <52FEA4F5.5010702@yandex.ru> <52FEA5A2.3050106@yandex.ru> <1392641917.21759.1.camel@srv31.corp.novso.com> <53020F0F.9050809@yandex.ru> <1392648453.22762.2.camel@srv31.corp.novso.com> <5304DA80.6010403@yandex.ru> Organization: DEFFAYET.COM Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 22:48:03 -0000 On Wed, 2014-02-19 at 20:23 +0400, Andrey V. Elsukov wrote: Hello, After very long testing, i have discovered the route cause. Testing is not easy as there is a dependency between kernel and userland, it's not like on a Linux where the kernel is not depend of userland. Broken userland can generate false-positive result. The revision 254519 break the firewall with IPsec. http://svnweb.freebsd.org/base?view=revision&revision=254519 "Move the global M_SKIP_FIREWALL mbuf flags to a protocol layer specific flag instead. The flag is only used within the IP and IPv6 layer 3 protocols. Because some firewall packages treat IPv4 and IPv6 packets the same the flag should have the same value for both." It seem that some code doesn't have been updated for allow firewall to work with IPsec. FreeBSD 10.0-CURRENT #0 r254518 (10-userland) ------------------------------- # ipfw -a list 00010 6 326 allow log logamount 10000 tcp from 192.168.0.1 to 192.168.0.2 dst-port 22 via re0 in 00020 0 0 allow log logamount 10000 tcp from 192.168.0.2 to 192.168.0.1 dst-port 22 via re0 out 65535 5149 411660 allow ip from any to any => ipfw counters are ok for inbound Feb 22 22:16:44 host2 kernel: ipfw: 10 Accept TCP 192.168.0.1:51691 192.168.0.2:22 in via re0 => ipfw see the connection 22:18:16.127112 IP 192.168.0.1 > 224.0.0.5: OSPFv2, Hello, length 44 22:18:21.042325 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc15a), length 92 22:18:21.042548 IP 192.168.0.2 > 192.168.0.1: ESP(spi=0x00003039,seq=0x6), length 92 22:18:21.042785 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc15b), length 84 22:18:21.074818 IP 192.168.0.2 > 192.168.0.1: ESP(spi=0x00003039,seq=0x7), length 116 22:18:21.174651 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc15c), length 84 => traffic is encrypted by IPsec FreeBSD 10.0-CURRENT #0 r254519 (10-userland) ------------------------------- # ipfw -a list 00010 0 0 allow log logamount 10000 tcp from 192.168.0.1 to 192.168.0.2 dst-port 22 via re0 in 00020 0 0 allow log logamount 10000 tcp from 192.168.0.2 to 192.168.0.1 dst-port 22 via re0 out 65535 3132 249778 allow ip from any to any => ipfw counters are not increased! nothing in log => ipfw DO NOT see the connection! 22:22:05.890386 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc165), length 92 22:22:05.890565 IP 192.168.0.2 > 192.168.0.1: ESP(spi=0x00003039,seq=0x6), length 92 22:22:05.890793 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc166), length 84 22:22:05.922544 IP 192.168.0.2 > 192.168.0.1: ESP(spi=0x00003039,seq=0x7), length 116 22:22:06.022056 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc167), length 84 => traffic is encrypted by IPsec Many thanks -- Nicolas DEFFAYET