Hi Steve,

Log below is from the one switch which is working with NPS and it go directly to the privilege mode:
Nov 18 17:38:11.277: AAA/BIND(00019352): Bind i/f
Nov 18 17:38:11.281: AAA/AUTHEN/LOGIN (00019352): Pick method list 'VTY'
LAN-ZG1-K5-07#
Nov 18 17:38:16.332: AAA/AUTHOR/EXEC(00019352): processing AV priv-lvl=15
Nov 18 17:38:16.332: AAA/AUTHOR/EXEC(00019352): processing AV service-type=2
Nov 18 17:38:16.332: AAA/AUTHOR/EXEC(00019352): Authorization successful

This log is from the switch configured on pfSense and it go on the enable mode:

20w1d: AAA: parse name=tty7 idb type=-1 tty=-1
20w1d: AAA: name=tty7 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=7 channel=0
20w1d: AAA/MEMORY: create_user (0x80FA1B54) user='' ruser='' port='tty7' rem_addr='192.168.2.106' authen_type=ASCII service=LOGIN priv=1
20w1d: AAA/AUTHEN/START (66358651): port='tty7' list='VTY' action=LOGIN service=LOGIN
20w1d: AAA/AUTHEN/START (66358651): found list VTY
20w1d: AAA/AUTHEN/START (66358651): Method=VERSO-RADIUS (radius)
20w1d: AAA/AUTHEN (66358651): status = GETPASS
20w1d: AAA/AUTHEN/CONT (66358651): continue_login (user='test')
20w1d: AAA/AUTHEN (66358651): status = GETPASS
LAN-ZG1-R2-23#
20w1d: AAA/AUTHEN (66358651): Method=VERSO-RADIUS (radius)
20w1d: RADIUS: ustruct sharecount=1
20w1d: RADIUS: Initial Transmit tty7 id 107 10.223.110.155:1812, Access-Request, len 77
20w1d: Attribute 4 6 0ADF6E17
20w1d: Attribute 5 6 00000007
20w1d: Attribute 61 6 00000005
20w1d: Attribute 1 6 74657374
20w1d: Attribute 31 15 3139322E
20w1d: Attribute 2 18 7FD1744C
20w1d: RADIUS: Received from id 107 10.223.110.155:1812, Access-Accept, len 33
20w1d: Attribute 26 13 0000000901077368
20w1d: RADIUS: saved authorization data for user 80FA1B54 at 80F4F90C
20w1d: AAA/AUTHEN (66358651): status = PASS
20w1d: tty7 AAA/AUTHOR/EXEC (3980703284): Port='tty7' list='' service=EXEC
20w1d: AAA/AUTHOR/EXEC: tty7 (3980703284) user='test'
20w1d: tty7 AAA/AUTHOR/EXEC (3980703284): send AV service=shell
20w1d: tty7 AAA/AUTHOR/EXEC (3980703284): send AV cmd*
20w1d: tty7 AAA/AUTHOR/EXEC (3980703284): found list "default"
20w1d: tty7 AAA/AUTHOR/EXEC (3980703284): Method=VERSO-RADIUS (radius)
20w1d: RADIUS: invalid format in cisco avpair at "shell"
20w1d: AAA/AUTHOR (3980703284): Post authorization status = ERROR
20w1d: tty7 AAA/AUTHOR/EXEC (3980703284): Method=LOCAL
20w1d: AAA/AUTHOR/LOCAL: no entry for test
20w1d: AAA/AUTHOR (3980703284): Post authorization status = ERROR
LAN-ZG1-R2-23#
20w1d: tty7 AAA/AUTHOR/EXEC (3980703284): Method=IF_AUTHEN
20w1d: AAA/AUTHOR (3980703284): Post authorization status = PASS_ADD
20w1d: AAA/AUTHOR/EXEC: Authorization successful
LAN-ZG1-R2-23#
20w1d: AAA/MEMORY: dup_user (0x80FA1C7C) user='test' ruser='' port='tty7' rem_addr='192.168.2.106' authen_type=ASCII service=ENABLE priv=15 source='AAA dup enable'
20w1d: AAA/AUTHEN/START (3251226681): port='tty7' list='' action=LOGIN service=ENABLE
20w1d: AAA/AUTHEN/START (3251226681): non-console enable - default to enable password
20w1d: AAA/AUTHEN/START (3251226681): Method=ENABLE
20w1d: AAA/AUTHEN (3251226681): status = GETPASS
LAN-ZG1-R2-23#
20w1d: AAA/AUTHEN/CONT (3251226681): continue_login (user='(undef)')
20w1d: AAA/AUTHEN (3251226681): status = GETPASS
20w1d: AAA/AUTHEN/CONT (3251226681): Method=ENABLE
20w1d: AAA/AUTHEN (3251226681): status = PASS
20w1d: AAA/MEMORY: free_user (0x80FA1C7C) user='' ruser='' port='tty7' rem_addr='192.168.2.106' authen_type=ASCII service=ENABLE priv=15

Best regards,
Jozy

Yup you can't install a pkg for 2.6 into 2.7.0. If you managed to force that to happen it will likely break things.

It should work fine in 2.7.2.

The packages should be updated during the upgrade anyway.

The new pkg system with dynamic repos makes accidentally pulling in packages from the wrong repo thankfully far more difficult. Since 23.09.1 you've had to opt in to the new repo when an update is available.

Yes you will need a least that. But you may also need the IGMP proxy configured, possibly at both ends, so that clients can see the streams and subscribe to them.

@Gertjan said in Dynamic DNS client "extracted from local system":

To know if the WAN IP really changed ? Easy. Store the latest succeeded updated WAN IPv4 address locally. This is the cache file. Compare the actual WAN IPv4 with the cache ;:

Just going to take this opportunity to point out that this causes a problem in the case where we restore to a replacement router in our lab before delivery. DDNS is updated to our office IP. Live router will not update because its cached IP didn’t change. (Workaround is to manually modify the file on disk to fool it, as I recall)

I went and changed to yes and the logs seemed to clear up.

Thank you again.

@stephenw10
system - advanced - networking - ipv6 options - no checks, but... the WAN - IPv6 Configuration Type - DHCP6 so I changed to none.

Thank you sir!

Thnx guys 👍

@stephenw10 Thanks for this info. I hope later down this may not be the case. Since I practice to think of my pfsense as an appliance, I would rather not tweak it but will take a look.

::1 is IPv6 localhost. Unbound should listen on that address by default but you may have disabled that. Or if you have enabled the forwarder instead.

If you have upgraded from a much older version you might have it added specifically in System > General Setup and can remove it from there.

@stephenw10

Well, we're at 48 hours without an incident after switching the ethernet cable that connects the ONT to the router, so it's pretty safe to say you were correct saying it was hardware

Thank you for your support, honestly I wouldn't have guessed a damaged cable would cause something so intermittent and short

Kind Regards,
Mylo

@stephenw10 that is insane.. I had a device that had a multicast mac set on it, company screw up.. It could work - but it could also cause some problems. It was a networking bridge for electric consumption meter, current cost by envi if I recall.. Had to be 10 years ago, I remember it working until I moved it something other than a dumb switch - then I ran into issues.. I remember having to do something with igmp snooping.

An update for anyone who may be experiencing this issue.

This issue is caused by ATT's RG firmware. The latency spikes and jitter are resolved on the BGW320-505 as of firmware 6.30.5.

This issue was somewhat widely discussed at /r/ATTFiber. Shame on ATT for taking 8+ months to release a firmware which fixed it. And I was only able to get the firmware update by working with a redditor who had a high-level engineering contact at ATT, who was able to MANUALLY push the firmware update to my device. Who knows when it would have rolled out to me...

Thank you to @stephenw10 for the help along the way.

@stephenw10 cheers. We shall wait!

I will say that I've only ever seen issues like that when using UFS without RAM disks enabled. Using ZFS or enabling RAM disks should prevent it for the vast majority of cases.

Graylog has taken care of this for me. Creating reports for top dst IP and ports

@mucip said in Internet lost in PfSense but VPN or everythingelse work well?:

the monitoring and what is used for?

And nice stats :

79f298d6-5237-4445-8459-f960de6df354-image.png

Monitoring the device in front of your pfSense, the ISP router, only tells you something about the cable between them 😊 and nothing much about your entire WAN connection.
Monitoring for example 8.8.8.8 tells you something about the 'quality' of the connection up until 8.8.8.8.
This will includes your entire 'ISP' WAN connection.

@GanaelG If you have two cables then you presumably want two separate ports and two physical networks, which is the doc page linked above:

https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/configuring-the-switch-ports.html

The example is for port 4 but you can do it for port 2 and 3 also.

@stephenw10 said in Route pfsense itself over VPN.:

Hmm, well it sure seems like it's set to serial as primary console from what you're seeing. But as I say you should be able to see which is set at the vga console.

Success !!!

I made the mistake when creating a static route by typing ip address of openvpn server and then selecting the subnet. Selecting the subnet was a mistake that caused pfsense to be stuck at boot. I created new static route by typing the openvpn server address, chose the appropriate WAN and saved the setting. After reboot, pfsense booted just fine. I created additional static routes for the remaining vpn clients and everything just worked. Rebooted once again, no issues. Then i selected openvpn client as a default gateway and that was it.

All tailscale clients are now going through vpn, and all vpn clients connect without any issues after reboot.

Thank you very much Stephen. All this would not be possible without your help. Im marking this thread as resolved.

Cheers.