Topics

[are not]

I'm seeking to reestablish wildcard certs through Let's Encrypt using the ACME client.   My DNS provider (and registrar) is EasyDNS.  On pfSense, EasyDNS was listed in the DNS challenge section as a provider and it just worked.  I think I had my wildcard cert established in under a minute of my first attempt.

OPNsense does not list EasyDNS as a DNS provider in the challenge set up.  When I migrated (21.1) I let it go to figure out later.  Later is now.

I'm no developer, but I've been a CLI guy for over 30 years, and from what I can see EasyDNS is included in the ACME client package OPN is using, and is present in both the examples and the running folders:

Code Select Expand

root@OPN:/usr/local/share/examples/acme.sh/dnsapi # ls -l dns_easydns.sh
-r-xr-xr-x  1 root  wheel  4426 Feb  4 00:53 dns_easydns.sh


Code Select Expand

root@OPN:/var/db/acme/.acme.sh/dnsapi # ls -l dns_easydns.sh
-r-xr-xr-x  1 root  wheel  4426 Feb  4 00:53 dns_easydns.sh


Searching has not led me to specific answers about easydns, nor have I had the right search terms to find a information speaking about how particular API clients might be enabled or disabled in OPN.   I have found others posting where the OPN GUI offers APIs which are not supported by the installed ACME (https://forum.opnsense.org/index.php?topic=18476.0) but that's the opposite of my issue (and I've seen comments not to do what the OP did in that thread).

Do I have any options here to get this DNS API working in a "clean" way, supported in config backups and across updates/upgrades? (like it did, and still appears to, in pfSense).   

If not "clean", I'm open to recommendations on the "least unclean" ways to do this automatically.

Hi all:

Late last week I updated from 21.7 to 22.1.  I did an upgrade in place.  After some brief testing I did a reinstall with config import to move from UFS -> ZFS for the rootfs.   Again, other than having to separate restore zenarmor configs from separate backups everything seemed OK.

In more detailed use over the next couple of days I discovered a small handful of issues.  One is that mdns-repeater doesn't seem to be doing anything any longer.  I have - verified the config, checked that it's running, stop/start, enable/disable, uninstalled and reinstalled, rebooted firewall.  I don't see mdns-repeater logging anywhere on the system.

I have also exhaustively gone through all of the firewall rules which took me a fair bit of time to develop 18 months ago or so to allow a VLAN where my kids' devices are to cast to my entertainment devices on another VLAN.   All of the rules to allow traffic to flow between devices (printers, chromecasts, TV, AVR) seem to be working but anything requiring mDNS doesn't find anything to connect to.  On a test laptop Bonjour Browser is empty and google Chrome shows nothing available in the Cast-> function from the kid VLAN.  I see multicast traffic to UDP/5353 hitting "pass" rules on both interfaces.

One potentially different config I have that might be uncommon which arose due to the way my home LAN evolved - my main LAN is untagged and many other VLANs (including the kids) are tagged on the same physical interface.  i.e. the LAN with the devices I want to case to is on igb1 and those attempting to cast are on igb1_vlanX.  This worked prior to 22.1, zenarmor and other software is still working fine from what I can see.

Anyone else?

I've observed this in 21.1.5 and 21.1.6.  I was occasionally finding that local name resolution wasn't working on the firewall.  My first sign of trouble would be alerts that the UPS netclient could not reach the server (because its name didn't resolve).

In Systems -> Settings -> General I have three DNS servers for the local system: 127.0.0.1, 1.1.1.1 and 8.8.8.8.  These are populated in resolv.conf normally.

In VPN -> Wireguard -> Local -> {config for first instance} I had populated DNS Server with the local end of my Wireguard point-to-point network.  (I believe some guide or testing when I first set this up led me to do this).  I have two site-to-site WG tunnels.

For DNS I use unbound in recursive mode, with local DHCP record insertion, listening on all interfaces.

When Wireguard cycles (restarted, toggled on/off, tunnel re-establishes after some kind of WAN transition) resolv.conf will be overwritten with the single entry from the Wireguard config.  It appears that unbound is not binding or not responding on the WG interface so DNS resolution for the firewall itself begins failing.  Some functions may have been falling through to an Internet DNS server but local records did not resolve.  I can do further testing and documentation if requested.

I removed the DNS setting and this seems to have stopped.  When testing site-to-site tunnels and traffic, I do believe that the WG interface answered DNS queries from remote tunnel peers.

I'm not so sure that the WG DNS setting whose help text is "Set the interface specific DNS server." should override all nameservers in /etc/resolv.conf when the tunnel transitions.  Although, IMO unbound should have answered queries at that address based on the other settings I see.

The limits of my experience make me unsure whether this is a bug, or at least an opportunity to add another sentence to the help text pointing out to users that filling in the WG DNS config option will override all the system nameservers.   I would perhaps expect it to APPEND the nameserver to the existing list in resolv.conf when the interface comes up?

[ though not necessarily about the VPN configuration itself, the config and workarounds required are because I'm using VPN and dealing with the quirks and requirements of VPN topology.  I thought it worth asking here because others running VPNs would have the same issues ]

OPN system at home with Wireguard site-to-site to two other sites.  The other sites are Edgerouter ER-X (vyos) and OpenWRT.  I control all sites.

There's been a bunch of troubleshooting, trial and error, and log watching but things are almost there.  The last hurdle was getting DNS for private namespace working over the tunnels.

I'll oversimplify with this example: My home and the hub site is "me.lan" on 10.0.0.0/24, one spoke is "sub.me.lan" on 10.0.1.0/24 and the other is "different.lan" on 10.0.2.0/24.  Both spokes run dnsmasq, one in the router the other on a pihole.  Each required a domain forward for me.lan to my firewall LAN interface and a corresponding permit rule.  The key thing causing DNS not to work was requiring to specify the source interface on the spoke's instance of dnsmasq.  Without specifying the internal interface as source it was querying from the WAN interface instead of over the tunnel and this didn't work. 

In dnsmasq this was '/me.lan/10.0.0.1@10.0.1.1'   and  '/me.lan/10.0.0.1@10.0.2.1' respectively.  This now works perfectly.

My last step is getting spoke site DNS working from hub site which is the OPNsense site running unbound in non-forwarding resolver mode with some blacklists, hardened DNSSEC etc...

In Services -> Unbound -> Overrides I have configured 'sub.me.lan -> 10.0.1.1' and 'different.lan -> 10.0.2.1' but it's not working and the first thing I want to look into is the same thing which fixed the spokes - ensuring that I'm sourcing the forwarded queries from an interface where routing, tunneling and permit rules will work accordingly.   I have found unbound documentation indicating how to set a non-standard port for these forwarded queries but no way to specify a source interface or IP address.

I would like to stick with unbound at the hub site.  I am thinking that I could alternatively add a dnsmasq instance on the hub fw on a non-standard port, configure unbound to forward to it and then dnsmasq to forward to the spokes using the same config as the spokes but if there's something simpler that I'm missing I'd like to do that before adding the layer of complexity just for a pet project.

Hi:

I'm fairly new to opn, I was running pf until about a month ago.  I'm also fairly new to IPv6.  I'm not new to networking in general.  I'm running 21.1.4 w/ LibreSSL right now.

In a home setting I'm working through enabling IPv6 on my internal nets in a somewhat structured manner.  Right now I'm at my kids/guest VLAN and it's highlighting some shortcomings.  This mostly revolves around the DHCPv6 server system not gathering hostnames as part of its work.  I've done some searching and reading but no posting on this until now..

I have read that it is not mandatory to collect hostnames and, potentially, ISC dhcpd just doesn't.  I've read that people have had success getting hostnames inserted into DNS by configuring "full" dynamic DNS updates to local servers in a more enterprise/advanced homelab setting, with an AD server and that sort of thing.  That's not my situation so I don't think that's my solution.  I have read that going fully static with everything can result in hostnames being inserted into local DNS.

I am using unbound in non-forwarding mode with a blacklist or two configured.  I am running both ntopng and sensei (I'll pick later) and what I really notice is not being able to look at the reporting and tell what is doing what when IPv6 is enabled other than long strings of full v6 IP addresses.  I could assign all statics, but it's a lot of devices and there will still always be new or "visiting" devices that won't be covered.  I use static IP in some places (infrastructure equipment mostly), DHCP leases in others (backup for the first category, and devices requiring any special port mapping or firewall rules like printers, game consoles), and I'm quite happy with dynamic addressing with lease injection into unbound for all the other stuff...

Is there a fix coming, or a workaround I've overlooked which could improve this area and maybe get this working?