From owner-freebsd-pf@freebsd.org Tue Mar 21 09:26:45 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 BD917D14DA6 for ; Tue, 21 Mar 2017 09:26:45 +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 87DA2D30 for ; Tue, 21 Mar 2017 09:26:45 +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 A96631EC60; Tue, 21 Mar 2017 10:26:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1490088403; bh=R8R7xZeACqsNdWlqEgUo9JLY8mjbuGcZnLzVBBxBOSo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=vPOAbuFqehjg59m1SzPI0cS7RAKcBojMuOa23pxc2wLoQPvo4gt6t61iNKkwkP1PW TLQGBf790XkgwPebvZ1MKVjQtl8E9nggm8YqeNlkAea3GAXIH04fX4v/kIvXOovb3X F+yILSxXo+OGCmUNoaMq56M/18XbRF1a/xzXDd/0= From: "Kristof Provost" To: "Marin Bernard" Cc: freebsd-pf@freebsd.org Subject: Re: Support for the enc(4) pseudo-interface Date: Tue, 21 Mar 2017 10:18:36 +0100 Message-ID: <44FBCEF5-6151-46FF-A166-81E7306914CC@sigsegv.be> In-Reply-To: <1490085811-bc1aa9c7b83aeddb9dee198bc4071b35@olivarim.com> References: <1490085811-bc1aa9c7b83aeddb9dee198bc4071b35@olivarim.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed 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 09:26:45 -0000 On 21 Mar 2017, at 9:43, Marin Bernard wrote: > Thanks for answering. Yes, I know that pf accepts rules mentioning > inexistent > interfaces. What puzzles me here is that my ruleset is actually > working. > With peer0 = 1.2.3.4 and peer1 = 5.6.7.8, the following ruleset works > as > expected: > > ----- > peers = "{1.2.3.4, 5.6.7.8}" > > set skip on lo > block all > > # Allow IKE > pass  in proto {tcp, udp} from $peers to self   port isakmp > pass out proto {tcp, udp} from self   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. > 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. Regards, Kristof