On Wed, May 19, 2021 at 12:30:27PM +0100, Stuart Henderson wrote:
> Understood why, but I think wireguard is a special case, normally
> maintaining a nat mapping across a change of address doesn't help as the
> system at the other side won't associate it with the same "connection". The
> () behavio
Understood why, but I think wireguard is a special case, normally
maintaining a nat mapping across a change of address doesn't help as the
system at the other side won't associate it with the same "connection". The
() behaviour relates to the address at state creation, there's no mechanism
to d
Thanks Alexandr and Stuart for your replies. I categorized this as a
bug in my head, because of (umb0) vs umb0 usage in my pf rules:
pce-0035# diff -u pf.conf-t1 pf.conf
--- pf.conf-t1 Wed May 19 07:45:27 2021
+++ pf.confThu Mar 4 19:34:25 2021
@@ -6,7 +6,7 @@
queue q_umb0 on umb0 flo
This can happen with any long lived UDP-based protocol that is natted to a
dynamically configured address. I think this is not a bug; PF is doing
exactly what you have asked it to.
The issue is that you're sending packets frequently (due to the fairly low
keepalive timer) which refreshes the P
Hello Mikolaj,
> ...
>
> >How-To-Repeat:
> Setup NAT with PF, connect wireguard client over internal
> network, which goes over external interface which changes IP address
> once in a while, in my case it's umb(4).
>
> >Fix:
> Unknown. Many workarounds, pfctl -Fs, seems the simplest
>Synopsis: wireguard traffic blackholed after umb(4) changes ip addr
>Category: kernel
>Environment:
System : OpenBSD 6.9
Details : OpenBSD 6.9-current (GENERIC.MP) #14: Tue May 11 18:41:12
UTC 2021
r...@pc1.home.local:/home/mkucharski/openbsd/src
Forgot to also show PF rules:
pce-0035# grep -ve '^$' -e '^#' /etc/pf.conf
set skip on lo
set limit states 25000
queue q_umb0 on umb0 flows 1024 qlimit 50 quantum 300 default
queue q_athn0 on athn0 flows 1024 qlimit 100 quantum 300 default
match out on umb0 inet from !(umb0) nat-to (umb0:0)
match
