Messages

If you have any trouble let me know and I can help you or potentially fix it. I maintain that plugin.

Forgot to revisit this and update the thread!  Got this working.  Only thing I don't like is leaving port 80 open, so I've only been allowing it when I want to manually trigger a renewal.    Does Caddy respond at all to port 80 requests when the host hasn't opened it up for validation?

I had never seen caddy before, but I'm looking into it and might give it a go.  NGINX configs can be pretty complicated, and there are some things that I just think the OPNsense web interface doesn't handle.

I'm trying to set up multiple FQDN's to be accessible for acme-challenge requests behind OPNsense.  I want publicly signed certs on the hosts, but the internal traffic to and between the hosts can't or shouldn't go back through NGINX, so using Let's Encrypt in NGINX won't work for these certificates.

I have unique Upstream Servers, Upstreams, and HTTP servers defined for each, but when I try and add multiple locations with the same URL Pattern (/.well-known/acme-challenge/) so that I can restrict  external requests to only hitting that path, NGINX won't start, and generates the following error message.

Code Select Expand

nginx: [emerg] duplicate location "/.well-known/acme-challenge/" in /usr/local/etc/nginx/nginx.conf:1199

I assumed I could have Locations with the same pattern referring to different upstreams and referenced by different HTTP servers, but must have to do this a different way?

It was Crowdsec..  a little new with this stuff, but found it Firewall->Diagnostics->Aliases->crowdsec_blocklists, purged that list, all of which were in the subnet that I was having trouble getting to, at a WordPress hosting provider..

I have one website I use for work that does not work through OPNsense.  There may be other sites, but one that I am aware of.  I'm running Unbound, Crowdsec, Suricata on the WAN interface, and Zenarmor.

I can use curl to get to it from the CLI of OPNsense, but it won't load from clients behind OPNsense, and it still fails from clients behind the firewall with all three of those (Crowdsec, Suricata, Zenarmor) disabled, well at least I attempted to disable them, not sure if the Crowdsec rules are still in effect or not.. 

Unbound logs show name resolution, plus i do see the outbound request in the packet capture on the client. Firewall logs don't even show any traffic to the destination IP that DNS and packet captures from the client show the traffic should go to.  Traceroute from clients behind OPNsense doesn't show a response from the next hop, which would be OPNsense..   

If I go to Reporting->Insight->Details and filter for the destination IP, I DO see matches on the LAN interface, but not on the WAN, so something on the firewall appears to be dropping the packets.  The IP is in a subnet that seems to go through clouldflare and is hosted by wordpress host WPEngine.  Any thoughts on where I can look to see where it's failing?

ddclient doesn't seem to work with duck dns tokens in it's current state.   Form requires you to enter a password, which isn't required for the token auth to work at Duck DNS and with the dyndns plugin.  Probably needs another update to allow validation with a blank password similar to the one which allowed for upper case characters in the username??

had os-ntopg-enterprise installed, which stopped working after upgrading.  I removed the package and reinstalled the version for FreeBSD 13 via:

pkg add https://packages.ntop.org/FreeBSD/FreeBSD:13:amd64/latest/ntop-1.0.pkg

The package still does not show in plugins.  Is there a new process specific to FreeBSD 13 to follow to install the enterprise version of ntopg?

21.7.7

That would explain why it doesn't work, though interestingly it was there in the install image, and resolved the issue during installation.

I noticed that if you look at the output of "sysctl -a", the following is set:
kern.random.random_sources: 'Intel Secure Key RNG'
Not sure if changing that is an option if the boot loader for random.trust_cpu doesn't work

Booting from install image, the console was bombarded with the following line:
random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.

I was able to get past that by adding the following boot loader option:
set random.trust_cpu=off

That enabled me to do the install. After the install, I continue to get those errors, and believed that if I created a similar entry in System->Settings->Tunables, that would take care of the issue, so I created the following setting there:

Tunable: random.trust_cpu
Value: off

If I look at /boot/loader.conf the entry shows up as:

random.trust_cpu="off"

So, it LOOKS like the entry from Tunables is there, but the message continues to flood the console.