You might be able to do it for force reinstalling the repo pkg from:
https://pkg00-atx.netgate.com/pfSense_v2_4_3_amd64-pfSense_v2_4_3/All/pfSense-repo-2.4.3_4.txz

Then selecting previous version. However even that looks like it's set to use 2.4.4.
So maybe:
https://pkg00-atx.netgate.com/pfSense_v2_4_2_amd64-pfSense_v2_4_2/All/pfSense-repo-2.4.2_3.txz

Or create a custom repo conf file:

FreeBSD: { enabled: no } pfSense-core: { url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_3_amd64-core", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/local/share/pfSense/keys/pkg", enabled: yes } pfSense: { url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_3_amd64-pfSense_v2_4_3", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/local/share/pfSense/keys/pkg", enabled: yes }

The 2 links in a lagg is a much nicer setup but the switches should support cross-chassis LACP really.

@stephenw10
Got it thank you

Or check /etc/product_label /etc/product_name /etc/version.

I'm not sure how far back those go though so if you have a very old version they might not be present.

Steve

What problem are you looking for a solution to?

You should only need to wait. There is a restriction on how often the instance can pull repo data to prevent DoSing the server.
Or send me the NDI in chat and I can reset it for you.

Steve

Hmm, backtrace is similar but not identical:

db:0:kdb.enter.default> bt Tracing pid 96484 tid 100231 td 0xfffff8006f46e740 kdb_enter() at kdb_enter+0x37/frame 0xfffffe002eb0b630 vpanic() at vpanic+0x197/frame 0xfffffe002eb0b680 panic() at panic+0x43/frame 0xfffffe002eb0b6e0 trap_fatal() at trap_fatal+0x391/frame 0xfffffe002eb0b740 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe002eb0b790 trap() at trap+0x286/frame 0xfffffe002eb0b8a0 calltrap() at calltrap+0x8/frame 0xfffffe002eb0b8a0 --- trap 0xc, rip = 0xffffffff811eef8e, rsp = 0xfffffe002eb0b970, rbp = 0xfffffe002eb0b9c0 --- vmspace_fork() at vmspace_fork+0x95e/frame 0xfffffe002eb0b9c0 fork1() at fork1+0x356/frame 0xfffffe002eb0ba60 sys_fork() at sys_fork+0x54/frame 0xfffffe002eb0bac0 amd64_syscall() at amd64_syscall+0x387/frame 0xfffffe002eb0bbf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe002eb0bbf0 --- syscall (2, FreeBSD ELF64, sys_fork), rip = 0x8003ed8ea, rsp = 0x7fffffffe558, rbp = 0x7fffffffe590 ---

But we see some errors in the message buffer:

<6>pid 75760 (unbound), jid 0, uid 59: exited on signal 11 <6>pid 4613 (awk), jid 0, uid 0: exited on signal 6 (core dumped)

I would guess that is pfBlocker updating except I don't see that running. In which case do you have a large number of custom Unbound values? Host overrides?

Check the crontab for processes running at 8.00. Installing the cron package will show that.

Steve

Yes that same fix is in the current 23.05 code.

In a virtual install like that I'd usually expect to see the LAN assigned to an interface connected to an internal only bridge. Such that other VMs on that bridge use pfSense as their gateway and traffic to/from them can be filtered.

Steve

@stephenw10 Hi,
Upgrading fails in all cases I have tried if upgrading from 2.6.0
Hyper-V and 4 different PC hardware routers I have tried it on.
I have two separate threads I started on that yesterday.
in the dev section for 2.7.0 CE
It used to work awhile back but at some point along the way it no longer works.
You can't upgrade from 2.6.0 to 2.7.0 dev latest
Well- you can but it results in an unbootable kernel or driver immediate failure when it goes
to reboot.
But works fine if you install the 2.7.0 CE memstick and then update from that.
That is my work-around and I'm very happy that at least works.
2.7 openvpns setups stay up like they're supposed to :)

That should work. Easy to test from a client using pfSense for DNS though. Just see if they resolve to 192.168.0.32.

Steve

@guardian said in How can I troubleshot these log messages:

Is there any reliable way to tell if unbound is really hung, or if it's just busy reloading?

Not really. Since if it takes that long to load the config Unbound really isn't running during that time.

You should not use the Service Watchdog for Unbound.

@cappie thank you for the reply. i have updated the drivers and rebooted, appears the interfaces were updated successfully. i'll continue to monitor the status over the weekend

@stephenw10 Thanks! That did indeed solve my issue.

Almost certainly just poorly configured by default rather than anything malicious. Any real attack or scan would be across a range of ports/services and wouldn't waste time hitting the same port repeatedly.

If you change the rule to reject instead of block they might get the message and stop trying.

Steve

@mephmanx said in GNUPG install on PFSense:

organization background tasks that are backed by git repos for config and update purposes.

Why would you do this on the "firewall" wouldn't those make more sense to do on some resource inside the org? What part of the firewalls role do these tasks help with?

Problem I have seen over the years is people think oh well this "box" I have is only using like 3% of its cpu doing its current thing, why not just leverage these unused cycles for doing other than firewall things..

Is that the case here? Do you not have some other resource on your network that could perform these background tasks?

@johnpoz thank you for your reply and suggestions.
thank you to all of you, guys.

I really appreciated your help.

Regards,
Mauro

You can spoof the MAC address on the VLAN parent interface. So assign/enable that, if it is not already, and apply the MAC there.

@rloeb Instant turnaround from Netgate support!!! Got it running. Now need to update system version.

@getcom dang man! i feel for you. keep up the good work and keep those ruzzkies out !!!