From owner-freebsd-pf@freebsd.org  Tue Mar 21 11:44:11 2017
Return-Path: <owner-freebsd-pf@freebsd.org>
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 B9552D16FBC
 for <freebsd-pf@mailman.ysv.freebsd.org>; Tue, 21 Mar 2017 11:44:11 +0000 (UTC)
 (envelope-from 000.fbsd@quip.cz)
Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 7E267F42
 for <freebsd-pf@freebsd.org>; Tue, 21 Mar 2017 11:44:10 +0000 (UTC)
 (envelope-from 000.fbsd@quip.cz)
Received: from elsa.codelab.cz (localhost [127.0.0.1])
 by elsa.codelab.cz (Postfix) with ESMTP id 8B1AF28485;
 Tue, 21 Mar 2017 12:44:02 +0100 (CET)
Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz
 [86.49.16.209])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by elsa.codelab.cz (Postfix) with ESMTPSA id 65B6328422;
 Tue, 21 Mar 2017 12:44:01 +0100 (CET)
Subject: Re: Support for the enc(4) pseudo-interface
To: Kristof Provost <kristof@sigsegv.be>, Marin Bernard <lists@olivarim.com>
Cc: freebsd-pf@freebsd.org
References: <1490085811-bc1aa9c7b83aeddb9dee198bc4071b35@olivarim.com>
 <44FBCEF5-6151-46FF-A166-81E7306914CC@sigsegv.be>
From: Miroslav Lachman <000.fbsd@quip.cz>
Message-ID: <58D11201.1000403@quip.cz>
Date: Tue, 21 Mar 2017 12:44:01 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101
 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <44FBCEF5-6151-46FF-A166-81E7306914CC@sigsegv.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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\)" <freebsd-pf.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-pf>,
 <mailto:freebsd-pf-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-pf/>
List-Post: <mailto:freebsd-pf@freebsd.org>
List-Help: <mailto:freebsd-pf-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
 <mailto:freebsd-pf-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 11:44:11 -0000

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.

Miroslav Lachman