I had never used the custom feature before 23.01, so I don't know if it had worked previously or not. If not, then a blank end date defaulting to "now", or an option to select "now, would be a nice enhancement.

I spent last Fall updating an entire website from PHP 7.4 to 8.1, a month of tedium trying things, looking at the syslogs, fix, try again, etc. What a pain... I am still finding PHP warnings and deprecations in my logs that I have to chase.

Danke - hatte ich noch nicht entdeckt! 🙈

@jeffreyn said in No Clients Can Connect To OpenVPN Due to CRL Expiry:

@jimp I applied the patch when it was released. I'm reading the release notes for 23.01 and see Issue #13424 has been addressed in the new version. Do I need to do anything like remove the patch before or after I upgrade? Or does everything take care of itself?

You do not need to do anything with the patch after upgrading. You can delete the entry from the system patches package.

@jimp I ran 'pfSens-upgrade' from the Shell and the world is now safe!

Other than something in item #1, none of the other issues should have been a problem on my system. Here is what I have installed.
b15b044b-06b8-4008-8a2a-22786ca6a1e2-image.png

@gianpaoloracca UPDATE:
you can scroll dragging the column header.
So it's clunky but it works.

Ah, sorry if I misunderstood.

re: network alias, that can be one IP by using a /32 mask.

@autourdupc said in VLAN to LAN ping always possible despite rules:

Next time, i will ask community before spending soo much time !

What we are here for.. If there is some issue you have question on - or not sure if your understanding something correctly.. Yup just stop on by, here to help.

@stephenw10
Answer, hopefully in order...

Version is 2.5.2 on the Azure VM and 21.05-RELEASE (amd64) on the 5100s

OVPN is site-to-site, pre-shared key, UDP on IPV4 only, Layer 3. On the remote server there is a point-to-site server (for use as a remote internet gateway). It's for travel use but nobody's travelling so there are no connections.

Latency is 27-32 ms, WAN Azure to WAN local; 100-130 ms to the other sites from WAN local.

I only have one local device so I haven't tried to replicate here. I could spin up a Hyper-V guest but not now, I am currently working on alternative method, most likely a Linux server on the local LAN, running OpenVPN as a server and NAT port forward Linux server. We are up interactively but backups through the tunnels are an issue.

Not an expert regarding state tables so I wouldn't know what to look for. I can try clearing the state tables after the trouble begins to see if that reset avoids a reboot to restore WAN performance. Would that provide useful information?

We're not running IPSEC now. We were, but IPSEC failed after a recent upgrade. We switched to OpenVPN. I have read that the IPSEC issue has been resolved but haven't switched back.

One more observation. We do have a point-to-site server running locally. There is one user, a Synology raid device that phones home and stays connected 24x7. It is used as an off-site backup device accepting snapshot replication and file share backups. It's been running without issues. It seems to be the site-to-site tunnels that are tripping us up, on the client-side.

In the time it took to fix this critical bug, I was able to:

Set up and thoroughly test out OPNsense in a staging environment Find viable replacements for all the pfSense plugins and features I was using Weigh the pros and cons of switching to OPNsense Realize that open source pfSense has become a second class citizen Provision a new production firewall with OPNsense Manually copy the configuration from pfSense to the new OPNsense box Retire my pfSense box and switch permanently to OPNsense

@viktor_g Thanks for your help.

Linked issue:
https://redmine.pfsense.org/issues/10445

That file could only be stuck if somehow the notifyqueue_running lock is stale or not being released. Maybe something in your notification settings is broken and it can't get messages out.

It crashed in a network memory operation.

db:0:kdb.enter.default> bt Tracing pid 12 tid 100026 td 0xfffff80004e1f620 m_tag_delete_chain() at m_tag_delete_chain+0x83/frame 0xfffffe01735bf8d0 mb_dtor_pack() at mb_dtor_pack+0x11/frame 0xfffffe01735bf8e0 uma_zfree_arg() at uma_zfree_arg+0x42/frame 0xfffffe01735bf940 mb_free_ext() at mb_free_ext+0xfe/frame 0xfffffe01735bf970 m_freem() at m_freem+0x48/frame 0xfffffe01735bf990 vmxnet3_stop() at vmxnet3_stop+0x273/frame 0xfffffe01735bf9e0 vmxnet3_init_locked() at vmxnet3_init_locked+0x2c/frame 0xfffffe01735bfa50 softclock_call_cc() at softclock_call_cc+0x13a/frame 0xfffffe01735bfb00 softclock() at softclock+0x79/frame 0xfffffe01735bfb20 intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame 0xfffffe01735bfb60 ithread_loop() at ithread_loop+0xe7/frame 0xfffffe01735bfbb0 fork_exit() at fork_exit+0x83/frame 0xfffffe01735bfbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01735bfbf0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80d0eee3 stack pointer = 0x28:0xfffffe01735bf8c0 frame pointer = 0x28:0xfffffe01735bf8d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock (0))

It's not normal to see those kinds of NIC timeouts in a VM either.

I'd make sure your ESX or VMWare install is completely current first, and upgrade the VM hardware compatibility as far as possible. Also make sure the selected OS version matches what you have installed. The exact text will vary depending on your ESX/VMware version but it should be set to FreeBSD 11.x 64-bit.

It might be an edge case we can't really detect well since it may be valid in some other way, even if it isn't an IP address (e.g. a hostname, other alias name, etc)

Soon.

@Asamat: Your 'this Bug' URL is this thread here. ☺

-Rico