Date: Sun, 17 Mar 2024 11:05:02 +0000 From: Lexi Winter <lexi@le-fay.org> To: Wesley Aptekar-Cassels <me@wesleyac.com> Cc: freebsd-questions@freebsd.org Subject: Re: Filtering incoming WireGuard traffic with pf? Message-ID: <ZfbOXkpUAyubL_IT@ilythia.eden.le-fay.org> In-Reply-To: <6aee40eb-d7ac-4163-93a9-ae746da65c82@app.fastmail.com> References: <6aee40eb-d7ac-4163-93a9-ae746da65c82@app.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZfbOXkpUAyubL_IT>