Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - SpikeyGG

#1
With the release of OPNsense 26 and announcement of deprecating ISC-DHCP (which I was using) I decided to move to Kea DHCP. I went through the complete migration and everything was working great for a few weeks. Then I needed to do some maintenance in my wiring closet so I took the whole network down, performed the maintenance, and brought everything back up. All of it seemed to be working but then I realized that all my DNS records for dynamic DHCP addresses were pointing at the wrong host!

I'm using Kea DHCP with Unbound DNS. Previously, with ISC-DHCP taking the network down and bringing it back online would not cause any issues with static nor dynamic DHCP hosts. I was hoping that eventually the bad records would "work themselves out" but it has been over a month and they're still wrong. I can see the correct dynamic leases in Kea's "Leases DHCPv4" list but nslookups for the name always give a different IP. In fact, I even turned on the Kea DDNS Agent at port 53001 and when querying that service, it too has the wrong IP!

I tried a couple of times already to flush the Unbound cache and force it to rebuild but somehow it always finds/restores (or never removes) the bad records. I also have mDNS deployed and it seems to always be working great -- I'm not sure why but I also don't know how to use nslookup to query it (if that is even possible).

Here's an example the device "media-equipment" which is actually at 172.27.80.29 (see Lease screenshot), however, the .mynet address shows 172.27.80.19:
Microsoft Windows [Version 10.0.19045.7184]
(c) Microsoft Corporation. All rights reserved.

C:\Users\SpikeyGG>ping media-equipment.mynet

Pinging media-equipment.mynet [172.27.80.19] with 32 bytes of data:
Reply from 172.27.80.19: bytes=32 time=2ms TTL=254
Reply from 172.27.80.19: bytes=32 time=1ms TTL=254

Ping statistics for 172.27.80.19:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 2ms, Average = 1ms
Control-C
^C
C:\Users\SpikeyGG>ping media-equipment.local

Pinging media-equipment.local [172.27.80.29] with 32 bytes of data:
Reply from 172.27.80.29: bytes=32 time=2ms TTL=254
Reply from 172.27.80.29: bytes=32 time=2ms TTL=254

Ping statistics for 172.27.80.29:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms
Control-C
^C
C:\Users\SpikeyGG>

Here is an nslookup issued to both port 53 (Unbound DNS) and port 53001 (Kea DDNS Agent) showing that they both report the wrong address:
C:\Users\SpikeyGG>nslookup -port=53001 media-equipment.mynet 172.27.20.1
Server:  UnKnown
Address:  172.27.20.1

Name:    media-equipment.mynet
Address:  172.27.80.19


C:\Users\SpikeyGG>nslookup -port=53 media-equipment.mynet 172.27.20.1
Server:  UnKnown
Address:  172.27.20.1

Name:    media-equipment.mynet
Address:  172.27.80.19


C:\Users\SpikeyGG>

I had tried manually setting the Kea DHCP options for:
  • ddns-send-updates
  • ddns-override-no-update
  • ddns-override-client-update
before those options were included in the OPNsense Kea DHCPv4 subnet options; but they didn't seem to help. Now that they're included, I have all three checked on my 172.27.80.0/26 subnet but all the records continue to be broken.

Anyone have suggestions of how to get my Unbound DNS (or even Kea DDNS Agent) fixed without resorting to use static IPs for all my dynamic DHCP devices?
#2
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. :D
#3
Quote from: franco on April 22, 2022, 03:28:21 PM
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?
#4
Quote from: franco on April 21, 2022, 08:10:09 AM
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:

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


Quote from: zerwes on April 21, 2022, 10:36:02 AM
can you issue on the console a command for the failing mirror like:
# curl -vI https://opn-repo.routerperformance.net/repo/FreeBSD:12:amd64/packagesite.txz
and
# 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?


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:~ %
#5
I tried System->Firmware->Status->Check for updates... and it spits out this:

***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
#6
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...
#7
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:


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?
#8
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
#9
 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?
#10
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...