On 2026-04-17 14:17, Henning Brauer wrote:
* Atanas Vladimirov <[email protected]> [2026-04-16 14:25]:
When you restart the VM the tapX device get deleted/destroyed and all
pf
rules (related to it) are gone too.
doesn't compute; that is simply not how pf works.
when it comes to interfaces, there are mostly 2 relevant cases: rules
bound to interfaces (or groups), i. e. "on tapX", and an interface
(group) name used in place of IP addresses, i. e. "to tapX" or "to
(tapX)".
for rules bound to interfaces, there is an abstraction. when the
interface the rule refers to goes away the rule will just not match
anything, and when the interface (re-)appears it is attached again and
everything works like before.
for interface names resolving to IPs, the "to tapX" form is resolved
at ruleset load time and won't change until you reload, with the
interface name resolving to the IP(s) the interface has at that very
same moment. In the "to (tapX)" form the resolution is dynamic and
updated every time the interface changes.
it is pretty much the same for interface groups; there was a
long-standing bug with rules being bound to an interface group, say
"tap", and newly arriving tapX interfaces part of that group not being
seen as such by pf - but I fixed that some years ago.
Hey Henning,
Thanks for your explanation! It made me dig deeper into my issue.
Maybe now is a good time to say that I do not want to hijacking the
thread of the OP.
I run -current many years now and I have an Alpine VM on which I run
some docker containers.
I have a bridge:
```
[hodor]~$ ifconfig bridge0
bridge0: flags=41<UP,RUNNING> mtu 1500
description: switch1-uplink
index 11 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto
rstp
designated: id 00:00:00:00:00:00 priority 0
tap0 flags=3<LEARNING,DISCOVER>
port 24 ifpriority 0 ifcost 0
em1 flags=3<LEARNING,DISCOVER>
port 4 ifpriority 0 ifcost 0
vether6 flags=3<LEARNING,DISCOVER>
port 17 ifpriority 0 ifcost 0
vether0 flags=3<LEARNING,DISCOVER>
port 15 ifpriority 0 ifcost 0
Addresses (max cache: 100, timeout: 240):
b4:e3:f9:d9:f0:6d em1 1 flags=0<>
60:01:94:70:23:64 em1 0 flags=0<>
b4:e3:f9:d6:21:43 em1 1 flags=0<>
54:32:04:40:81:1c em1 1 flags=0<>
48:26:4c:44:51:8a em1 1 flags=0<>
00:93:37:95:05:0b em1 1 flags=0<>
c8:d7:78:fe:a9:c8 em1 1 flags=0<>
cc:86:ec:b0:ba:75 em1 1 flags=0<>
dc:a6:32:49:0c:af em1 1 flags=0<>
08:5b:d6:0d:43:dc em1 1 flags=0<>
5c:33:7b:f1:46:47 em1 1 flags=0<>
04:f4:d8:32:c0:ce em1 1 flags=0<>
64:c6:d2:5b:03:fb em1 1 flags=0<>
fe:e1:ba:d2:02:32 tap0 1 flags=0<>
c8:bf:4c:8c:40:74 em1 1 flags=0<>
f4:91:1e:30:f6:38 em1 0 flags=0<>
32:1c:8d:f2:7e:f3 em1 1 flags=0<>
```
and pf.conf I have `set skip on { lo, em0, em1, em2, em3, em4, em5, tap
}`
Inside the VM I have:
```
# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
```
And when I do a `reboot` on the VM, I have to run `pfctl -f
/etc/pf.conf`
once the VM is back up so its network works again.
And because I need to reboot the VM very rare (I reboot the host more
often,
when I upgrade to a recent snapshot) I never spend much time on what is
going on :).
So, now I have rebooted the VM and start playing with it.
The first thing I noticed is that the dhcp client can't get lease from
the dhcpd:
```
tcpdump on the tap0 device
--------------------------
16:42:03.905226 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x79b98b39 [|bootp] (ttl 64, id 0, len 328)
16:42:03.905247 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x79b98b39 [|bootp] (ttl 64, id 0, len 328)
16:42:07.034073 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x79b98b39 secs:3 [|bootp] (ttl 64, id 0, len 328)
16:42:07.034134 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x79b98b39 secs:3 [|bootp] (ttl 64, id 0, len 328)
16:42:08.574268 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x8346f06f secs:2959 [|bootp] (ttl 64, id 0, len 328)
16:42:08.574289 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x8346f06f secs:2959 [|bootp] (ttl 64, id 0, len 328)
16:42:11.123933 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x79b98b39 secs:8 [|bootp] (ttl 64, id 0, len 328)
16:42:11.123949 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x79b98b39 secs:8 [|bootp] (ttl 64, id 0, len 328)
16:42:12.123588 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x8346f06f secs:2963 [|bootp] (ttl 64, id 0, len 328)
16:42:12.123618 fe:e1:ba:d2:02:32 ff:ff:ff:ff:ff:ff 0800 342: 0.0.0.0.68
> 255.255.255.255.67: xid:0x8346f06f secs:2963 [|bootp] (ttl 64, id 0, len 328)
```
and from the VM:
```
# udhcpc eth0
udhcpc: started, v1.37.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc failed to get a DHCP lease
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc failed to get a DHCP lease
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc failed to get a DHCP lease
```
(If I reload the PF rules it starts immediately.)
So, in this "broken" state I found that the VM has received IPv6 address
from the `slaacd`
and I can ping that IPv6 address from another machine in the network.
Then I set an IPv4 address manually and the ping started. I even put a
default gateway and the VM
reached the Internet.
But I can't SSH into VM, neither over IPv4, nor IPv6. I see the packets
coming to bridge0, but not reaching the tap0.
Again, if I reload the PF it starts to work as it should.
At the moment the host is running Apr 5 snapshot:
```
OpenBSD 7.9-beta (GENERIC.MP) #391: Sun Apr 5 11:12:14 MDT 2026
```
Bassically, that's the reason why I wrote my first email and gave such a
proposal to the OP.
Do you think that this issue is PF-related or something else is going
on?
I'll be happy to provide anything further that will help resolving this
problem.
Best wishes,
Atanas
