Messages

Thanks very much for the reference for that teardown image!  It looks to me that the sound I hear is coming from what appears to be the RAM area, which is odd. 

The background noise is because this is in a well-ventilated closet in my flat and I had the window open nearby - the DEC850 isn't in a rack and there is no power brick near the sound area, there's nothing at all.  And picking up the DEC850 has the sound follow the unit, coming from exactly the same location.  Very peculiar indeed...

In the last week or two, my DEC850 started making a soft rapid "chirp" sound (audio attached).  As I bought the unit in 2022 it's obviously going to be out of the initial warranty period (and I believe the model has since been upgraded to a "v2" anyway...

Given that the DEC850 is fanless, and there's likely no moving parts within it, does anyone have any thoughts as to what this sound could be, and, how worried I should be?  Likely electronic in origin, at a guess.  No, I haven't tried to open the unit up yet.  In terms of location, it seems to be towards the right edge somewhere, as you face the front of the unit (where the GB/SFP ports are).

Thank you!

There are a few ways to answer this, but, in short, if you are using a third party DNS service, such as NextDNS, Control-D, CloudFlare, Google, etc, then, yes, all of your DNS queries are being sent to them and they can see anything/everything that your devices may attempt to query/lookup.

However, the word that does the heavy lifting above is "can" - that's purely at the technology level of a query leaving your network and going to their systems.  Whether or not they log that data, mine it, monetise it, sell it, harvest it, etc etc, is a more complicated question to answer.

You'll want to check the privacy policies of any company that you may forward queries to.  Some claim to be quite pro-privacy and that they do not log data related to queries, or, give you transparent access/control to what they log (NextDNS does this for example), as well as where they log it, and for how long.

DoT, DoH, or DoQ are all great ways to protect your DNS queries in transit from unscrupulous ISPs that may tamper with, censor, or otherwise interfere with your DNS activities, but, once the query lands at the DNS provider you may send upstream queries to, that's where things become more complicated.

There are a variety of ways of configuring AdGuardHome that may work to your liking; it allows you to specify what DNSBLs you make use of, and those lists are (I believe, but someone else will correct me if I'm wrong, because that's what the Internet does) kept locally for the purposes of blocking.

That means that if you are using AGH, and your local devices look up "evil.com" and evil.com is on a DNSBL you activated in AdGuardHome, then that query is not sent anywhere other than your local network.

Now, keep in mind that AdGuardHome also permits you to refer queries to upstream DNS resolvers (caching/forwarding resolvers) which AdGuard controls.  These may offer additional DNS query protections to minimise certain types of domains (ads, trackers, malware, whatever), but, you do not have to use those; you can use the "Filters" menu of AGH to control what blocklists you want to use, and those are periodically retrieved and downloaded to your local network.

So really the answer to your question falls to how you configure your network to get answers to queries that your local network doesn't know the answer to.  At some point you need to ask someone for the data, as gone are the days when we could FTP to DECVAX and download the HOSTS.TXT file (yes, I've been doing this this long.  Longer.).

Personally, I'd recommend a layered approach.  I use AdGuardHome with a series of custom upstreams for various domains which may either talk to something local I control, or, talk to NextDNS, but, I also have local Filters in AGH, but trust the privacy policy of NextDNS for the things I send them.  Read their privacy policy yourself at https://nextdns.io/privacy and see what you think.

But there are lots of other providers of DNS services, and you'll want to carefully review the services and policies of anyone you use.

I'd *like* to use Unbound, but, I've got a very complicated setup that was easier to accomplish in AdGuardHome, particularly because I'm using DoH, DoT, and wherever possible DoQ; and the latter (DNS over QUIC) is still somewhat experimental in Unbound, and I don't believe it's made it to the version in OPNSense yet.

Just my tuppence...

Stupid question:  Is patch 287c13beb still necessary to apply if one installs 24.7_9? 

I've been waiting a bit to upgrade to 24.7, but as I do a fair bit with IPv6, was watching this thread closely.  I'll probably be waiting a few more days before doing any installations anyway, but, wasn't sure if this patch is already included in one of the Hotfixes or not.

For what it is worth, I did something like this whereby I increased my LAN from a /24 to a /23, and it was as simple as modifying the DHCP lease settings for DHCP clients (not yet played with Kea), including the netmask, and ensuring that the static IPv4 interface for the OPNSense box itself also had the /23 subnet selected from the dropdown.  I rebooted the box, then, rebooted my DHCP clients.

In my case, the only things that required anything more were a handful of devices where I wasn't using DHCP and had chosen to specify static settings which needed the new netmask.  Changed that, rebooted those devices just to be sure (but wasn't really necessary), and It Just Worked.

I don't think there was anything more to it in my case, but it was a year or so back, so I may be forgetting a step (that someone is bound to correct in this thread shortly).

[For people that have this issue:]

For people that have this issue: Check if you've assigned a static ip address to your wireguard interface. You would be able to see this under Interface->[Your wireguard interface].

If you go to this page and press save without making ANY changes, opnsense will yell at you with an error message. Make the fix (in my case, don't assign a static ip address), then press save, apply the changes, and then restart wireguard. The routes will now get propagated.

In my case, this is not the issue (at least not obviously); routes are not being propagated, as you pointed out, but, it's not due to an issue with the interface configuration.

My interface is set to "None" for the IPv4 and v6 configuration type -- all of my WG interfaces are -- and doing a "save" does not generate an error.

However, the UI *does* say that a change was made and now I need to apply it, even though no change was actually made, which may imply something else changed.

Certainly possible that it's something related to the Github issue mentioned.  My list of AllowedIPs is quite extensive, 168 defined networks or /32 hosts.  I'll go through that carefully and look for any overlaps - I did find a /24 which was also defined in a /16. 

In my situation, though, manually restarting the interface in question from the UI allowed me to route traffic again, but it's still not clear what's "broken".

I did a manual "restart" of the wg3 interface as per:

https://forum.opnsense.org/index.php?topic=39819.0

And that seems to have fixed whatever was "stuck".

And yes, I'm at _2 now.

I will do a poor job of explaining this, and my apologies for that in advance.

I was at the most recent version of OPNSense, and everything was working fine.

I updated to 24.1.5_1 this morning, and one of my Wireguard tunnels - whilst up - is not routing/passing packets as it did prior to this version being installed.

The interface (wg3) receives packets from the peer (I can remotely access the peer, and send ICMP or other traffic to the IP address of the wg3 endpoint on my OPNSense box.

However, no outbound packets traverse that interface, despite there having been no changes to my configuration for Wireguard for quite some time.

I have firewall rules in my OPNSense to permit certain hosts on my LAN to send to the remote peer, and am using outbound masquerading to masquerade as the "Interface address" for those packets -- again, nothing has changed here, and it was routing/passing packets just fine until this update.

I've tried a few reboots, just in case that might "clear something up", but to no avail.

On my OPNSense box, listening on the wg3 interface, I can see my remote peer's ICMP coming in:

listening on wg3, link-type NULL (BSD loopback), capture size 262144 bytes
09:18:16.311527 IP 10.200.202.2 > 10.200.202.1: ICMP echo request, id 49148, seq 256, length 64
09:18:17.335410 IP 10.200.202.2 > 10.200.202.1: ICMP echo request, id 49148, seq 257, length 64
09:18:18.359476 IP 10.200.202.2 > 10.200.202.1: ICMP echo request, id 49148, seq 258, length 64
09:18:19.383596 IP 10.200.202.2 > 10.200.202.1: ICMP echo request, id 49148, seq 259, length 64

But nothing is returned from 10.200.202.1, which is the wg3 interface.

WireGuard reports that it is up and handshakes are working fine, which is obviously the case or the ICMP wouldn't make it in.

I have several other WG interfaces, all of which are working fine as far as I can tell (Dashboard says all gateways are up, and packets seem to be flowing).

The only thing that is different about this particular interface (wg3) is that it's only meant to be listening on localhost, which means that the traffic to the remote endpoint needs to go to another process on my OPNSense box which is also listening on localhost.

Again, this was all working great till I updated, now not so much.

If I can't figure out a quick fix for this one, what's the right/best way to "rollback" OPNSense installs to the previous version whilst I ponder this a bit more?

Thank you!

Thanks!

I did search before posting, but, obviously not well enough.   All sorted!

I noticed something peculiar about this release that I have not had issues prior to 23.7 -- something that I did in earlier versions isn't working, and that thing is:

1)  Login
2)  Select Services -> DHCPv4 -> Leases
3)  Find a device on my LAN that I want to assign a static IP to
4)  Click the + symbol box on the row for that item

Previous behaviour: 

I was taken to a page to add the static IP with various parameters.

Current behaviour:

I'm immediately taken back to the Dashboard, and no obvious errors appear in any of the system log files.

I was able to add the static assignment by:

Services -> DHCPv4 -> [LAN name] -> Scroll to bottom -> Select + symbol

At that point it took me to the page I was expecting, and I was able to add the static assignment and all seems okay.

Not sure if this is Just Me, or if there's something amiss somewhere.

pflogsumm.

I've used this for years for Postfix logs.  Not using it on my OPNSense, but am sure you could find a way to make it work. May even be in FreeBSD ports...

Outstanding.  That was it.  I modified the .conf file, re-issued a certificate, and all looks good.

Thank you very much for the pointer!

This may or may not help you...

One thing to keep in mind is that for each Mullvad connection you'll likely need to have a different Wireguard key, and, as you probably know, Mullvad only permits 5 total per Mullvad account. 

In my case, I have several Mullvad connections set up, each using their own wgX interface assignment, but, each connection has its own key, and, I believe in all cases, each has a different tunnel address.  There was a bit of trial and error in my getting everything to work right, but, I followed the guide on the OPNsense Docs site and it mostly got me where I needed to go.

I haven't experienced what you describe, though.

For what it is worth, this problem persists with OPNsense 23.1.7_3 with ACME Client Plugin 3.16.

The DNS01 challenge for Gandi (and perhaps all DNS01 challenges?) seem to fail immediately, without respecting the DNS Sleep option. 

Regularly through its native UI. I follow their RSS feed for releases, and as soon as something new comes out, I update locally.

Weirdly, since the update, DNS rewrites have been flaky.  I have had to disconnect and reconnect network clients to ensure they get rewritten responses.  It may be related to IPv6 somehow, so, will look at that.