@johnpoz Ok, well thank you anyway John
Tas

Hmm, so in that log after 'Bootup complete' none of the WG tunnels or gateways were up?

Cool. Yup there was a backend issue last night. It should be fixed now.

@stephenw10 Unfortunately I am going to have to wait till I can bring down the network to test. If I take it down now and it doesn't come back up I will be having some hell to pay from the family...lol. 😃

@Zermus said in crowdsec:

It's a shame Elastic took their stuff in house and ELK stacks are no longer free. Tom Lawrence's (https://www.youtube.com/@LAWRENCESYSTEMS) videos convinced me that I should go over to Graylog Open on my personal stuff when that happened and I'm happy with it.

I always viewed ELK as overly complicated. Graylog is much more manageable, although the console isn't as nice. Work in progress.

@stephenw10 said in Gateway monitoring still not OK:

I would still expect to have seen dpinger try to ping and show loss rather than pending.

/etc/inc/gwlb.inc:

// dpinger returns '<gwname> 0 0 0' when queried directly after it starts. // while a latency of 0 and a loss of 0 would be perfect, in a real world it doesnt happen. // or does it, anyone? if so we must 'detect' the initialization period differently..

@Euroguy said in Router advertisement not sending default gateway:

So, followup after a reinstallation of the system

Short answer is, things now seem to work.

Glad to see you got it up and running :)

I get both DHCP4 and 6 clients with leases now (although status of lease seems broken, always showing black down arrow even though lease is active and remote machine is up and active

I see that from time to time too. I think there are some timers that you can tweak (can't recall which ones though) that determines how long it takes without a "sign of life" before the client is marked as offline. For IPv4 there's an ARP timer ... and for v6 it should be an equivalent NDP timer. Can be set in System / Advanced / Tunables once you find out what they are called :)

DHCP6 server fails as DHCP requests / Discovery is done on fe80::/10 and that is not considered to be LAN it seems. I had to add a LAN allow rule for fe80::10 to ff02::/16 like this for DHCP6 to work:
e98b2093-2534-4c7e-9c09-6d54251d537d-image.png

That rule shouldn't be needed, it is part of the automatic rule set added by pfSense. I get those by means of pfSense magic: (check in /tmp/rules.debug)

pass in quick on $WAN proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 ridentifier 1000000463 label "allow dhcpv6 client in WAN" pass quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 ridentifier 1000002551 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 ridentifier 1000002552 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 ridentifier 1000002553 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 ridentifier 1000002554 label "allow access to DHCPv6 server" <snip>

Update:
the timer tweak I used a long time ago was

net.link.ether.inet.max_age=60

which make the cached ARP-entry lifetime 60 seconds, I wanted clients to go offline faster. Default is 1200s. See https://man.freebsd.org/cgi/man.cgi?query=arp&sektion=4

24319ba3-b5d5-4add-b251-9993249ff5a6-image.png

@Gertjan oh I missed that - my bad.

Not disagreeing with anything stated thus far—all interesting discourse to me. Merely sharing that I've been forwarding unbound's recursive DoT lookups to Cloudflare and Quad9 simulatenously with DNSSEC enabled for many years without issue. I've never encountered any problems that seemed to stem from double validation, conflicting checks, blocked or broken answers, untrusted anwers, or mismatched trust anchors and/or an incomplete chain of trust. (And obviously, unless there was an apparent client DNS issue on my LAN, some of that could be happening without me even realizing.)

I faintly recall troubleshooting/tweaking "EDNS Buffer Size" (Services / DNS Resolver / Advanced Settings / Advanced Settings) at one point, and I currently have it set to "4096: Unbound Default". I think I also experimented with "Experimental Bit 0x20 Support" but ultimately left it off for improved performance. Those are the only DNSSEC-related tweaks I remember ever fiddling with.

Nary do I see a 150+ ms query time when I'm paying attention.

@johnytb said in Gtek 2.5G (Intel I225 Controller) PCI-E x1 Network Card not recognized by the pfsense:

can you explain to me what exactly is this interface that you show here ?

That's pfSense most important interface 😊
The one that works when even all your NICs don't work.

Its called : the console, which could be a serial connection, or, if you have VGA/HDMI build in, it could be that and a (USB) keyboard.
Or : If the LAN NIC is working, you 'ssh' into your pfSense using a SSH client like putty or classic 'ssh'.

Keep in mind : what happens when you have a disk drive issue ?
=> pfSense can't boot.
=> Network interfaces will all by down ...
You the the console (serial or VG/HDMI/Keyboard) access.

For command line commands I use the ... command line = console (or SSH) access.

UI Update output.

>>> Updating repositories metadata... Updating pfSense-core repository catalogue... Fetching meta.conf: . done Fetching data.pkg: . done Processing entries: . done pfSense-core repository update completed. 5 packages processed. Updating pfSense repository catalogue... Fetching meta.conf: . done Fetching data.pkg: .......... done Processing entries: .......... done pfSense repository update completed. 733 packages processed. All repositories are up to date. >>> Setting vital flag on pkg...done. >>> Setting vital flag on pfSense...done. >>> Renaming current boot environment from 25.03 to 25.03_20250719205419...done. >>> Cloning current boot environment 25.03_20250719205419...done. >>> Removing vital flag from php83...done. >>> Upgrading packages in cloned boot environment 25.03... Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. Checking for upgrades (10 candidates): .......... done Processing candidates (10 candidates): .......... done The following 10 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: if_pppoe-kmod: 25.03.b.20250515.1415.1500029 -> 25.07.r.20250715.1733.1500029 [pfSense] pfSense: 25.03.b.20250515.1415.1500029 -> 25.07.r.20250715.1733.1500029 [pfSense] pfSense-base: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-boot: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-default-config-serial: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense] pfSense-kernel-pfSense: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-pkg-Nexus: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense] pfSense-pkg-System_Patches: 2.2.21_1 -> 2.2.21_2 [pfSense] pfSense-repoc: 20250419 -> 20250520 [pfSense] unbound: 1.22.0_1 -> 1.23.0 [pfSense] Number of packages to be upgraded: 10 The operation will free 12 MiB. 214 MiB to be downloaded. [1/10] Fetching unbound-1.23.0.pkg: .......... done [2/10] Fetching pfSense-pkg-System_Patches-2.2.21_2.pkg: ......... done [3/10] Fetching if_pppoe-kmod-25.07.r.20250715.1733.1500029.pkg: ... done [4/10] Fetching pfSense-pkg-Nexus-25.07.r.20250715.1733.pkg: .......... done [5/10] Fetching pfSense-kernel-pfSense-25.07.r.20250715.1733.pkg: .......... done [6/10] Fetching pfSense-base-25.07.r.20250715.1733.pkg: .......... done [7/10] Fetching pfSense-25.07.r.20250715.1733.1500029.pkg: .......... done [8/10] Fetching pfSense-boot-25.07.r.20250715.1733.pkg: .......... done [9/10] Fetching pfSense-default-config-serial-25.07.r.20250715.1733.pkg: . done [10/10] Fetching pfSense-repoc-20250520.pkg: .......... done Checking integrity... done (0 conflicting) [1/10] Upgrading unbound from 1.22.0_1 to 1.23.0... ===> Creating groups Using existing group 'unbound' ===> Creating users Using existing user 'unbound' [1/10] Extracting unbound-1.23.0: .......... done [2/10] Upgrading pfSense-repoc from 20250419 to 20250520... [2/10] Extracting pfSense-repoc-20250520: .. done [3/10] Upgrading if_pppoe-kmod from 25.03.b.20250515.1415.1500029 to 25.07.r.20250715.1733.1500029... [3/10] Extracting if_pppoe-kmod-25.07.r.20250715.1733.1500029: .. done [4/10] Upgrading pfSense-boot from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [4/10] Extracting pfSense-boot-25.07.r.20250715.1733: .......... done [5/10] Upgrading pfSense-pkg-System_Patches from 2.2.21_1 to 2.2.21_2... [5/10] Extracting pfSense-pkg-System_Patches-2.2.21_2: .......... done [6/10] Upgrading pfSense-pkg-Nexus from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [6/10] Extracting pfSense-pkg-Nexus-25.07.r.20250715.1733: .......... done [7/10] Upgrading pfSense-kernel-pfSense from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [7/10] Extracting pfSense-kernel-pfSense-25.07.r.20250715.1733: .......... done [8/10] Upgrading pfSense-base from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [8/10] Extracting pfSense-base-25.07.r.20250715.1733: ... done ===> Keeping a copy of current version mtree ===> Removing schg flag from base files ===> Extracting new base tarball ===> Removing static obsoleted files [9/10] Upgrading pfSense from 25.03.b.20250515.1415.1500029 to 25.07.r.20250715.1733.1500029... [9/10] Extracting pfSense-25.07.r.20250715.1733.1500029: .......... done [10/10] Upgrading pfSense-default-config-serial from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [10/10] Extracting pfSense-default-config-serial-25.07.r.20250715.1733: [10/10] Extracting pfSense-default-config-serial-25.07.r.20250715.1733... done Failed

@iggybuddy6 I'm just happy I could help. Today I went from thinking I knew everything about setting up wg on pfSense, to realising I did not, and that is a great reward in itself!

Hopefully your setup will remain stable going forward.

@johnpoz This even does this with the newest CE edition inside of UTM virtualized environment outside of the 2100s

Screenshot 2025-07-17 at 10.15.51.png

It is not just the 2100s this is set up for standard stuff everything else works with it just the status page

@stephenw10 Thanks for letting me know there were backend issue, I think it would be helpful if Netgate posted an announcement when there are issues, maybe some details, and an ETA to restore service.

It would save a little headache for some of us.

Recently done four of them. Two upgrades from 2.7.2 and two net installed. All went ok & reinstalled packages after.

I agree an iso would be useful but I’ve managed without.

Next one will be an ESXI vm, so will try both methods on that.

You can set the size it rotates at and the number of files to retain in the log settings at Status > Logs > Settings. As long as you have the space you should be able to increase it.

Ah OK I see, the names threw me!

@mav3rick said in OpenVPN on 2 pfsense instance with HA - service is running on both pfsense instances:

So setting openvpn to bind only to the CARP VIP works fine for me

Multi-WAN with HA there?
If so, it would be a better idea to run openVPN server on localhost instead.
This would allow it to receive connections from all WANs.

No need to select a VIP, just forward packets from the WANs VIPs to localhost.
You can use DNS, thus the client would connect to the WAN that is UP.
Or
You can use two remote entries in the .ovpn, with timeout lets say, 2 seconds.

Then, just create the NAT rule to access the firewall-2, using the SYNC address as previously mentioned.

@viragomann I lost oversight. The customer edited stuff on his own ... and wrote he succeeded by adding fw rules and policy-based-routing. Sounds like overkill a bit, but ok if he's happy.
I have to accept that this box is out of my control somehow now ;-)

thanks for your help. I might report back if I get access again and see things.