Connectivity check is not working

[will@moonen.me]

The feature "Run an audit" - "Connectivity" is not working - all pings and subsequent tests fail.

However, updates are processed and tests with ping (from interface diagnostics) are working as expected.

I have added a rule that allows all IPv4-ICMP requests on the WAN port.
I have also added a NAT-rule for any outbound destination.

I have also added the WAN-port to the unbound dns service.

Based on the above test results I assume that the problem is somewhere within the settings.
However, I don't have an idea what to look for.

Anyone an idea as to why this type of audit could be failing?

[i81b4u]

Had the same issue and did a quick and dirty fix by patching /usr/local/opnsense/scripts/firmware/connection.sh (patch included).

That is the script that does the connectivity check. It performs a ping command on IPv4 and IPv6 using a 1500 byte packet size. If I'm not mistaken, the maximum packet size for IPv4 using an MTU of 1500 is 1472. For IPv6 the maximum size is 1452. Bottom line is that if you know the MTU of your WAN-interface and subtract 28 bytes for IPv4 and 48 bytes for IPv6, you get the maximum packet size that can be used in said script.

You could calculate the values dynamically, but I was too lazy to do that (for now).

Best regards.

[franco]

The connectivity audit is designed to force fragmentation on the ping in order to catch hard to find edge cases. Without posting the output you're just speculating it's wrong and to some degree it is, but it's just a tool to force these edge cases. Even the audit should still say you can use at least one of IPv4 or Pv6 update checks fine.

[i81b4u]

Without context it comes down to speculation most of the time.
Having said that, when someone expects something to work in a particular way, who am I to say that it can not be done, aside from the original intention of the author of that script/piece of software.

In this case I would not like to state that something is either right or wrong, just that it did not work the way someone expected it to work.

So no offense meant in any way to anyone or anything. Just trying to help out ;-).

[franco]

No, no, I just wan to explain :)

The audits are to be used when a problem is expected, not when it works fine. The exception is the security audit maybe, but nobody posted that here in the forum for a while... but I digress.

We could make the connectivity audit simpler or fix these "problems", but it wouldn't tell us all we want to know. What it does is probe both the IPv4 and IPv6 path to the update server and check the certificates. Each of these checks has some historic bug or support case context. My favourite one was the broken fragmentation in VMware guest which was only visible through the ping that forces fragmentation in most cases.



Cheers,
Franco