Messages

for the past few update checks I have been having this issue where just the mimugmail repo won't update:

Code Select Expand

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 23.1_6 at Fri Mar 10 10:23:09 PST 2023
Fetching changelog information, please wait... done
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 816 packages processed.
Updating mimugmail repository catalogue...
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:13:amd64/meta.txz: Operation timed out
repository mimugmail has no meta file, using default settings
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:13:amd64/packagesite.pkg: Operation timed out
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:13:amd64/packagesite.txz: Operation timed out
Unable to update repository mimugmail
Error updating repositories!
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***

In trying to debug, I log in via ssh and I noticed I cannot curl from or ping opn-repo.routerperformance.net.  So I go to Interfaces->Diagnostics->Ping.  I cannot ping any address using IPv4 IF the source is set to 'default' if I set it to any of the options in the dropdown, it works fine.  If I set it to IPv6, it also works fine with the default interface. 

So it would appear that I have an IPv4 issue only from the firewall itself?  I assume the repository for the OPNSense itself is reachable via IPv6? I'm lost, hoping for some help.

@adk20 - mine show exactly the same. 

I'm mostly concerned with the "Cannot Fork" error as It doesn't seem like it finished cleanly.

If it matters I was coming from 21.7, so I am pretty sure a restart should have been required

I just tried to update to 21.7.3_3... it got all the way through and was updating the base image.  Installed the kernel ok, then the next step was base... then I got "Cannot fork: Operation not permitted" followed by "**DONE**"

It did not reboot, even though it should have.  Now I do not know what to do and fear in I am in an unstable state.  Can anyone assist?

@Thomas_L When I go to the User Management tab and enter users there they do not appear in the Config Export file at all.  They seem to be completely ignored.  That is, entering them there, they cannot be used for auth at all.  This USED to work, but one of the recent updates it broke (maybe with 21.1).  However, if I enter the users in the bypass field I can use as normal.  If you wouldn't mind sharing what you do that would be great!

I have a publicly exposed service that I want to prompt me for basic auth if I am connecting from outside my local LAN.  I accomplished this by:

• Make a condition for Source IP matches Specified IP, with 192.168.1.0/24, and negate condition checked
• Make a rule that if the above condition is true, then execute function http-request auth (from the "Execute Function" pulldown menu)
• Apply that rule to the backend
• In user management, create the users I want to be able to authenticate

That's it - it's worked fine for well over a year... then sometime in recent past, it stopped.  I get requested for authentication if outside my LAN, but no users will work.  So I go investigate the config file and there are no users in there.

So I go to Settings->Global Options->Custom options and I add:

Code Select Expand

userlist users
user me insecure-password password
Still nothing.

Did something change recently?  What am I missing here?

I keep seeing posts about people upgrading without reboots.  I sometimes think everyone is punking me.  Is this a thing?  How does one accomplish this?

Any issues with the list being so big?  I just don't know what a reasonable size is.

I am currently using AdGuard Home, but I would like to move to having this in my router...

Can I use the lists here: https://oisd.nl/?p=dl

And if so, which version.  AdGuard can use the AdblockPlus syntax (the first one)

Can't find any option regardin DoT, i've also added to the DNS over TLS field 1.0.0.1@853  (under miscellaneous tab) but on https://cloudflare-dns.com/help/ i keep on getting no to the DNS over TLS check.
Please could you tell us how to do it? Thanks.

@Massimo1993, try to restart the unbound service after you fill in the resolvers on the Miscellaneous tab.  That made it start for me.

But then I have a question: Does unbound then ignore the General-> Enable forwarding mode?  Because that is NOT currently checked for me, but my requests are being forwarded to my DoT provider.

I think you need a managed switch.  Ubiquity sells a 5-port one for $25 US, and you can get a a few around that price on amazon a well...

I'm a little confused...So when downstairs you want it to get an IP address in the 10.0.0.x network and when upstairs you want it to get an IP in the 10.0.1.x network?

If you have a fixed DHCP lease set up for the vacuum, then I don't know if this is possible.  Does the vacuum need to have a fixed IP address? 

You don't set up the TXT and CAA records manually.  When you set up th Validation Method, you did select DNS-01 as the challenge method and selected the Google Cloud DNS API as the service?  If all of that is correct, then it should create the TXT and CAA records for you when it tries to validate the cert.

You may need to increase the delay value as it has to wait long enough for cache to timeout so Google will get queried for the records.

This is exactly what HAProxy is for.

https://docs.opnsense.org/manual/how-tos/haproxy.html

My setup is like so:

I have HAProxy bound to 127.0.0.1, and then I do a port-forward from the WAN port 443 to 127.0.0.1.  I did this because I have an IP issued over DHCP from my ISP and I only wanted HAProxy listening on the WAN interface.

If I change HAPoxy to bind to 0.0.0.0:443, then it works.  I guess what I don't understand is in my original way, I can get to NextCloud from the Internet and every machine on the LAN, but it will not work from the router itself.  Any clues?

I have HAProxy running on my WAN.  One of the services it serves is my self-hosted nextcloud server, located on my LAN.   From my LAN, I can go to cloud.mydomain.com, which resolves to my WAN IP and everything is fine.  From the internet, I can do the same. 

However, in the System->Configuration->Backup, when I put https://cloud.mydomain.com in the URL field, the backup test fails.  In the logs I see that it's not resolving the domain name:

Code Select Expand


{"url":"https:\/\/cloud.mydomain.com\/remote.php\/dav\/files\/steve\/","content_type":null,"http_code":0,"header_size":0,"request_size":0,"filetime":-1,"ssl_verify_result":0,"redirect_count":0,"total_time":60.005564,"namelookup_time":0.004236,"connect_time":0,"pretransfer_time":0,"size_upload":0,"size_download":0,"speed_download":0,"speed_upload":0,"download_content_length":-1,"upload_content_length":-1,"starttransfer_time":0,"redirect_time":0,"redirect_url":"","primary_ip":"","certinfo":[],"primary_port":0,"local_ip":"","local_port":0,"http_version":0,"protocol":0,"ssl_verifyresult":0,"scheme":"","appconnect_time_us":0,"connect_time_us":0,"namelookup_time_us":4236,"pretransfer_time_us":0,"redirect_time_us":0,"starttransfer_time_us":0,"total_time_us":60005564}


What I've checked:

   
• In Interfaces->Diagnostics->DNS Lookup, get resolution on cloud.mydomian.com
• From command line: ping cloud.mydomain.com pings my WAN interface
• From command line: dig cloud.mydomain.com returns WAN IP
• From command line: host cloud.mydomian.com returns WAN IP