Messages

1

General Discussion / Re: Adguardhome, NextDNS, ControlD etc....

« on: August 24, 2024, 03:05:41 am »

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...

2

24.7 Production Series / Re: [SOLVED] DHCP6 Gateway is shown as disconnected in 24.7

« on: July 30, 2024, 02:46:20 am »

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.

3

General Discussion / Re: How can I widen the LAN subnet from /24 to /20?

« on: July 13, 2024, 05:08:50 am »

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).

4

24.1 Legacy Series / Re: 24.1.5: Wiregard routing/masquerading issue? How to rollback?

« on: April 06, 2024, 04:10:55 am »

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".

5

24.1 Legacy Series / Re: 24.1.5: Wiregard routing/masquerading issue? How to rollback?

« on: April 05, 2024, 12:31:48 am »

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.

6

24.1 Legacy Series / 24.1.5: Wiregard routing/masquerading issue? How to rollback?

« on: April 05, 2024, 12:24:55 am »

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!

7

23.7 Legacy Series / Re: Adding DHCPv4 static leases (OPNsense 23.7.2)

« on: August 28, 2023, 07:06:07 am »

Thanks!

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

8

23.7 Legacy Series / Adding DHCPv4 static leases (OPNsense 23.7.2)

« on: August 27, 2023, 05:42:30 am »

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.

9

23.1 Legacy Series / Re: Postfix Log Analysis

« on: May 26, 2023, 11:13:56 pm »

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…

10

23.1 Legacy Series / Re: [SOLVED] ACME plugin with Gandi LiveDNS

« on: May 15, 2023, 01:02:58 am »

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

Thank you very much for the pointer!

11

23.1 Legacy Series / Re: Maximum active (Mullvad) VPN connections with WireGuard?

« on: May 07, 2023, 06:14:55 am »

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.

12

23.1 Legacy Series / Re: ACME plugin with Gandi LiveDNS

« on: May 06, 2023, 05:58:42 am »

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. 

13

23.1 Legacy Series / Re: DNS issues since 23.1.6

« on: May 04, 2023, 10:42:06 pm »

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. 

14

23.1 Legacy Series / Re: DNS issues since 23.1.6

« on: May 04, 2023, 03:18:04 am »

I'd been holding off installing 23.1.6 till the AdGuard plugin was updated - once that happened, and this thread indicated things were working, I went for it.  I had a few issues (still do) that I thought I'd share.  I fully accept this may Just Be Me.

I am using AdGuard on 53, I am not using Unbound, I am not using any NAT rules to redirect 53 to some other port where AdGuard is listening.  It's a very basic setup with regards to ports, but, for my specific DNS requirements, it's been working fine.

Upon installing the 1.9 plugin for AdGuard, I enabled the tickbox for listening on 53 (Primary DNS).

Everything reported green and up and running, but, after about a minute, AdGuard stopped responding and the Dashboard said the service was not running.  I restarted it, and everything worked fine.

This morning, I rebooted my system and the same thing happened.  Everything seemed to start up just fine, but, a minute or two later, AdGuard ceased replying (and I could not reach it on the local port/dashboard for AdGuard).  The dashboard was "green" and implied the service was running, and, when the system first booted, DNS worked.

I clicked on restart again, and it's been up ever since.  I haven't been able to locate anything in the OPNSense logs that seems salient, but will keep hunting.  Again, may Just Be Me, but, thought I'd mention it.

15

23.1 Legacy Series / [SOLVED] ACME plugin with Gandi LiveDNS

« on: April 10, 2023, 06:16:52 am »

Prior to 23.1, the ACME plugin seemed to work fine, and I had automatically renewed certificates for several months.

Somewhere around the change to 23.1, however, it no longer works via OPNSense, even though I can use Gandi's LiveDNS and API key from "letsencrypt" on a Pi just fine (so the issue is not Gandi, and not the API key).

My logs appear as such (with debug logging enabled for the ACME Settings):

Code: [Select]

2023-04-10T14:02:33 Error   opnsense    AcmeClient: validation for certificate failed: host.mydomain.com   
2023-04-10T14:02:33 Error   opnsense    AcmeClient: domain validation failed (dns01)   
2023-04-10T14:02:25 Notice  opnsense    AcmeClient: running acme.sh command: /usr/local/sbin/acme.sh --issue --syslog 7 --debug --server 'letsencrypt' --dns 'dns_gandi_livedns' --dnssleep '90' --home '/var/etc/acme-client/home' --certpath '/var/etc/acme-client/certs/whatever.07307279/cert.pem' --keypath '/var/etc/acme-client/keys/whatever.07307279/private.key' --capath '/var/etc/acme-client/certs/whatever.07307279/chain.pem' --fullchainpath '/var/etc/acme-client/certs/whatever.07307279/fullchain.pem' --domain 'host.mydomain.com' --days '1' --force --keylength '4096' --accountconf '/var/etc/acme-client/accounts/whatever.40506586_prod/account.conf'   
2023-04-10T14:02:25 Notice  opnsense    AcmeClient: using challenge type: GandiV5   
2023-04-10T14:02:25 Notice  opnsense    AcmeClient: account is registered: Let's Encrypt   
2023-04-10T14:02:25 Notice  opnsense    AcmeClient: using CA: letsencrypt   
2023-04-10T14:02:25 Notice  opnsense    AcmeClient: issue certificate: host.mydomain.com   
2023-04-10T14:02:25 Notice  opnsense    AcmeClient: certificate must be issued/renewed: host.mydomain.com
Obviously, this is in reverse chronological order.

I've obfuscated a few things, but, I do not think they are relevant to the issue.  The domain has the Gandi API enabled, the key works fine, etc etc.

What I do notice, however, is that the "dnssleep" option passed to the ACME shell script is being ignored.  I've tried various values here, 120 seconds, 240, 0 (default) - however, as you can see from the logs, within 2 seconds OPNSense records the attempt as a failure, and gives up.

Interestingly, even with "0" set as the value, the OPNSense plugin does not seem to re-try as per the on-screen note of:

The time in seconds to wait for all the TXT records to take effect after adding them to the DNS API. Defaults to 0 seconds, which causes Acme Client to check public DNS services every 10 seconds for up to 20 minutes. If set to a non-zero value, a fixed DNS sleep time will be used and the local DNS servers will be queried instead. A DNS sleep time of 120 seconds or more is recommended for some DNS APIs.

Does anyone have ACME working with 23.1 series and Gandi LiveDNS?