From owner-freebsd-pf@freebsd.org Tue Mar 21 09:59:41 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 1B0ABD158C8 for ; Tue, 21 Mar 2017 09:59:41 +0000 (UTC) (envelope-from lists@olivarim.com) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 8F7F01C32 for ; Tue, 21 Mar 2017 09:59:40 +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 v2L9xbHI028829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 21 Mar 2017 10:59:37 +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 v2L9xbgc018866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 21 Mar 2017 10:59:37 +0100 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2017 10:59:16 +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: <1490090356-3beb99ed533c66a1f0fe54cca1460456@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 09:59:41 -0000 Hi again Kristof, It appears you were right. ICMP flows through even with no rule set. I'm afra= id I'll have to build a custom kernel. Thank you for your help, Marin. 21 mars 2017 10:18 "Kristof Provost" a =C3=A9crit: > On 21 Mar 2017, at 9:43, Marin Bernard wrote:=20 > > Thanks for answering. Yes, I know that pf accepts rules mentioning=20 > > inexistent=20 > > interfaces. What puzzles me here is that my ruleset is actually=20 > > working.=20 > > With peer0 =3D 1.2.3.4 and peer1 =3D 5.6.7.8, the following ruleset work= s=20 > > as=20 > > expected:=20 > >=20 > > -----=20 > > peers =3D "{1.2.3.4, 5.6.7.8}"=20 > >=20 > > set skip on lo=20 > > block all=20 > >=20 > > # Allow IKE=20 > > pass=C2=A0 in proto {tcp, udp} from $peers to self=C2=A0=C2=A0 port isak= mp=20 > > pass out proto {tcp, udp} from self=C2=A0=C2=A0 to $peers port isakmp= =20 > >=20 > > # Allow ICMPv4 echo requests only through IPsec=20 > > pass in on enc0 proto icmp from $peers to self icmp-type echoreq=20 > > -----=20 > >=20 > > If there is no SA, it is impossible for a peer to ping another. As=20 > > soon=20 > > as IKE creates a SA, however, ping starts working. As you can see,=20 > > the last rule is explicitely bound to the inexistent enc0 interface,=20 > > and=20 > > yet is working fine.=20 > >=20 > Can you try without the enc0 rule? I suspect that what=E2=80=99s happening= =20 > here is that=20 > the IPSec traffic is bypassing the firewall altogether. If that's the=20 > case the=20 > your traffic will still flow, even without the pass on enc0 rule.=20 > =20 > If you want to filter on it it should work if you add =E2=80=98device enc= =E2=80=99=20 > to your=20 > kernel config. The man page suggests that should then allow you to=20 > filter IPSec=20 > traffic on enc0.=20 > =20 > Regards,=20 > Kristof=20