Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - puithove

#1
It seems you were right on the money.  Dropped the vcpu down to 6, and while it does spin up the CPU when applying the firewall rules, it doesn't take very long at all - 30s or so vs 10 minutes.  Definitely seems like CPU contention anyway.

Thanks!
#2
Yea, you're not wrong on that.  Right now though it's running on an otherwise unused node, and was the same when I had only 12 vcpus on it (turned it up to try to improve boot time, which it as expected didn't).  I'm away from home right now so don't / can't take down the router to change it.  I'll play with it a bit more when I'm back home in a few days.
#3
I definitely should have included that.

VM running under Proxmox
Dual E5-2630v2 - 12 physical cores with hyperthreading enabled
VM given 24 threads (virtual cores)
#4
I don't reboot my router very often luckily, usually just when doing upgrades.  However, I recently started noticing a really long startup time which is spent waiting on "Configuring Firewall..." with the CPU just pegged out.  We're talking times of 10+ minutes waiting like that.

I decided to dig through all of my firewall rules to figure out what was taking so long.  In doing so I looked at the number of addresses defined for the bogonsv6 alias, and as soon as I saw that I knew what the holdup was.  There are 10s of thousands that are added to the firewall rules for blocking bogons via that alias (makes sense given the address space of IPv6).

I have turned off blocking bogons for now and that makes an instant difference. I wonder though if there are any optimizations that can be made to how firewall rulesets are loaded that could reduce the amount of time it takes to get through this at bootup time.  Considering that making changes to firewall rulesets and applying changes even with the block bogons enabled is very quick, it kinda surprises me that it takes so long to load the ruleset at bootup (though maybe applying changes doesn't force a full ruleset reload).

Other thought - I've had the Block Bogons feature enabled since the dawn of time, and have had dual-stack IPv6 running for the past few years - so why is this suddenly an issue more recently?

Currently on OPNsense 21.1.5-amd64
#5
Ok, found this little gold nugget in the release notes for 18.7.9:

unbound: only use IPv6 when enabled and IPv4 is not preferred

So I turned off the "Prefer IPv4" option (under System / Settings / General), and now it's listening on IPv6, and working correctly.

That seems valid - but if this is to be the case, then that option should also make it so that the DNS server list handed out by DHCP does NOT include any of the IPv6 addresses.
#6
Nobody run into this?  No thoughts?
#7
I'm on 18.7.9

I have IPV6 configured to go through TunnelBroker/HE.  All traffic on IPV6 flows fine.  Unbound is running as a forwarder - forwarding to IPv4 addresses - and successfullly resolves all IPV6 queries. DHCPv4 apparently includes the interface's IPV6 address in the list of DNS servers provided as it shows up in client's resolvers.  This results in slow DNS queries as clients sometimes attempt to contact DNS on IPV6 which times out.

Unbound is not listening on any IPV6 address.  Output from "sockstat | grep -i unbound" run on the OPNsense router:

unbound  unbound    79724 3  stream /tmp/php-fastcgi.socket-1
unbound  unbound    79724 4  udp4   *:53                  *:*
unbound  unbound    79724 5  tcp4   *:53                  *:*
unbound  unbound    79724 6  tcp4   127.0.0.1:953         *:*
unbound  unbound    79724 7  dgram  -> /var/run/logpriv
unbound  unbound    79724 8  stream -> ??
unbound  unbound    79724 9  stream -> ??
unbound  unbound    79724 10 stream -> ??
unbound  unbound    79724 11 stream -> ??
unbound  unbound    79724 12 stream -> ??
unbound  unbound    79724 13 stream -> ??
unbound  unbound    79724 14 stream -> ??
unbound  unbound    79724 15 stream -> ??


You can see it's listening on all udp4 and tcp4 addresses.  On the config page, I have "ALL" set on both Network Interfaces and Outgoing Network Interfaces.  Unbound ACLs automatically include all IPV6 subnets from all my interfaces.

I saw in some other threads there may be a need to manually add config option "do-ip6: yes", but when I put that in Custom Options on the General config page, Unbound fails to start.

Any tips here?