Messages

Thank you for posting this!

I've been working on the automation of my certificate renewals and this showed up at a good time.  Your script is well thought out and now I am using it for the opnsense renewals.

The other one I have seen was in this topic : https://forum.opnsense.org/index.php?topic=53086.0

I think maybe you misunderstood the firewall rule in this topic.  It says for traffic arriving at the WAN address, redirect (or forward for ipv6) to the local network address.

So what I thought was an IPv6 problem with the DNAT rule was actually a more general failure of the rule.  Because there were multiple IP addresses for IPv4 in the alias (due to using the MAC address type with hostwatch), I believe that the supporting automatic pass rules did not get created at all.  Once the alias was set up to only have one IPv4 and one IPv6 it worked.  I will mark this issue as solved.

I didn't think to look at the alias, but you are absolutely correct that this is where my problem lies.  Because I am using a MAC-based alias, it contains a whole bunch of other IP addresses that are no longer valid (dhcp addresses from before I set up the static host).  I did not realize that MAC-based alias would pull every IP that was ever associated with it.  It doesn't look like there is a way to remove the now invalid addresses.  For now, I have created host based alias and pointed it to two new aliases (one with ipv4 address and one with dynamic prefix for ipv6).  This works long term but with the cost of more alias names. I thought the whole idea of hostwatch was to be able to reduce this.  Isn't there any way to remove these now invalid IP addresses?

I have a dual-stack network and I have had the attached DNAT firewall rule in place for at least a year which allows me to access my internal applications from the internet.  This redirects/forwards the traffic to my internal nginx server.

I created a brand new server to address some security concerns I had with the previous server.  I updated the MAC address for the existing alias that I created for the old nginx server, but now I am not able to access my applications externally.  I think that opnsense creates firewall rules "behind the scenes" because I have specified Pass for the firewall rule item.  Because of this, I thought maybe it would work if I deleted and re-created the rule.  Unfortunately this did not solve the problem.

I am on 26.7.5 and migrated my old firewall rules to the new rules back in February.  Is this a regression introduced recently or am I doing something wrong?

I don't understand why you wouldn't connect the mesh router to the switch.  This is the correct location and it should be setup in AP mode.  There is no reason for VLANs just to connect a mesh system.  You might want VLANS for other purposes, but it is not needed to connect a mesh system.

If you're not able to read and understand release notes before updating critical components, OPNsense may not be the correct solution for you. Consider switching to a consumer product.

Sounds kind of harsh.  I agree that this is not a typical consumer product and that it requires users to understand what is impacted before blindly pressing the upgrade button.  On the other hand, I think that the release notes might better identify breaking changes to flag users where more research is needed.

If you used these instructions to setup dnsmasq, then dnsmasq would be configured with a different port (53035) than unbound (53).  This way, only unbound is used for normal dns and other clients cannot access dnsmasq via 53053 unless you create a rule for it.  The instructions also discuss reverse lookups which is basically done the way you have already configured.

Edit: link to instructions:  https://docs.opnsense.org/manual/dnsmasq.html

I am able to update the certificate in place using the APIs as indicated above.  I cannot get opnsense to use the updated certificate, however.  I have tried issuing an API call to restart the webgui and I have tried calling reconfigure in the trust section.  None of these force opnsense to use the new certificate.

These are the API calls I have tried:
POST  /api/core/service/restart/webgui
POST  /api/trust/settings/reconfigure

EDIT:  I did some more investigation and testing and the GUI uses /api/core/service/restart/webgui, but it uses the web sessionid for authentication.  When I call it using the API token, I receive an error - curl: (16) Error in the HTTP2 framing layer.  It doesn't seem like I can trigger a webgui restart using the API from my script.  As a workaround, I am now executing 'configctl webgui restart' from my script using SSH.  This works, but it is not as clean.

I have this working perfectly with pihole.  There are other variations you could do, but this configuration has been stable for me since dnsmasq was implemented in opnsense.

Start with configuring dnsmasq with this document:  https://docs.opnsense.org/manual/dnsmasq.html

Next add pihole address via dns-server [6] in dnsmasq

Point pihole upstream server to opnsense (Unbound)

DNS flow (for local domain) is client -> pihole -> Unbound (opnsense) -> dnsmasq (opnsense)
DNS flow (for internet) is client -> pihole -> Unbound (opnsense)

How do you install the agent?  I attempted to run with the freebsd install script that gets automatically generated.  The process was running, but didn't seem to be listening so something wasn't correct.  It seems that the script may still set things up with beszel as the user.  This is the command I used (ran as root).  I obviously used the token and key that got automatically generated (instead of my_token and my_key).

curl -sL https://get.beszel.dev -o /tmp/install-agent.sh && chmod +x /tmp/install-agent.sh && /tmp/install-agent.sh -p 45876 -k "ssh-ed25519 my_key" -t "my_token" -url "https://beszelhub.mydomain.com" 

Edit:  I was able to solve my own problem.  The process was actually running and listening.  I just had to allow an IP for my reverse proxy.

Unless you have a specific need, you might consider ditching DHCPv6 by using RA-STATELESS (instead of SLAAC).  There really isn't a need to assign addresses if the clients you need to reference are using EUI-64.  While identity association makes firewall rules easier to manage now, having fewer IP addresses is still easier to manage. YMMV

How do I configure this option?

I used the configuration example right out of the dnsmasq documentation (https://docs.opnsense.org/manual/dnsmasq.html#configuration-examples).  The only difference is that I used RA-STATELESS and RA-NAMES for the RA Mode.

RA-NAMES uses the MAC address to register the IPv6 address, so you have to have an IPv4 address along with MAC in order for it to match using the EUI-64 address.

I am using dnsmasq with SLAAC and RA-NAMES.  This allows dnsmasq to register IPv6 addresses for clients that use EUI-64 address.  I find this to be very convenient.  It doesn't help with privacy addresses, but I generally don't need to reference those clients by name anyway.