[Solved] Connectivity Audit - No IPv6 address could be found ?

[vk2him]

I've noticed a connectivity audit indicates I have no ipv6 connection, even though I have ipv6 working fine on my system. I can ping6 and traceroute6 from opnsense ssh and from a client without issue, and the correct ipv6 firewall rules are enabled.

test-ipv6.com also reports ipv6 is working.

Here is the output - is opn-repo.routerperformance.net the correct repo for ipv6 as a google search indicates it only has an ipv4 address?

Code Select Expand

***GOT REQUEST TO AUDIT CONNECTIVITY***
Currently running OPNsense 26.1.8_5 (amd64) at Sat May 30 11:45:49 AEST 2026

Current repository configuration:
/usr/local/etc/pkg/repos/FreeBSD.conf:
FreeBSD: { enabled: no }
FreeBSD-kmods: { enabled: no }
/usr/local/etc/pkg/repos/OPNsense-aux.conf:
OPNsense-aux: {
  fingerprints: "/usr/local/etc/pkg/fingerprints/OPNsense",
  url: "https://pkg.opnsense.org/${ABI}/26.1/aux",
  signature_type: "fingerprints",
  priority: 11,
  enabled: no
}
/usr/local/etc/pkg/repos/OPNsense.conf:
OPNsense: {
  fingerprints: "/usr/local/etc/pkg/fingerprints/OPNsense",
  url: "https://pkg.opnsense.org/${ABI}/26.1/latest",
  signature_type: "fingerprints",
  priority: 11,
  enabled: yes
}
/usr/local/etc/pkg/repos/mimugmail.conf:
mimugmail: {
  url: "https://opn-repo.routerperformance.net/repo/${ABI}",
  priority: 5,
  enabled: yes
}

/usr/local/etc/pkg/repos/ntop.conf:
ntop: {
  fingerprints: "/usr/local/etc/pkg/fingerprints/ntop",
  url: https://packages.ntop.org/FreeBSD/${ABI}/latest,
  signature_type: "fingerprints",
  priority: 100,
  enabled: yes
}

Checking connectivity for host: opn-repo.routerperformance.net -> 46.16.78.247
PING 46.16.78.247 (46.16.78.247): 1500 data bytes
1508 bytes from 46.16.78.247: icmp_seq=0 ttl=48 time=251.814 ms
1508 bytes from 46.16.78.247: icmp_seq=1 ttl=48 time=251.098 ms
1508 bytes from 46.16.78.247: icmp_seq=2 ttl=48 time=251.640 ms
1508 bytes from 46.16.78.247: icmp_seq=3 ttl=48 time=251.238 ms

--- 46.16.78.247 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 251.098/251.448/251.814/0.291 ms

Checking connectivity for repository (IPv4): https://pkg.opnsense.org/FreeBSD:14:amd64/26.1
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 928 packages processed.
Updating mimugmail repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: ... done
Processing entries: .......... done
mimugmail repository update completed. 189 packages processed.
Updating ntop repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: . done
Processing entries: . done
ntop repository update completed. 6 packages processed.
All repositories are up to date.

No IPv6 address could be found for host: opn-repo.routerperformance.net

Checking server certificate for host: opn-repo.routerperformance.net
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E7
verify return:1
depth=0 CN = opn-repo.routerperformance.net
verify return:1
DONE
Checking server certificate for host: pkg.opnsense.org
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = AT, O = ZeroSSL, CN = ZeroSSL RSA Domain Secure Site CA
verify return:1
depth=0 CN = pkg.opnsense.org
verify return:1
DONE
***DONE***


[Patrick M. Hausen]

That is the community repo run by Michael Münz that you must have added manually at some time. Did you install AdGuard Home or Unifi Controller, possibly?

That repo does not have IPv6 connectivity.

[dseven]

The audit scripts basically just pick the first (based on config filename) enabled package repo and use that as the test target, even if it's a third-party repo. That seems a bit ... fragile.

If you want to kludge around it, you probably could rename /usr/local/etc/pkg/repos/mimugmail.conf to mimugmail-full.conf (or something like that). If the filename doesn't match the repo name, the scripts will skip it (but it should still work as a pkg repo).

[vk2him]

Thanks guys, yes I'm running AdGuard Home - strange as I've been running AGH and ipv6 for a long time and the ipv6 Connectivity Audit always worked for ipv6 until recently.

I just tried renaming mimugmail.conf to mimugmail-full.conf and the ipv6 Connectivity Audit then worked, however it wasn't able to perform the mimugmail repository update as it couldn't find the mimugmail.conf, so I reverted the name back to mimugmail.conf

I also noticed I had the priority: for mimugmail.conf set to 5, so I changed that to 150 however the ipv6 connectivity audit still failed.

I wonder if it is possible to force the ipv6 connectivity audit to use the same config that is used for ipv4?

[dseven]

Thanks guys, yes I'm running AdGuard Home - strange as I've been running AGH and ipv6 for a long time and the ipv6 Connectivity Audit always worked for ipv6 until recently.

I just tried renaming mimugmail.conf to mimugmail-full.conf and the ipv6 Connectivity Audit then worked, however it wasn't able to perform the mimugmail repository update as it couldn't find the mimugmail.conf, so I reverted the name back to mimugmail.conf

Hmm. I renamed mine, and it didn't seem to affect anything. What were you doing when the failure occurred?

Anyway, if AGH is the only thing you need, you could use mimugmail-single as documented at https://www.routerperformance.net/opnsense-repo/ - that should kludge around it too.

I also noticed I had the priority: for mimugmail.conf set to 5, so I changed that to 150 however the ipv6 connectivity audit still failed.

I wonder if it is possible to force the ipv6 connectivity audit to use the same config that is used for ipv4?

The scripts don't look at priority - they just use the first one based on the order of the filenames.

It *does* use the same hostname for v4 and v6 - v4 worked because that hostname has a v4 address (A record in DNS).

[vk2him]

Thanks for the help @dseven - I realised I made a typo when renaming - I used mimugmail_full.conf instead of mimugmail-full.conf

After renaming it correctly to mimugmail-full.conf, the ipv6 connectivity audit now works, and the mimugmail repo passes under ipv4.

Code Select Expand

Checking connectivity for repository (IPv4): https://pkg.opnsense.org/FreeBSD:14:amd64/26.1
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 928 packages processed.
Updating mimugmail repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .... done
Processing entries: .......... done
mimugmail repository update completed. 189 packages processed.
Updating ntop repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: . done
Processing entries: . done
ntop repository update completed. 6 packages processed.
All repositories are up to date.

mimugmail repo update fails under ipv6, which I think is correct as the mimugmail url is only accessible via ipv4.

Code Select Expand

Checking connectivity for repository (IPv6): https://pkg.opnsense.org/FreeBSD:14:amd64/26.1
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: ......... done
Processing entries: .......... done
OPNsense repository update completed. 928 packages processed.
Updating mimugmail repository catalogue...
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
repository mimugmail has no meta file, using default settings
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
Unable to update repository mimugmail
Updating ntop repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: . done
Processing entries: . done
ntop repository update completed. 6 packages processed.


[Patrick M. Hausen]

The connectivity audit is as far as I know intended to be a debugging aid in case you observe any problem with updates. It's not a regular health check that must necessarily be "green" all the time.