From owner-freebsd-pf@freebsd.org Tue Mar 21 08:47:10 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 53B3AD0A307 for ; Tue, 21 Mar 2017 08:47:10 +0000 (UTC) (envelope-from lists@olivarim.com) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.infomaniak.ch", Issuer "StartCom Class 3 OV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5DE5643 for ; Tue, 21 Mar 2017 08:47:08 +0000 (UTC) (envelope-from lists@olivarim.com) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v2L8hq6R020505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 21 Mar 2017 09:43:53 +0100 Received: from webmail.infomaniak.ch ([10.4.23.106]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v2L8hq0I017937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 21 Mar 2017 09:43:52 +0100 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2017 09:43:31 +0100 From: "Marin Bernard" To: "Kristof Provost" Cc: freebsd-pf@freebsd.org X-Webmail2-User: MTAwMzg Reply-To: lists@olivarim.com Subject: Re: Support for the enc(4) pseudo-interface Message-ID: <1490085811-bc1aa9c7b83aeddb9dee198bc4071b35@olivarim.com> X-Mailer: Infomaniak Webmail X-Origin: Y8xgjoznB//SMiGKbu86tO+eL/TieqKX66IlzxJcW2Y MIME-Version: 1.0 X-Priority: 3 (Normal) Content-Type: text/plain; charset="utf-8" X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 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 08:47:10 -0000 Hi, Thanks for answering. Yes, I know that pf accepts rules mentioning inexistent= =20 interfaces. What puzzles me here is that my ruleset is actually working.=20 With peer0 =3D 1.2.3.4 and peer1 =3D 5.6.7.8, the following ruleset works as= =20 expected: ----- peers =3D "{1.2.3.4, 5.6.7.8}" set skip on lo block all # Allow IKE pass=C2=A0 in proto {tcp, udp} from $peers to self=C2=A0=C2=A0 port isakmp pass out proto {tcp, udp} from self=C2=A0=C2=A0 to $peers port isakmp # Allow ICMPv4 echo requests only through IPsec pass in on enc0 proto icmp from $peers to self icmp-type echoreq ----- 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. Thanks, Marin. 21 mars 2017 03:30 "Kristof Provost" a =C3=A9crit: > On 20 Mar 2017, at 23:08, Marin Bernard wrote:=20 > > Yet, it appears that pf is able to handle references to enc(4) in its= =20 > > ruleset=20 > > even if the kernel does not support it. Is it expected behaviour? Is=20 > > it=20 > > safe to use such a configuration on a production machine ?=20 > >=20 > pf accepts rules for interfaces that don=E2=80=99t exist (yet), so this is= =20 > expected,=20 > but it won=E2=80=99t do what you want it to do.=20 >=20 > Regards,=20 > Kristof=20