Re: Clang sanitizer support
On Fri, Jan 8, 2021, at 5:40 PM, Joe Nelson wrote: > Hi all, I'd like to use Clang's AddressSanitizer and ThreadSanitizer > on my OpenBSD development machine. Following up on this, looks like MALLOC_OPTIONS can help me detect use-after-free and double free errors. What I'm missing is a way to detect memory leaks in my programs. Any tips?
Re: DHCP non-issues
Claudio Jeker wrote: > On Tue, Jul 20, 2021 at 08:53:03AM -, Stuart Henderson wrote: > > On 2021-07-19, jungle Boogie wrote: > > > On Mon, 19 Jul 2021 at 04:48, Christian Weisgerber > > > wrote: > > >> > > >> Look guys, it's simple. > > >> > > >> If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" > > >> for that interface. slaacd(8) will then automatically handle things. > > >> > > >> If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" > > >> for that interface. dhcpleased(8) will then automatically handle > > >> things. If you require special DHCP options that dhcpleased(8) > > >> doesn't include, then you don't enable autoconfigurarion and run > > >> dhclient(8) instead, which can be extensively configured. > > >> > > >> Both slaacd(8) and dhcpleased(8) pass nameserver information to > > >> resolvd(8), which adds those nameservers to /etc/resolv.conf unless > > >> unwind(8) is running. If you don't want that to happen for some > > >> other reason, you turn off resolvd(8). > > >> > > > > > > Sounds like great information to put in current.html: > > > https://www.openbsd.org/faq/current.html > > > I think folks are surprised by the change and want to know how to > > > handle the new daemons in certain situations. > > > Your explanation above is very helpful and probably could be used in > > > current.html > > > I imagine the 7.0 "what's new" section will contain something similar. > > > > > > > > > What do I need to do to have WireGuard start at boot when I want to > > > use a hostname in my hostname.wg0 interface file? > > > > > > Currently, the interface doesn't come up as expected: > > > ifconfig: no address associated with name > > > > > > Are these my options? > > > a. use dhclient > > > b. make a script to start the interface later > > > c. use ip address > > > > or d. add an entry to /etc/hosts > > > > Some people are also running into problems with hostnames in pf.conf; > > a c and d apply in that case too. > > > > Some of this could be fixed by having a way to ask dhcpleased to wait > > (with timeout) for an address during boot. For your example with wg, > > as well as that, netstart would need to be split i.e. start standard > > interfaces, then dhcpleased/unwind/resolvd, then tunnel interfaces. > > > > I was going to say the same would apply for hostnames used in fstab > > if /usr and /var are NFS-mounted; but actually /usr and /var can't > > be NFS-mounted if you rely on addresses from dhcpleased to reach the > > NFS server anyway (these daemons need access to /var so they need > > to be started after /usr and /var are mounted). > > > > Actually this needs to be fixed in /etc/netstart, dhcpleasd / slaacd. Until > now systems with dynamic ips had the 10sec wait of dhclient to make sure > the interfaces are up and configured. This no longer and because of this > stuff breaks left and right. > > Up until now the system relied on the fact that after /etc/netstart ran > the interfaces where up and configured (static or dynamic) and all > following services relied on this fact. Honestly adding host entires is > not a solution because it will not work in all cases. e.g. pf rules using > interface names as addresses will not work correctly. > > There must be a way to wait at the end of netstart to ensure that network > configuration settled or timed out. IIRC dlg@ hat a diff that allowed > something along these lines. > > We already hit this issue with slaacd on IPv6-only setups and ignored it. > Now it affects everyone, lets not ignore it again. The following diff will help the most common cases. netstart will pause a little bit until at least one (v4 or v6) default route is installed. In the most common cases, this is immediate. In the dynamic cases, the delay is probably enough. We don't need to solve all potential problems.. Index: etc/netstart === RCS file: /cvs/src/etc/netstart,v retrieving revision 1.213 diff -u -p -u -r1.213 netstart --- etc/netstart16 Jul 2021 15:21:41 - 1.213 +++ etc/netstart20 Jul 2021 16:20:15 - @@ -335,3 +335,9 @@ if [[ $ip6kernel == YES ]]; then sleep 1 done fi + +# Pause a little so at least one dynamic (slaacd or dhcpleased) config completes +count=0 +while ((count++ < 20 && $(route -n show | grep '^default ' | wc -l) == 0)); do + sleep .5 +done
Re: enqueue_randomness from userland ?
Sven F. wrote: > > How to manually increase entropy ? Jerk the joystick rapidly from side to side, as if running as Lewis Carol in the LA Olympics video game.
Fw: Re: VLANs isolation
Hello Rosen,
> - block out on vlan received-on vlan
> is redundant, it never going to be used, you already have block all
Unfortunalety, the traffic passes between vlans without that rule at the end of
my rule set. I don't know why...
> - pass quick on vlan1003 inet from vlan1002:network to vlan1003:network
> Because of the direction from - to, this rule will be applied on the inbound
> traffic only
That's exactly what I need. I want clients fron one vlan to access devices in
another vlan but disable access inversely.
> Also as this is a quick rule, you should move it to the top of your rule set,
> so the traffic that matches this one, does not get evaluated for the rest of
> your rules.
True, thanks for the hint!
On Sat, 17 Jul 2021 10:25:37 -0600
Rosen Iliev wrote:
> Hello Radek,
>
> Your
>
> - block out on vlan received-on vlan
> is redundant, it never going to be used, you already have block all
>
> - pass quick on vlan1003 inet from vlan1002:network to vlan1003:network
> Because of the direction from - to, this rule will be applied on the inbound
> traffic only, so the rule should be*pass in quick on vlan1003***Also as this
> is a quick rule, you should move it to the top of your rule set, so the
> traffic that matches this one, does not get evaluated for the rest of your
> rules. I know the pf will optimize that in some point of time.
>
> Regards,
>
> Rosen
>
> Radek wrote on 7/14/2021 08:25:
> > Thank you Claudio for pointing me in the right direction.
> >
> > My testing pf.conf seems to work as expected:
> > - vlan1002:network can ping vlan1003:network only
> > - vlan1003:network can't ping vlan1002:network
> > - there is no routing between other vlans
> >
> > set block-policy drop
> > set loginterface egress
> > set skip on lo0
> > match in all scrub (no-df random-id max-mss 1440)
> > match out on egress inet from !(egress:network) to any nat-to (egress:0)
> > antispoof quick for { egress vlan }
> > block all
> > pass in on egress inet proto tcp to egress port 22
> > pass out quick on egress inet
> > pass on vlan inet to !vlan
> > pass quick on vlan1003 inet from vlan1002:network to vlan1003:network
> > block out on vlan received-on vlan
> >
> > Any other pf tweeks and suggestion would be appreciated.
> >
> > On Tue, 13 Jul 2021 12:25:32 +0200
> > Claudio Jeker wrote:
> >
> >> On Tue, Jul 13, 2021 at 11:34:28AM +0200, Radek wrote:
> >>> Hello,
> >>> I'm going to build a router with +40 vlans.
> >>> I need to block access from every vlan to each other (and then enable
> >>> traffic between certain vlans as needed).
> >>>
> >>> How can I do this? Is there any one liner pf block rule to do this?
> >> Not really but you can try:
> >>
> >> block out on vlan received-on vlan
> >>
> >> It really matters in how you want to build your filters (outbound or
> >> inbound filtering). Maybe it is better to just start with a block all rule
> >> and slowly allow traffic back. You can use interface groups and pf tags to
> >> help with rule writing.
> >>
> >> --
> >> :wq Claudio
> >>
> >
>
--
Radek
--
Radek
Re: enqueue_randomness from userland ?
On 2021-07-20, Sven F. wrote: > On Tue, Jul 20, 2021 at 1:41 PM Theo de Raadt wrote: >> >> The entropy subsystem is complete. >> >> There is no need to do anything more. >> > > I saw that reading adds entropy back, > if the subsystem is complete out of the box that would make > https://man.openbsd.org/omrng or https://man.openbsd.org/octrng.4 superfluous, > which is odd, but i'll trust you on that. Entropy from the hw RNGs is useful for first boot, and sometimes if you're running from cloned disk images (e.g. for some provisioning systems). > A long time ago it was easy to block /dev/random and urandom was of > lesser quality. Have a read of http://www.openbsd.org/papers/hackfest2014-arc4random/ to see how it works.
Re: enqueue_randomness from userland ?
Sven F. wrote: > On Tue, Jul 20, 2021 at 1:41 PM Theo de Raadt wrote: > > > > The entropy subsystem is complete. > > > > There is no need to do anything more. > > > > I saw that reading adds entropy back, > if the subsystem is complete out of the box that would make > https://man.openbsd.org/omrng or https://man.openbsd.org/octrng.4 superfluous, > which is odd, but i'll trust you on that. > > A long time ago it was easy to block /dev/random and urandom was of > lesser quality. What you are trying to do is pointless.
Re: enqueue_randomness from userland ?
On Tue, Jul 20, 2021 at 1:41 PM Theo de Raadt wrote: > > The entropy subsystem is complete. > > There is no need to do anything more. > I saw that reading adds entropy back, if the subsystem is complete out of the box that would make https://man.openbsd.org/omrng or https://man.openbsd.org/octrng.4 superfluous, which is odd, but i'll trust you on that. A long time ago it was easy to block /dev/random and urandom was of lesser quality. -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: enqueue_randomness from userland ?
The entropy subsystem is complete. There is no need to do anything more. Sven F. wrote: > Dear readers, > > Is it possible to call `enqueue_randomness` from userland ? > Looks like `echo 'something' > /dev/random` would not work but > > `ttyinput(int c, struct tty *tp)` is calling it > > so maybe echo 'something' > /dev/tty00 would ( but my guess it doesn't > either ) > as i cannot 'input command' like that ( need to come from keyboard . > > How to manually increase entropy ? > > Best, > > -- > -- > - > Knowing is not enough; we must apply. Willing is not enough; we must do >
enqueue_randomness from userland ?
Dear readers, Is it possible to call `enqueue_randomness` from userland ? Looks like `echo 'something' > /dev/random` would not work but `ttyinput(int c, struct tty *tp)` is calling it so maybe echo 'something' > /dev/tty00 would ( but my guess it doesn't either ) as i cannot 'input command' like that ( need to come from keyboard . How to manually increase entropy ? Best, -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: Clang sanitizer support
Joe Nelson writes: > On Fri, Jan 8, 2021, at 5:40 PM, Joe Nelson wrote: >> Hi all, I'd like to use Clang's AddressSanitizer and ThreadSanitizer >> on my OpenBSD development machine. > > Following up on this, looks like MALLOC_OPTIONS can help me detect > use-after-free and double free errors. What I'm missing is a way to > detect memory leaks in my programs. Any tips? There's a built-in mechanisms to check for memory leaks: https://www.drijf.net/malloc/ don't know if it still applies, I tried only once and was like a couple of years ago (if not more). HTH
Re: DHCP non-issues
Is it still possible to reject dhcp replies from certain servers? Here in the Netherlands ISPs provide you with a random pick of black box routers with their plans. Last year I had a VodafoneZiggo plan, offering 8 variants, and currently I have a KPN plan which has 12. Both times I received their most recent hardware model. The default connection method is to have your ISP router function as a gateway through which your connections pass via a (usually very poor) NAT engine. Luckily I was able to put these devices in "bridge" mode through their respective front-end menus. The goal was to avoid as much software layers as possible, receive the external IP on my OpenBSD gateway box, as well as all unfiltered traffic. However, whenever the VodafoneZiggo router had a reboot cycle (e.g. when the ISP pushed a software update) it would first go into its default state - providing local dhcp et al. - before it would go into bridge mode shortly after. This consistently broke my setup. My current KPN router does things differently: the local dhcpd cannot be disabled even in this "bridge" mode. Meaning it will be the response that wins discovery every time. Again, breaking my setup. I solved these issues by putting the following in my dhclient.conf, resp.: reject 192.168.1.254; reject 192.168.100.1;
Re: DNS resolution after VPN?
and make sure there is a route to Route to your Internal DNS servers
over the VPNs
Or
a policy that covers the DNS servers ip range if it is an Ipsec
policy based vpn
Hope this helps
On Tue, 20 Jul 2021 at 13:15, Timo Myyrä wrote:
>
> Stuart Henderson [2021-07-20, 11:24 +]:
>
> > On 2021-07-20, Timo Myyrä wrote:
> >
> >> Hi,
> >>
> >> Just started testing the new dhcleased,resolvd stuff and noticed that
> >> DNS resolution won't work correctly once I open my VPN connection. Name
> >> resolution works for external domains but not for the internal domains
> >> resolved by the interal DNS servers.
> >>
> >> I'm using openconnect to setup VPN tunnel and it runs the
> >> /etc/vpnc-script to setup networking after initing the tunnel. This
> >> script adds the nameserver entries into /etc/resolv.conf.
> >> But these entries in /etc/resolv.conf are done below following line:
> >> nameserver 127.0.0.1 # resolvd: unwind
> >>
> >> This means the unwind is handling the DNS query passing and it doesn't
> >> seem to notice the DNS server entries given by openconnect.
> >>
> >> What would be a good method to get DNS resolution working after running
> >> openconnect? I'd like to prepend the DNS servers from VPN connection so
> >> they are queried first, then fallback to other servers.
> >>
> >> Timo
> >>
> >>
> >
> > Untested but I would use unwind and try something like
> >
> > forwarder
> > preference recursor oDoT-dhcp dhcp stub
> > force forwarder {vpndomain.com}
> >
> > For the forwarder address you might be able to statically configure
> > it, if not then you could modify vpnc-script to have it update the
> > address in unwind.conf and reload it.
>
> Thanks, this works somewhat:
>
> forwarder { $ip1 $ip2 }
> force accept bogus forwarder { $internal_domain1 }
> force accept bogus forwarder { $internal_domain2 }
> ...
>
> A bit cubersome to list all internal domains but I there shouldn't be
> that many of them in day-to-day use.
> The DNS server IP's are pretty much static so manually adjusting the
> unwind.conf is doable.
>
> Timo
>
--
Kindest regards,
Tom Smyth.
Re: DNS resolution after VPN?
Stuart Henderson [2021-07-20, 11:24 +]:
> On 2021-07-20, Timo Myyrä wrote:
>
>> Hi,
>>
>> Just started testing the new dhcleased,resolvd stuff and noticed that
>> DNS resolution won't work correctly once I open my VPN connection. Name
>> resolution works for external domains but not for the internal domains
>> resolved by the interal DNS servers.
>>
>> I'm using openconnect to setup VPN tunnel and it runs the
>> /etc/vpnc-script to setup networking after initing the tunnel. This
>> script adds the nameserver entries into /etc/resolv.conf.
>> But these entries in /etc/resolv.conf are done below following line:
>> nameserver 127.0.0.1 # resolvd: unwind
>>
>> This means the unwind is handling the DNS query passing and it doesn't
>> seem to notice the DNS server entries given by openconnect.
>>
>> What would be a good method to get DNS resolution working after running
>> openconnect? I'd like to prepend the DNS servers from VPN connection so
>> they are queried first, then fallback to other servers.
>>
>> Timo
>>
>>
>
> Untested but I would use unwind and try something like
>
> forwarder
> preference recursor oDoT-dhcp dhcp stub
> force forwarder {vpndomain.com}
>
> For the forwarder address you might be able to statically configure
> it, if not then you could modify vpnc-script to have it update the
> address in unwind.conf and reload it.
Thanks, this works somewhat:
forwarder { $ip1 $ip2 }
force accept bogus forwarder { $internal_domain1 }
force accept bogus forwarder { $internal_domain2 }
...
A bit cubersome to list all internal domains but I there shouldn't be
that many of them in day-to-day use.
The DNS server IP's are pretty much static so manually adjusting the
unwind.conf is doable.
Timo
Re: DNS resolution after VPN?
On 2021-07-20, Timo Myyrä wrote:
> Hi,
>
> Just started testing the new dhcleased,resolvd stuff and noticed that
> DNS resolution won't work correctly once I open my VPN connection. Name
> resolution works for external domains but not for the internal domains
> resolved by the interal DNS servers.
>
> I'm using openconnect to setup VPN tunnel and it runs the
> /etc/vpnc-script to setup networking after initing the tunnel. This
> script adds the nameserver entries into /etc/resolv.conf.
> But these entries in /etc/resolv.conf are done below following line:
> nameserver 127.0.0.1 # resolvd: unwind
>
> This means the unwind is handling the DNS query passing and it doesn't
> seem to notice the DNS server entries given by openconnect.
>
> What would be a good method to get DNS resolution working after running
> openconnect? I'd like to prepend the DNS servers from VPN connection so
> they are queried first, then fallback to other servers.
>
> Timo
>
>
Untested but I would use unwind and try something like
forwarder
preference recursor oDoT-dhcp dhcp stub
force forwarder {vpndomain.com}
For the forwarder address you might be able to statically configure
it, if not then you could modify vpnc-script to have it update the
address in unwind.conf and reload it.
Re: DHCP non-issues
On 2021-07-20, Kevin Chadwick wrote: > On July 20, 2021 10:35:55 AM UTC, Kevin Chadwick wrote: >>On Mon, 19 Jul 2021, 12:47 Christian Weisgerber, >>wrote: >> >>> Look guys, it's simple. >>> >>> If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" >>> for that interface. slaacd(8) will then automatically handle things. >>> >>> If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" >>> for that interface. dhcpleased(8) will then automatically handle >>> things. If you require special DHCP options that dhcpleased(8) >>> doesn't include, then you don't enable autoconfigurarion and run >>> dhclient(8) instead, which can be extensively configured. >>> >> > > Is it possible to try inet autoconf and then also inet6 autoconf > opportunistically maybe even with inet preferred, for deployment in > foreign networks? > > Yes and that was possible with dhclient too.
Re: DHCP non-issues
On July 20, 2021 10:35:55 AM UTC, Kevin Chadwick wrote: >On Mon, 19 Jul 2021, 12:47 Christian Weisgerber, >wrote: > >> Look guys, it's simple. >> >> If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" >> for that interface. slaacd(8) will then automatically handle things. >> >> If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" >> for that interface. dhcpleased(8) will then automatically handle >> things. If you require special DHCP options that dhcpleased(8) >> doesn't include, then you don't enable autoconfigurarion and run >> dhclient(8) instead, which can be extensively configured. >> > Is it possible to try inet autoconf and then also inet6 autoconf opportunistically maybe even with inet preferred, for deployment in foreign networks?
DNS resolution after VPN?
Hi, Just started testing the new dhcleased,resolvd stuff and noticed that DNS resolution won't work correctly once I open my VPN connection. Name resolution works for external domains but not for the internal domains resolved by the interal DNS servers. I'm using openconnect to setup VPN tunnel and it runs the /etc/vpnc-script to setup networking after initing the tunnel. This script adds the nameserver entries into /etc/resolv.conf. But these entries in /etc/resolv.conf are done below following line: nameserver 127.0.0.1 # resolvd: unwind This means the unwind is handling the DNS query passing and it doesn't seem to notice the DNS server entries given by openconnect. What would be a good method to get DNS resolution working after running openconnect? I'd like to prepend the DNS servers from VPN connection so they are queried first, then fallback to other servers. Timo
Re: DHCP non-issues
Paul de Weerd(we...@weirdnet.nl) on 2021.07.19 20:04:35 +0200: > On Mon, Jul 19, 2021 at 01:59:18PM +0200, Paul de Weerd wrote: > | So far, I've found NFS and syslogd to need configuration changes or > | /etc/hosts entries to ensure they start properly. > > As I was asked about this off-list, I went back and re-read my > message. Apologies for not being more clear: Thanks for the details. The details are important here. They can be worked around by doing what dhclient did - wait. But they can also be fixed in the programs that have the actual problem, i.e. in syslogd and the NFS setup. Which is, i hope what we will do.
Re: DHCP non-issues
On Tue, Jul 20, 2021 at 08:53:03AM -, Stuart Henderson wrote: > On 2021-07-19, jungle Boogie wrote: > > On Mon, 19 Jul 2021 at 04:48, Christian Weisgerber > > wrote: > >> > >> Look guys, it's simple. > >> > >> If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" > >> for that interface. slaacd(8) will then automatically handle things. > >> > >> If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" > >> for that interface. dhcpleased(8) will then automatically handle > >> things. If you require special DHCP options that dhcpleased(8) > >> doesn't include, then you don't enable autoconfigurarion and run > >> dhclient(8) instead, which can be extensively configured. > >> > >> Both slaacd(8) and dhcpleased(8) pass nameserver information to > >> resolvd(8), which adds those nameservers to /etc/resolv.conf unless > >> unwind(8) is running. If you don't want that to happen for some > >> other reason, you turn off resolvd(8). > >> > > > > Sounds like great information to put in current.html: > > https://www.openbsd.org/faq/current.html > > I think folks are surprised by the change and want to know how to > > handle the new daemons in certain situations. > > Your explanation above is very helpful and probably could be used in > > current.html > > I imagine the 7.0 "what's new" section will contain something similar. > > > > > > What do I need to do to have WireGuard start at boot when I want to > > use a hostname in my hostname.wg0 interface file? > > > > Currently, the interface doesn't come up as expected: > > ifconfig: no address associated with name > > > > Are these my options? > > a. use dhclient > > b. make a script to start the interface later > > c. use ip address > > or d. add an entry to /etc/hosts > > Some people are also running into problems with hostnames in pf.conf; > a c and d apply in that case too. > > Some of this could be fixed by having a way to ask dhcpleased to wait > (with timeout) for an address during boot. For your example with wg, > as well as that, netstart would need to be split i.e. start standard > interfaces, then dhcpleased/unwind/resolvd, then tunnel interfaces. > > I was going to say the same would apply for hostnames used in fstab > if /usr and /var are NFS-mounted; but actually /usr and /var can't > be NFS-mounted if you rely on addresses from dhcpleased to reach the > NFS server anyway (these daemons need access to /var so they need > to be started after /usr and /var are mounted). > Actually this needs to be fixed in /etc/netstart, dhcpleasd / slaacd. Until now systems with dynamic ips had the 10sec wait of dhclient to make sure the interfaces are up and configured. This no longer and because of this stuff breaks left and right. Up until now the system relied on the fact that after /etc/netstart ran the interfaces where up and configured (static or dynamic) and all following services relied on this fact. Honestly adding host entires is not a solution because it will not work in all cases. e.g. pf rules using interface names as addresses will not work correctly. There must be a way to wait at the end of netstart to ensure that network configuration settled or timed out. IIRC dlg@ hat a diff that allowed something along these lines. We already hit this issue with slaacd on IPv6-only setups and ignored it. Now it affects everyone, lets not ignore it again. -- :wq Claudio
Re: DHCP non-issues
On 2021-07-19, jungle Boogie wrote: > On Mon, 19 Jul 2021 at 04:48, Christian Weisgerber wrote: >> >> Look guys, it's simple. >> >> If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" >> for that interface. slaacd(8) will then automatically handle things. >> >> If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" >> for that interface. dhcpleased(8) will then automatically handle >> things. If you require special DHCP options that dhcpleased(8) >> doesn't include, then you don't enable autoconfigurarion and run >> dhclient(8) instead, which can be extensively configured. >> >> Both slaacd(8) and dhcpleased(8) pass nameserver information to >> resolvd(8), which adds those nameservers to /etc/resolv.conf unless >> unwind(8) is running. If you don't want that to happen for some >> other reason, you turn off resolvd(8). >> > > Sounds like great information to put in current.html: > https://www.openbsd.org/faq/current.html > I think folks are surprised by the change and want to know how to > handle the new daemons in certain situations. > Your explanation above is very helpful and probably could be used in > current.html > I imagine the 7.0 "what's new" section will contain something similar. > > > What do I need to do to have WireGuard start at boot when I want to > use a hostname in my hostname.wg0 interface file? > > Currently, the interface doesn't come up as expected: > ifconfig: no address associated with name > > Are these my options? > a. use dhclient > b. make a script to start the interface later > c. use ip address or d. add an entry to /etc/hosts Some people are also running into problems with hostnames in pf.conf; a c and d apply in that case too. Some of this could be fixed by having a way to ask dhcpleased to wait (with timeout) for an address during boot. For your example with wg, as well as that, netstart would need to be split i.e. start standard interfaces, then dhcpleased/unwind/resolvd, then tunnel interfaces. I was going to say the same would apply for hostnames used in fstab if /usr and /var are NFS-mounted; but actually /usr and /var can't be NFS-mounted if you rely on addresses from dhcpleased to reach the NFS server anyway (these daemons need access to /var so they need to be started after /usr and /var are mounted).
