Messages

76

23.1 Legacy Series / Re: OPnsense mirrors slow in updates [solved]

« on: April 13, 2023, 04:48:22 pm »

It was likely returning IPv6 addresses from the DNS lookup and trying to use them.

If you don't have IPv6 on your WAN, then it will likely not work.

Glad to hear you got it sorted.

77

23.1 Legacy Series / Re: os-vmware problems with ESXi 8

« on: April 13, 2023, 04:40:56 pm »

You might try recreating the virtual hardware too...

I presume you are using PVSCSI, VMXNET3 and virtual HW version 20.

What OS did you select for the VM?

What physical CPU is in your clone? Is it a quad-core?

You may also want to keep an eye on memory usage in case there is a leak.

78

23.1 Legacy Series / Re: OPnsense mirrors slow in updates

« on: April 10, 2023, 07:32:07 pm »

...but it says that an actual firmware update most be performed for it [to] take...

If you haven't worked it out already, and iirc, an actual update isn't required. You just need to perform a check for updates. Doing so might reveal available updates, which you can then install.

Changing to a faster mirror should result in the check for updates returning more quickly.

79

23.1 Legacy Series / Re: Using OPNsense in a domain

« on: April 08, 2023, 11:37:41 pm »

What DNS servers do you have at System: Settings: General...?

It could be related to this issue, or not. ¯\_(ツ)_/¯

If you have a domain environment (I presume ADDS), perhaps you could use M$ DHCP...?

You might consider modifying the topic title to something like DHCP ignores custom DNS servers to get more responses.

80

23.1 Legacy Series / Re: OpenVPN not work after update OPNSense from 23.1.1_2->23.1.3

« on: April 05, 2023, 11:56:15 pm »

@mara, the patch was committed to master three weeks ago.

You might want to update to the latest revision (23.1.5_4) announced here.

You will likely want to consider the patches here too.

81

23.1 Legacy Series / Re: OpenVPN Widget 23.1.5-4 Broken

« on: April 05, 2023, 11:49:21 pm »

I think that's new.

Did you patch per https://forum.opnsense.org/index.php?topic=33314.msg161367#msg161367...?

82

23.1 Legacy Series / Re: IGMP Proxy

« on: April 05, 2023, 11:46:43 pm »

I didn't wrote "224.0.0.0/24", I wrote 224.0.0.0/4.

224.0.0.0/24 is a subnetwork of 224.0.0.0/4. As it is not a routable network, I was suggesting your use case might be very rare. Also, the UI might not like it during validation. Did you try 232.0.0.0/8 instead of 224.0.0.0/4?

83

23.1 Legacy Series / Re: IGMP Proxy

« on: April 04, 2023, 01:58:10 pm »

224.0.0.0/24 (part of 224.0.0.0/4) is not routable. It is the local subnetwork block.

Cannot test on mine anymore, but you could try 213.13.19.0/20 and 232.0.0.0/8 instead.

Maybe even try just 213.13.19.0/20 first. That would cover hosts in the range 213.13.16.1 to 213.13.31.254.

84

23.1 Legacy Series / Re: os-vmware problems with ESXi 8

« on: April 04, 2023, 01:45:05 pm »

Perhaps check that open-vm-tools-nox11 version too. I'd normally check at the console / ssh with pkg, but it should also show up under packages once installed.

Stunning refers to quiescing the disk. The only other time I've seen something like this is when the disk takes too long to respond when being stunned and a hard reset occurs.

Yours seems to be more related to CPU resets. Perhaps more closely emulate the hardware profile, so if you have a dual core CPU and one socket, perhaps set the VM up to emulate that rather than trying to emulate more cores than you might have.

Are there other people using the os-vmware plugin with ESXi 8 successfully?

I migrated away from ESX last year so I'm unable to check without quite some work. Anyone else...?

85

23.1 Legacy Series / Re: os-vmware problems with ESXi 8

« on: April 04, 2023, 11:32:31 am »

Trying to make sense of your logs...

In the first log, the tools have crashed or are not installed. The status is 0 which is UNKNOWN.

In the second log, the status is 2 which is OLD, at least for the toolbox.

Perhaps check the version of tools installed. It should be 12.2.0_2.

Did you reboot after initial installation of the plugin?

Are you stunning the VM for any reason?

86

23.1 Legacy Series / Re: IGMP Proxy

« on: April 04, 2023, 10:39:37 am »

Hope you have the appropriate Class D network in your WAN firewall rules...!

1 - Adding subnets, doesn't allow me subnets with different netmask

Can you provide some more detail on this? For example, what networks were you unable to add?

Normally this would be networks that contains all the upstream hosts (or hosts with /32 CIDR masks); and sometimes the source-specific multicast block 232.0.0.0/8 might also be necessary. I've certainly been able to set multiple networks with different masks in the past, but that was some time ago now.

I presume you setup a downstream interface and also checked the "allow options" advanced option in your firewall rules where necessary...

87

23.1 Legacy Series / Re: OpenVPN clients require manual restart after reboot

« on: April 03, 2023, 03:00:04 am »

So this time before I rebooted OPNsense, I manually stopped both VPN clients ...not sure why they keep cycling up and down in the above dmesg printout.

Did manually stopping the clients have any impact on the problem, i.e. did they restart normally on reboot?

The cycling at the start (before rebooting) looks normal if you are restarting the clients regularly.

Startup doesn't look "normal" though. In the absence of timestamps I'm making some presumptions, but I would call that cycling atypical...

The section in question:

Code: [Select]

ovpnc1: link state changed to UP
ovpnc2: link state changed to UP
WARNING: attempt to domain_add(netgraph) after domainfinalize()
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to accept, logging disabled
load_dn_sched dn_sched FIFO loaded
load_dn_sched dn_sched QFQ loaded
load_dn_sched dn_sched RR loaded
load_dn_sched dn_sched WF2Q+ loaded
load_dn_sched dn_sched PRIO loaded
load_dn_sched dn_sched FQ_CODEL loaded
load_dn_sched dn_sched FQ_PIE loaded
load_dn_aqm dn_aqm CODEL loaded
load_dn_aqm dn_aqm PIE loaded
ovpnc1: link state changed to DOWN
ovpnc2: link state changed to DOWN
ovpnc1: link state changed to UP
ovpnc2: link state changed to UP
If I'm not mistaken, it looks like you are loading netgraph / limiters in between the interface state changes. This could certainly be related to the problem. Could you try disabling this to see the effect on the problem?

Re client config, you may want to consider removing perist-tun to see if rebuilding the interface helps with the problem. I would suggest explicit-exit-notify 5 is a bit excessive, the default 1 or maybe 2 should really be sufficient. It's possible (but maybe not probable) that you are telling multiple servers that you are leaving... This setting only has an effect if you are using UDP tunnels.

It doesn't look like management-hold is an issue and your cron jobs look fine.

Do you know of any slick way to divide the OpenVPN log?

I would just carve it up manually. If you have the epoch / timestamp, it should be relatively straightforward. It's really so that anyone having a look doesn't have to try and find the point of reboot as it's not always obvious. So an alternative is to write into the file at the reboot epoch and make it obvious, or post the timestamp, etc.

Also, I'd have a look yourself first before resorting to publicly posting the log.

Probably also important to try each of the suggestions one at a time to see the effect and identify potential root causes rather than doing them all at once and fixing it but not knowing why or how.

88

23.1 Legacy Series / Re: OpenVPN UI Regressions in 23.1.5 - Dashboard Widget & Connection Status Page

« on: April 02, 2023, 04:24:20 pm »

Solved - Github commits:
a5c4de0
3066c87

Thanks and credit to @AdSchellevis. If he drops a reply here, applaud the good fellow.

Use the following or wait for the hotfix/release:

Code: [Select]

opnsense-patch a5c4de0
opnsense-patch 3066c87


89

23.1 Legacy Series / Re: OpenVPN clients require manual restart after reboot

« on: April 02, 2023, 11:33:02 am »

From dmesg you want to check you get something similar to:

Code: [Select]

...
Syncing disks, vnodes remaining... 8 0 0 done
All buffers synced.
Uptime: 2d14h58m34s
...
Rebooting...

That way you know it was a clean sync to disk (the 0 0 done and All buffers synced).

The following command might reveal something:

Code: [Select]

dmesg | grep ovpnc
Link state changes and name changes should be the only lines returned.

You might need to share your OpenVPN logs to make headway... Maybe split /var/log/openvpn/latest.log into two at the reboot epoch and have a look either side. Methinks it would be a fair bit of redaction to share here and then we might miss some detail such as IP range overlap, routing table conflicts, etc.

Given that you are forcing the clients to regularly reconnect, it's probably worthwhile asking how you are doing this, e.g. are you restarting the OpenVPN service for each client, issuing a client-kill command via the management interface whilst using the explicit-exit-notify 2 configuration directive, or some other mechanism.

Also did you ever issue a hold on command via the management interface? Or do you have the --management-hold directive in your configuration? You may want to check with something like:

Code: [Select]

echo hold | socat - unix-connect:/var/etc/openvpn/client1.sock
You will likely need to install socat first. You might also want to check this following a reboot and before killing the PIDs...

If you get a hold=1 response, try issuing a hold release command to see if it starts and then a hold off command to help it persist reboots.

If present, the removal of the --management-hold directive would be important.

90

23.1 Legacy Series / Re: OpenVPN clients require manual restart after reboot

« on: April 02, 2023, 03:17:32 am »

I'm running 23.1.5_4-amd64 and just rebooted but all my clients came up straight away.

Are you positive you are getting a clean shutdown? Perhaps reboot again at the console (if you have one) and check if that's the case...