Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Mar 2024 21:27:19 -0400
From:      "Wesley Aptekar-Cassels" <me@wesleyac.com>
To:        "Lexi Winter" <lexi@le-fay.org>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Filtering incoming WireGuard traffic with pf?
Message-ID:  <12846907-f22f-4bc3-bde9-5fef439d0a36@app.fastmail.com>
In-Reply-To: <ZfbOXkpUAyubL_IT@ilythia.eden.le-fay.org>
References:  <6aee40eb-d7ac-4163-93a9-ae746da65c82@app.fastmail.com> <ZfbOXkpUAyubL_IT@ilythia.eden.le-fay.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 17, 2024, at 7:05 AM, Lexi Winter wrote:
> 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.

Indeed, this was it, thanks. I was confused because I did have the same pf
configuration on both machines, but I must have pinged them both from each
other via the wireguard IPs, so each one was allowing traffic from the other as
return traffic.

I now have the following pf rule added, and everything works as expected:

pass in on $ext_if proto udp from X.X.X.X to ($ext_if) port 51820

Thanks for the help!

:w



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12846907-f22f-4bc3-bde9-5fef439d0a36>