It's probably a routing conflict. The laptop has an IP and gateway in the LAN subnet and that must be routed outside the tunnel but at the same time the WG server is sending it routes to the LAN subnet via the tunnel. I would expect to see some routing error logged somewhere. Putting the WIFI on a different subnet would workaround it. You could also block access to the WG server from the LAN so the tunnel cannot connect when you're on that subnet. Steve

The installer image contains a FAT32 partition for exactly this purpose. See: https://docs.netgate.com/pfsense/en/latest/backup/restore-during-install.html#restore-configuration-from-usb-during-install Steve

Ok I created a bug for it but that may get changed to a feature request because that is the expected behaviour in the code. It's not what I would expect as a user though. https://redmine.pfsense.org/issues/15228

Yup, usually you won't notice the difference. We have seen some situations where it is required though. Others where the throughput can be significantly increased by disabling it. It's worth testing disabling it if you are not seeing the expected throughput and have local access to revert that change if required. Steve

Almost always because the system clock changed so the data becomes invalid.

Many modules that are shown as Intel compatible will work there. Those listed are just what we've tested locally. The most common problem people hit is trying to use a 10/1G module at 1G. That often requires setting a 1G fixed link speed and some modules don't expose that option. DAC cables usually don't offer that. Steve

Hmm, still can't replicate it. It must be something in your config somehow. Are you able to test it with a default config? Or upload your config to us to check?

@JKnott said in Netgate 6100 SFP+ connection error rate of 0.0055%. Should I be worried?: @ChrisJenk said in Netgate 6100 SFP+ connection error rate of 0.0055%. Should I be worried?: Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll ix1 9000 <Link#6> 90:ec:77:7f:c9:d5 31488071 1452 0 74590982 0 0 ix1 - fe80::%ix1/64 fe80::92ec:77ff:fe7f:c9d5%ix1 1060 - - 98 - - Is that your WAN or LAN? While there's no problem with jumbo frames on the LAN, assuming other devices can handle them, you shouldn't be sending them to the WAN. PfSense should be sending ICMP too big messages when a jumbo frame tries to leave your LAN. You shouldn't be using jumbo frames on the WAN side, with the possible exception of if you're on Internet2. It's my LAN and I do use Jumbo frames on that (carefully). However, the jumbo frames are restricted to two VLANs neither of which are configured on the NetGate so those frames should actually never reach the unit. I think that MTU is a hangover from an older config; I will set it back to the default. However, in my current setup the LAN is now ix0 and it has an MTU of 1500. Name Mtu Network Address Ipkts Ierrs Idrop Opkts **Oerrs** Coll ix0 1500 <Link#5> 90:ec:77:7f:c9:d4 17034814 **387** 0 20616901 0 0 ix0 - fe80::%ix0/64 fe80::92ec:77ff:fe7f:c9d4%ix0 4078 - - 18875 - - ix0 - 10.0.200.0/24 router 8993 - - 22104 - - ix0 - fd00::/64 router 8936 - - 9272 - - ix0 - xxxxxxxxx::/64 router.xxxxxxxxxxxx 0 - - 25628 - - ix0 - yyyyyyyyy::/64 yyyyyyyyyyyyyy::1 0 - - 42 - -

Hmm, none jumps out there but I would try removing them one at a time if you're able.

Ok, what does the Status > Interfaces page show? What sort of connection does your ISP provide? Is it just DHCP? You may need to reboot the modem if it's locked to the MAC address of the Asus router. Steve

@Popolou This is from my Windows laptop, I don't have the native apps installed. But, it did prompt me to test with another Windows device that hadn't been moved to the pfSense firewall yet. That did seem to run much better, so it may well be a device issue, rather than the firewall. Strangely though, the troublesome laptop does work very smoothly when it's on a raw internet connection. Thanks to you both for your answers.

Thanks. I reinstalled yesterday evening. Seems to be booting fine now after the fresh installation. Just have to restore the backup and I'm good. Thank you so much for the input though!

@stephenw10 OK I just deleted them all and created new ones - now 7 of them are green and 1 is red (100% packet loss) - while this is less than ideal we can live with that in the short term. What I'll do is open a support call with the provider that these tunnels go to and see what they have to say. If we identify issues with pfSense I will likely open up a new thread on this forum and link to it from here. As for the LAN drops, I think that problem is solved, we've had 2 whole working days now and its been clean. As mentioned we did rather too many changes at once to isolate which one of these might of been the solution, but thems the breaks. Of course your help has been invaluable so thank you very much for that.

@stephenw10 Unfortunately the NUT service would not restart after all this. I had to delete the package and reinstall. I think I should just wait for the officially updated package (hopefully to be released soon!)

Hmm well I know nothing about them but others may.

Thank you @stephenw10 Turned out to be a config issue on my site which I missed. (forgot to add the sync states checkbox on the secondary node)

@stephenw10 thank you. everything works fine now!

@harithruchira said in Need help to understand firewall log: What does the long log entry at 12:46:06 mean? That is dpinger, the gateway monitor, restarting. It has two instances, one on each WAN. @harithruchira said in Need help to understand firewall log: Could you explain the numbers 76642 and 76977? Those are the process IDs. OK so it looks like that first log was only the gateway log and this second log is the full system log? It's much easier to work with logs like this if you copy and paste them here rather than using screenshots. But you can see that includes entries showing ix3 relinking after you presumably rebooted the modem? Whatever was logged before that might show why it went down initially. Running both ntopng and bandwidthd at the same time can sometimes be a problem. The one thing that stands out as an issue is php coredumping at 12:48:48. However it's running again a few seconds later.

@msf24 said in ovpn client wont connect wih firewall settings on high: when updating with 3.1 router i am having connectivity issues What firewall are you using? This doesn't sound like pfSense. Steve

@stephenw10 said in Wrong timestamp in Packet Capture Output?: This should be a feature request. The ability to use local timestamps seems like a useful addition. Totally agree! Already created yesterday. It's not a bug though. Of course, just developers have not polished this many years ago.