That's great. Thank you very much. I'll give that a try and let you know how it goes. Many thanks

how can I make the pydio work with the certificate? You don't. Install certbot on your pydio box and then let it get its own certificate.

The file could be stock and still not affected, it depends on the bug and how the library is used. I haven't looked deeply at that particular issue, but in similar cases in the past we've seen instances where we happened to not use a particular affected component so even though the vendor library was flawed, pfSense was not vulnerable. So it does take a bit deeper analysis than just inspecting version numbers. Still, it is very out of date, so we are certainly looking at what the impact of updating it will be.

@racecarr Hello, So our company decided to revert back to ring central after using dialpad for about a month. Our experience with their product and services was low-grade - in terms of voip quality and end-user app usability (stability and lack of admin accessibility). They rely to some extent on google data centers for some of their data operations which can be an advantage but also a dependency that is not fault tolerant. We experienced this when some database servers experienced disruption and our users where unable to access the app to get into their accounts to make calls. I do not recommend dialpad. It appeared to me their systems are underdeveloped when it comes to non-Ai and non-sync features, meaning the primary usage of voip with them was inconsistent and low-quality as they seemed to have emphasized other feature enhancements over the main functionality, being voice-over-ip call quality and connection stabilization .

Squid probably isn't tracking that accurately anyhow. You'd be better off with a setup more like netflow but that would require an off-box collector to keep the data and make graphs. ntopng may help locally.

Just installed aprwatch package. Settings used : [image: 1573472225610-6a2513ff-1864-4fd3-9651-57e24d546982-image.png] Had to stop it an hour later : my (self hosted) mail box received hundreds of mails from arpwatch. This means : My Sys > Adv > Notifications has been set up correctly ;) "arpwatch" sends mail using the pfSense mail notational system .... and it does as advertised. Btw : take note of the warning : [image: 1573472062935-43769840-23e6-4917-b4ec-e65cbf94cfe7-image.png] I know what 'gmail' might do when you bombard it with pretty identical mails (from the same IP). It will do what it should do : it will discard and block them .... Upfront, you should white list (make the sender mail a contact, etc). gmail is nice to be sued as a things-go-bad-notifier, but do not spam them.

@fluctuationit Is the VM network adapter bridged or NAT? If NAT, you have the same subnet on both sides of it, which will not work.

Fixed by disabling dhcpv6 which I didn't even need because router advertising is enough to get ipv6 working. Still don't know why dhcpv6 was causing the cpu spikes though.

Great input, I'll look into each of these and learn about them. Thanks very much again.

@stephenw10 said in Trying to Understand Traffic Graphs: The GUI will become laggy when it has no upstream connectivity. That can be significantly worse on the dashboard where you may have several widgets that try to resolve DNS and check external sources. The update check, support status check, package update check, dyndns entries for example all have to time-out. However it should not take 3 minutes. That seems more likely all the cpu cycles were being used for some process that could not complete. Steve Thank you for explaining the lagging experience Steve! My 3 minutes was a guess estimate...I thought it checked for update when first launching Dashboard though. Dashboard was already opened.

@jasonsmith said in help me out too.: Below is the output of Pfsense when network fails This may have been omitted, let's see it.

You can disable MSIX for just em devices so that other PCI devices can still use it. Add to /boot/loader.conf.local hw.em.msix=0 If your NIC doesn't support MSIX though it won't be using that anyway. Steve

@MrSassinak said in No matter what I do, through pfSense I'm getting between 190-200Mb down, and between 400-600Mb up..: 1f418086 That's an Avoton device ID. Are you sure that's not a C2000 CPU? Otherwise it's a C2000 based add on card, which is possible. It should still pass 1Gb either way unless it's like C2350 without turbo mode.

I just did this and noticed no packet loss pinging the pfSense interface on another VLAN on the same lag. 0% loss pinging at 0.5 second intervals. 192.168.223.1 is the pfSense interface address on lagg0.223 Throughout this ping I created VLAN 1501 on lagg0, OPT17 on lagg0.1501, and enabled/numbered/applied OPT17. --- 192.168.223.1 ping statistics --- 444 packets transmitted, 444 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.169/0.664/159.686/7.556 ms At what point does the loss occur? When you add the VLAN? When you create the new interface using that VLAN? When you enable, number, and apply the new interface? What does the system log show when you add an interface? Does your switch log show anything interesting? ETA: No loss pinging through the firewall on removal of the same.

Start with a Multi-WAN configuration. No I don't know of a guide for that specific set of circumstances. It's pretty uncommon. I would start by just getting the two WANs and the PtP working between the sites, then work on using that PtP as a backup WAN for each side.

If the local router gives you a private IP from it's own DHCP server you can just set the WAN DHCP client to refuse leases from that server. But you can only do that if the DHCP server that hands you a public lease is not that same IP. Otherwise you've refused all leases https://docs.netgate.com/pfsense/en/latest/book/interfaces/ipv4-wan-types.html#dhcp Steve

You should start a new thread for this and detail exactly what you're seeing and what you have done. There are numerous reason you could be seeing less throughput that you expect. The chances you are hitting the same issue as the OP in this thread are low. Steve

@stephenw10 Yeah i have been searching for that too, haven't found it yet...

@stephenw10 Good idea, I'll take a look in Wireshark at the result, that might give some clues. I removed the hardset 1492 MTU from the config and let PPP negotiate the MTU. It still came up 1492 as expected. Its odd that it only happens in bursts, the first about an hour after resetting the link. I haven't seen anything since. I've also asked the ISP if there is anything happening at their end just in case. regards Tim