From owner-freebsd-pf@freebsd.org Tue Mar 21 12:22:25 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0F17D14A5C for ; Tue, 21 Mar 2017 12:22:25 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B3EFD12 for ; Tue, 21 Mar 2017 12:22:25 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from [172.19.248.15] (unknown [104.153.224.169]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id B35D71EF17; Tue, 21 Mar 2017 13:22:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1490098943; bh=TpuLKZ2LJUubAoCEM/ixJeokD89CR9/abzkVWPhtCf4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=nm7S5HvE7220c0IOE3h2wIV50mGzDXXKF4VSQ6D6TX1Pfsh78IxQYLDMoxotu92Ph PGms3ZaPFWBGrGpoHAEf8lN5mwqjM4obOSZdnhmy59SlcO5Nq99wQwMwSfiCnKE5xX FQW61AKAorYkaXU9DHILw6gURch5Dd2MMDqUwPPw= From: "Kristof Provost" To: "Miroslav Lachman" <000.fbsd@quip.cz> Cc: "Marin Bernard" , freebsd-pf@freebsd.org Subject: Re: Support for the enc(4) pseudo-interface Date: Tue, 21 Mar 2017 13:22:01 +0100 Message-ID: In-Reply-To: <58D11201.1000403@quip.cz> References: <1490085811-bc1aa9c7b83aeddb9dee198bc4071b35@olivarim.com> <44FBCEF5-6151-46FF-A166-81E7306914CC@sigsegv.be> <58D11201.1000403@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6080) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 12:22:25 -0000 On 21 Mar 2017, at 12:44, Miroslav Lachman wrote: > Kristof Provost wrote on 2017/03/21 10:18: >> On 21 Mar 2017, at 9:43, Marin Bernard wrote: > >>> If there is no SA, it is impossible for a peer to ping another. As >>> soon >>> as IKE creates a SA, however, ping starts working. As you can see, >>> the last rule is explicitely bound to the inexistent enc0 interface, >>> and >>> yet is working fine. >>> >> Can you try without the enc0 rule? I suspect that what’s happening >> here >> is that >> the IPSec traffic is bypassing the firewall altogether. If that's the >> case the >> your traffic will still flow, even without the pass on enc0 rule. >> >> If you want to filter on it it should work if you add ‘device >> enc’ to your >> kernel config. The man page suggests that should then allow you to >> filter IPSec >> traffic on enc0. > > Shouldn't it be included in GENERIC if IPSec is now part of it? It > seems > illogical to build own kernel for IPsec if IPSec was included in > GENERIC for > 11.0 ... but without enc. > Yeah, perhaps it should be. I’ve not used it myself, so I don’t know if/how well it works now, but unless it breaks things or introduces significant performance regressions we should probably turn it on too. Martin, could you give us an idea of how well this works for you when you’ve got the time to set it up? Regards, Kristof