Messages

1

General Discussion / Re: I can't update: "Could not authenticate the selected mirror."

« on: May 30, 2022, 02:03:08 am »

Nevermind, I just figured it out. I had to remove the mimugmail.conf file that I must have placed in /usr/local/etc/pkg/repos/mimugmail.conf via CLI. Now it's working again.

2

General Discussion / Re: I can't update: "Could not authenticate the selected mirror."

« on: May 30, 2022, 01:53:29 am »

Well, https://opn-repo.routerperformance.net is a third party repo. You can't get around that by switching a mirror, you need to deinstall it.


Cheers,
Franco

Hi Franco, I went to System->Firmware->Plugins and removed all the orphaned plugins but still when I click "Check for updates" it errors out the same way.

Do you know what I need to do to completely purge the https://opn-repo.routerperformance.net from my opnsense installation?

3

General Discussion / Re: I can't update: "Could not authenticate the selected mirror."

« on: April 22, 2022, 03:24:14 pm »

Use a HTTP mirror to update to 22.1.x, then try a HTTPS one again to see if the issue sticks or has been solved.


Cheers,
Franco

Thanks Franco, I tried setting a few different HTTP mirror on the Settings page but saving that and checking for updates again still produces the same error messages. It doesn't look like that mirror selection has any effect on the server that it's complaining about. I tried several values in the Mirror and saved. The result always shows:

Code: [Select]

pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:12:amd64/packagesite.txz: Authentication error

can you issue on the console a command for the failing mirror like:

Code: [Select]

# curl -vI https://opn-repo.routerperformance.net/repo/FreeBSD:12:amd64/packagesite.txzand

Code: [Select]

# openssl s_client -connect opn-repo.routerperformance.net:443 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' | openssl x509 -noout -text

I definitely see the same problem at the command line interface and it says that the cert is expired. I guess I need to update those, do you guys have a process for updating those manually?

Code: [Select]

spikeygg@opnsense:~ % curl -vI https://opn-repo.routerperformance.net/repo/FreeBSD:12:amd64/packagesite.txz
*   Trying 46.16.78.247:443...
* Connected to opn-repo.routerperformance.net (46.16.78.247) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /usr/local/etc/ssl/cert.pem
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, certificate expired (557):
* SSL certificate problem: certificate has expired
* Closing connection 0
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
spikeygg@opnsense:~ % openssl s_client -connect opn-repo.routerperformance.net:443 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' | openssl x509 -noout -text
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:1
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
notAfter=Sep 30 14:01:15 2021 GMT
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=10:certificate has expired
notAfter=Sep 29 19:21:40 2021 GMT
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
notAfter=Sep 29 19:21:40 2021 GMT
verify return:1
depth=0 CN = opn-repo.routerperformance.net
notAfter=Jun 12 23:11:08 2022 GMT
verify return:1
DONE
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:98:a7:76:0a:f4:ad:09:65:d3:35:f4:16:97:01:86:1f:22
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = R3
        Validity
            Not Before: Mar 14 23:11:09 2022 GMT
            Not After : Jun 12 23:11:08 2022 GMT
        Subject: CN = opn-repo.routerperformance.net
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:e5:0f:ab:95:f7:25:b9:b4:d9:bd:75:63:3b:26:
                    fc:c2:39:75:94:fd:7d:10:07:7f:6a:f6:0f:8d:59:
                    8b:2e:e1:65:e6:1e:5d:51:ac:fc:ac:74:d7:0b:88:
                    2b:62:00:d3:ed:34:2e:c9:a4:35:f0:6c:ef:73:21:
                    47:01:b8:cc:fb:d9:6a:17:f4:8b:a0:06:6e:19:e7:
                    40:9c:d1:83:d3:ec:bf:2f:33:a4:0c:be:df:33:2a:
                    ad:db:3c:d3:36:86:2e:ff:a6:93:16:ee:64:a6:2c:
                    db:a4:77:f4:e7:99:6f:a5:77:b7:1d:81:4b:ae:ba:
                    86:c2:29:ba:08:2c:93:44:df:26:0d:2f:50:06:77:
                    29:34:b3:9b:34:fa:04:4b:a6:80:df:7b:84:d2:67:
                    c4:43:99:48:f0:fa:8f:be:8b:1c:ed:33:5e:50:2d:
                    8b:82:34:b5:97:41:05:05:0f:8e:f2:71:90:f1:7c:
                    be:1c:13:51:b5:30:40:a2:2f:bc:d5:33:c7:f3:32:
                    bd:33:b2:4c:97:c8:27:75:65:e4:fb:59:e1:f6:62:
                    55:7c:8b:3c:be:9a:16:72:f2:50:75:79:7c:4a:92:
                    6d:d6:98:3d:e7:02:4b:9d:1a:b4:67:5f:a3:84:bb:
                    8f:6e:85:61:aa:99:bc:72:fb:ca:71:39:fb:96:b3:
                    62:8f:b2:56:68:b5:3a:48:95:8b:fe:9d:94:8a:f9:
                    99:72:fd:c1:80:2d:2b:f6:0f:10:33:b3:b2:43:9d:
                    1e:4e:60:9f:5a:43:24:80:0b:a6:8d:d9:1e:b0:04:
                    1c:e7:a6:c6:51:c0:e4:61:a6:d7:da:77:a5:8d:82:
                    94:d2:37:4d:66:c4:62:15:81:6a:d1:cf:2e:ab:bb:
                    98:f3:6d:12:d7:f7:10:fd:5d:3b:12:94:4a:3f:b2:
                    0b:82:b7:be:e3:2d:2a:d1:12:c9:e6:c7:9a:1a:de:
                    5d:bc:52:83:63:6a:a4:e8:b5:82:b5:0e:41:15:bf:
                    e8:82:ca:9e:18:d1:20:be:9a:32:d2:bd:c0:fb:ad:
                    45:44:31:d9:da:5f:3a:eb:75:10:df:b9:ca:e2:95:
                    0b:5f:4b:73:06:38:45:4d:c5:08:af:53:e9:8b:6c:
                    57:c3:2b:83:87:a2:37:8b:5f:9a:5f:f1:ed:ea:e5:
                    69:94:d5:5e:2d:1a:6a:e4:f6:ef:97:41:85:d0:76:
                    30:67:dc:2b:69:a1:90:54:71:a5:40:8f:2a:60:0f:
                    ce:46:63:cf:86:ff:63:2e:5d:26:01:2d:14:7a:0e:
                    65:8c:89:38:e4:6e:23:b8:9d:78:20:f5:73:a3:4c:
                    db:61:aa:63:7f:77:c0:36:b6:3e:16:a6:69:15:23:
                    dd:3c:7b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                7A:0D:A2:1D:52:AE:91:F3:CB:F2:12:9B:AF:70:CB:74:DE:B8:BE:99
            X509v3 Authority Key Identifier:
                keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

            Authority Information Access:
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/

            X509v3 Subject Alternative Name:
                DNS:opn-repo.routerperformance.net
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org

            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : DF:A5:5E:AB:68:82:4F:1F:6C:AD:EE:B8:5F:4E:3E:5A:
                                EA:CD:A2:12:A4:6A:5E:8E:3B:12:C0:20:44:5C:2A:73
                    Timestamp : Mar 15 00:11:09.460 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:E5:C2:5F:BD:CD:08:8E:8C:97:50:A6:
                                92:4A:AF:11:2B:02:D2:E4:90:64:83:05:02:41:68:73:
                                D1:22:7A:90:B0:02:20:47:A9:B4:01:39:2F:83:B9:73:
                                78:0F:D9:63:F0:64:58:38:39:43:DD:99:B2:C5:41:88:
                                D1:CA:05:6D:4A:72:79
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 29:79:BE:F0:9E:39:39:21:F0:56:73:9F:63:A5:77:E5:
                                BE:57:7D:9C:60:0A:F8:F9:4D:5D:26:5C:25:5D:C7:84
                    Timestamp : Mar 15 00:11:09.451 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:2C:54:83:86:C9:20:83:11:59:FC:5A:AD:
                                C5:F3:CD:DA:C4:67:4C:16:01:4D:9C:37:0D:D5:46:47:
                                B0:90:ED:B8:02:20:4F:5A:5A:CE:EB:EC:9A:40:2B:7A:
                                CC:B2:31:D2:A4:AB:27:E2:C3:51:C0:E5:A0:C7:C3:43:
                                2A:E1:8C:7C:D1:C2
    Signature Algorithm: sha256WithRSAEncryption
         1a:64:ff:af:c6:bc:6e:ba:dd:36:14:d6:7d:bf:5b:28:77:de:
         3f:d0:ed:2e:de:08:88:70:3f:ba:7e:39:40:e8:56:7b:01:6a:
         8b:ba:36:1d:7c:bb:27:d2:36:f5:ab:14:9c:26:57:53:40:70:
         ae:6d:1c:87:3d:2f:f9:16:2e:34:1b:91:9c:9e:1c:5b:57:d7:
         82:e6:29:08:62:c6:e8:9e:e2:38:cf:77:58:18:08:35:a0:99:
         65:44:f8:9b:fc:01:b9:4a:b2:83:98:bd:fc:03:1c:0b:8e:2a:
         63:88:74:80:dd:d5:fa:ca:af:6f:79:35:ed:c2:e8:cf:15:99:
         a2:8c:04:3b:da:8d:9d:25:61:8b:e5:da:ec:3b:a8:0e:42:02:
         45:d0:e4:8f:52:20:a1:c7:9c:c2:9d:07:3d:9e:b7:73:6c:18:
         6e:39:29:ef:ab:77:aa:43:b1:13:29:7a:2a:3f:0e:3d:00:83:
         ad:96:54:f9:91:4b:c3:1b:9e:63:01:c0:b8:24:db:d3:c2:66:
         e1:c1:cc:ab:ad:f7:eb:f4:ee:0c:88:92:0f:da:5e:1b:46:9e:
         67:4e:68:78:ec:4e:64:95:fc:c4:53:30:52:5b:10:5a:7a:04:
         3c:3e:10:e3:0f:64:e7:0d:88:2d:57:b1:12:ed:ce:84:1f:95:
         d8:2a:61:3d
spikeygg@opnsense:~ %


4

General Discussion / I can't update: "Could not authenticate the selected mirror."

« on: April 21, 2022, 02:46:56 am »

I tried System->Firmware->Status->Check for updates... and it spits out this:

Code: [Select]

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 21.7.2_1 (amd64/OpenSSL) at Wed Apr 20 18:39:04 MDT 2022
Fetching changelog information, please wait... done
Updating OPNsense repository catalogue...
pkg: Repository OPNsense has a wrong packagesite, need to re-create database
Fetching meta.conf: . done
Fetching packagesite.txz: .......... done
Processing entries: .......... done
OPNsense repository update completed. 777 packages processed.
Updating mimugmail repository catalogue...
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
2619649490944:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
2619649490944:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
2619649490944:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
2619649490944:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
2619649490944:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
2619649490944:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:12:amd64/meta.txz: Authentication error
repository mimugmail has no meta file, using default settings
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
2619649490944:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
2619649490944:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
2619649490944:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:12:amd64/packagesite.txz: Authentication error
Unable to update repository mimugmail
Error updating repositories!
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***
Then says: "Could not authenticate the selected mirror."

I found a few threads on the message board.
1) SSL cert check, my files exist and are non-zero size
2) Check date and time -- looks accurate with my phone/PC
3) Someone suggested deleting the fake let's encrypt cert, I tried that, it didn't help.

Other ideas? What else can I check? My whole network seems to be functioning correctly. Not sure why opnsense is complaining about this.

Thanks,
-Greg

5

20.7 Legacy Series / Re: nginx won't start "Address is already in use"

« on: February 14, 2021, 05:31:20 am »

I did relocate the OPNsense web gui ports already. Also, the NGINX server was started and working, I saw it acting as a reverse-proxy before and I was tweaking the config files and tried to restart it and it never came back on...

6

20.7 Legacy Series / nginx won't start "Address is already in use"

« on: February 14, 2021, 05:29:49 am »

I'm trying to set up the nginx plugin on my OPNsense and it seems I keep running into this problem where I try to restart the service and it completely breaks. Now when I try to start it, I get this:

Code: [Select]

root@opnsense:~ # service nginx start
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Starting nginx.
nginx: [emerg] bind() to unix:/var/run/nginx_status.sock failed (48: Address already in use)
nginx: [emerg] bind() to unix:/var/run/nginx_status.sock failed (48: Address already in use)
nginx: [emerg] bind() to unix:/var/run/nginx_status.sock failed (48: Address already in use)
nginx: [emerg] bind() to unix:/var/run/nginx_status.sock failed (48: Address already in use)
nginx: [emerg] bind() to unix:/var/run/nginx_status.sock failed (48: Address already in use)
nginx: [emerg] still could not bind()
/usr/local/etc/rc.d/nginx: WARNING: failed to start nginx
root@opnsense:~ # ps auxww |grep nginx
root     24076   0.0  0.0 1060888  3196  0  R+   21:25       0:00.00 grep nginx
root@opnsense:~ # service nginx status
nginx is not running.
root@opnsense:~ # ls -la /var/run/nginx*
-rw-r-----  1 root  wheel  0 Feb 13 20:40 /var/run/nginx.pid
srw-rw-rw-  1 root  wheel  0 Feb 13 20:40 /var/run/nginx_status.sock
root@opnsense:~ #

I found this thread from the 19.1 Legacy Series archive but there was no resolution. As you can see the nginx service isn't running. I've tried deleting the 0-byte files in /var/run and they just get recreated when the service start is attempted.

I tried removing a lot of the config options I set in the nginx plugin options but it still doesn't start up. I think it gets thrown into a broken state and can no longer be started. Any ideas on how to troubleshoot this?

7

General Discussion / Re: Unbound DNS cannot flush out stale DNS entries

« on: December 22, 2020, 11:23:02 pm »

Through some trial and error, I think I may have just figured out a way to make this happen in a super annoying round about way:

• Go to DHCP server settings and change the DHCP lease time to be very short (3 minutes or something)
• Plug in the device, have it register to get short lease so its MAC address gets recorded
• Unplug device
• Copy MAC address
• Wait for the lease to expire
• Restart Unbound DNS
• Create static entry for device

I've found that even after the DHCP server removes the lease due to the expiration the Unbound DNS server STILL serves that DNS entry. You have to restart the service for it to realize that the entry is no longer valid and remove it.

This feels super janky but it works. If anyone has a better way to do this please let me know.

Thanks,
-Greg

8

General Discussion / Unbound DNS cannot flush out stale DNS entries

« on: December 22, 2020, 11:07:26 pm »

 I've been using OPNsense for a bit and one thing I do a lot these days is add more IoT devices to my LAN. I have the biggest problem with removing the stale DNS DHCP entries from the system. I'm curious how to go about doing this in a way that works every time.

 The problem occurs when I try to set up a new device. I program it to hook up to my WiFi with DHCP because I don't know what the MAC is, yet. It gets a randomly assigned DHCP IP from the pool and shows up in the leases list. At this point, it becomes part of the DNS results because Unbound records the DHCP lease data in its DNS entries. I can see this with `nslookup <name> <opnsense>` from other computers on the network.

 Now that I have the MAC I can go in and add the static entry on the DHCP server but then the nslookup results show both the old pool IP and the new static IP. I cannot get the old pool IP to go away!! I tried restarting the DHCP server and restarting Unbound DNS server multiple times but the entry won't go away.

 I have even tried disconnecting the device, waiting for OPNsense to recognize that the device is offline but the lease is out there and clicking the little trash icon next to it to delete the entry from the DHCP server but when I use nslookup and force it to use the root DNS server it STILL resolves (even after restarting Unbound and DHCP servers)! What gives??

 Just about the only way I've found that ALWAYS works so far is to reboot the router but that takes 2-3 minutes and the internet is down at my house during that time so I'd like to find a way to do this that doesn't involve a restart.

 Unfortunately, because these are IoT devices, there's no easy way to get it to issue a "ipconfig /release" to tell the DHCP server that they're done so I have to do this from the router's side.

Thanks,
-Greg
Do I have to wait for the lease to expire?

9

Tutorials and FAQs / Help! VLAN rule isn't always applying...

« on: November 26, 2020, 06:41:27 pm »

In an effort to learn networking, I'm migrating my home network to take advantage of VLANs. I've set up OpnSense and hooked everything up and I'm trying to get the rules situated but they're not making sense to me now.

I've got a "management" VLAN10 a "client" VLAN20 and a "wifi" VLAN30.

VLAN10 has a hassio host (for home assistant) [172.27.10.5]
VLAN20 has skeeter my desktop computer [172.27.20.4]
VLAN30 has pixel my phone [172.27.30.40]

I wrote a very simple rule in the VLAN20 ruleset to allow skeeter to connect to hassio, works great! But for the life of me, I cannot figure out why I can't write the same rule for pixel and have it work on VLAN30.

I've attached the live log that I captured showing both blocking and passing packets that look identical! Also my rule set for VLAN30 and VLAN20. I have skeeter listed as one of the "management_hosts" so it matches that top rule immediately when I connect skeeter to hassio. I created the top two rules on VLAN30 to try to allow pixel to connect but it's still being blocked.

Please help me solve this, I really want to understand where I'm missing understanding on this...