From nobody Sun Mar 17 11:05:02 2024 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TyFWQ42J9z5CtDK for ; Sun, 17 Mar 2024 11:05:06 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from thyme.eden.le-Fay.ORG (THYME.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:107::10]) by mx1.freebsd.org (Postfix) with ESMTP id 4TyFWP6M28z4PBc for ; Sun, 17 Mar 2024 11:05:05 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=le-fay.org header.s=thyme header.b=gvj3qz4I; dmarc=none; spf=pass (mx1.freebsd.org: domain of lexi@le-fay.org designates 2001:8b0:aab5:107::10 as permitted sender) smtp.mailfrom=lexi@le-fay.org Received: from iris.eden.le-Fay.ORG (IRIS.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:106:3::6]) by thyme.eden.le-Fay.ORG (Postfix) with ESMTP id A002C5C; Sun, 17 Mar 2024 11:05:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=thyme; t=1710673500; bh=iFu02rqjK3OLz2yUqL1Xm0Y7HV1E/cf3119bbWix9AY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gvj3qz4IDRDTuevBrXMvgK3L9RuPFSrYwiVDtqF8veB1uP4lygh4AlLsC5EO/3mP+ 2omC+8Chnwt7i8Ix8jM+DsRTchX94lPtqiJSCS7mgj3zq3y5aGrypc05ThlB9Nwm8V bzCLLlJkItaRkRPTk08HxOMzDuhem+tmwGfdc2XM= Received: from ilythia.eden.le-fay.org (ILYTHIA.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 7D4712C0418; Sun, 17 Mar 2024 11:05:02 +0000 (GMT) Date: Sun, 17 Mar 2024 11:05:02 +0000 From: Lexi Winter To: Wesley Aptekar-Cassels Cc: freebsd-questions@freebsd.org Subject: Re: Filtering incoming WireGuard traffic with pf? Message-ID: Mail-Followup-To: Wesley Aptekar-Cassels , freebsd-questions@freebsd.org References: <6aee40eb-d7ac-4163-93a9-ae746da65c82@app.fastmail.com> List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4ZUWtRzuNCcDapq3" Content-Disposition: inline In-Reply-To: <6aee40eb-d7ac-4163-93a9-ae746da65c82@app.fastmail.com> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.50 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2001:8b0:aab5:107::10]; R_DKIM_ALLOW(-0.20)[le-fay.org:s=thyme]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; DMARC_NA(0.00)[le-fay.org]; DKIM_TRACE(0.00)[le-fay.org:+]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:20712, ipnet:2001:8b0::/32, country:GB]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org]; DWL_DNSWL_NONE(0.00)[le-fay.org:dkim]; RCVD_IN_DNSWL_NONE(0.00)[2001:8b0:aab5:107::10:from] X-Rspamd-Queue-Id: 4TyFWP6M28z4PBc --4ZUWtRzuNCcDapq3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Wesley Aptekar-Cassels: > The relevant section of my /etc/pf.conf is: >=20 > ``` > ext_if =3D "vtnet0" > wg_lan =3D "10.10.0.0/24" >=20 > set skip on lo > scrub in >=20 > nat on $ext_if from $wg_lan to any -> ($ext_if) >=20 > block in on $ext_if > pass out > ``` [...] > My expectation was that `block in on $ext_if` would block WireGuard traff= ic and > that I'd need a `pass in on $ext_if proto udp to ($ext_if) port 51820` li= ne in > order to enable it, but my WireGuard tunnel works even without that, which > makes it seem to me that the decapsulation of the WireGuard traffic happe= ns > before it hits pf. that shouldn't be the case; it's not like IPsec where decryption happens in a way which is a bit magical. =20 what's likely going on here is that your local machine (the one running pf) is creating an outgoing connection to the Wireguard peer, which pf allows because of the 'pass out' rule. then because pf keeps state by default, the return traffic is also allowed, and there's no need for an incoming rule. you could test this by blocking traffic on the Wireguard port on both ends of the tunnel; that should prevent the Wireguard connection from coming up at all. however, you'll need to disable both ends of the peers for a few minutes before testing, to make sure any existing pf state has expired. in practice, although Wireguard will work this way (with incoming traffic blocked on one end), it's still better to allow incoming traffic on both ends of the tunnel so that either machine can initiate the connection. --4ZUWtRzuNCcDapq3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmX2zlsACgkQDHqbqZ41 x5la4Av/Z+ds7B2q0CXqCygz7c0hwajIpgTw67GdEvbHrtfXtQM7xPU4oY8PnllH o4PFGdqsxvZzTBJER0GbtwxC8Y+BTF0hwStS0bJ+SBrBTwTqVFciG9p/mCmotqIm DKV5ca1QTiboD/CNgotNLI2/gHSVD0RGA5lUjA3UsQrwL8hnb3N7y5HlL107ZRop 1fFktFpGVG7wyCjHbQHKBazhGWu1Z/9Ng2jwlT4a7gsZ4DE21WPkWMStWYzd57qo o7f2TaChXLNygS9wR2WKWF8vVRdhT/Sdu+yk2oy+bYhP5q7ecsyNq/J5D57Z4hIm UkDRImTzEUitN4uBByOwIm7oBpDUR70yNDpUac2zOuk2jzXZ/W/RDLO7cwkmz27A Vs+Sk2Hl0pUK3pvT2+CQOHYhUVxUxlms1uBTsJnxAd5TS6zmjkTFzLIXISKam4sq /+BJoJkGLcozB7ssfLK5RuGQKWA2em/0CFp9wtWBHn7T7HQXXzrD3gX1YhuDPG1d R5ivGFae =dEfE -----END PGP SIGNATURE----- --4ZUWtRzuNCcDapq3--