Your modules don't need to 'vendor match' on each end, but they'll need to negotiate a link speed between them. SFP+ modules are typically 10G, while SFP are 1G. You CAN plug an SFP into a SFP+ slot, but you can't do the reverse. You'll have to look at module specifics if you want a 10G fiber to negotiate down to 1G, I've never done it and I don't know how well it's supported. Since it's a Supermicro chassis, and not something proprietary like Cisco, you should be able to pretty much use any vendor module on that side; I can't speak to UniFi on what modules they accept. So in a nutshell, you should be fine getting two 1G SFP UniFi (Ubiquiti) modules. Personally, I wouldn't pay $15+ for a 1G fiber module.

@chidmas said in Low bandwidth extremely low for local network to WAN however normal for pfsense box to WAN.: N3050 I'm wondering if your CPU is getting choked out, it's pretty low spec with only two threads. Have you tried, and can you provide, the following: Monitored the CPU load while doing the hard-wired speed test Provide the model of the Intel nic Do a direct connect speed test (remove all hardware, just pfsense + workstation) check your logs for any errors

@Gertjan Oh god! I did change what you suggested and it fixed my issue! I am not sure myself why i did change it but i'm defininitely learning from my mistake. Thank you so much!

@jimp, I'm sorry but I'm afraid that something is wrong because in "Firewall > NAT > Port Forward" works well, when I change the value of the Virtual IP (CARP) in "Firewall > Virtual IP" It updates dinamically in "Firewall > NAT > Port Forward" but not in "Firewall > NAT > Outbound". Example. Firewall > Virtual IP > VIP CARP DEDI_NIC_FO (Type: CARP) => 80.80.80.80 Firewall > NAT > Port Forward: In the NAT Port Forward Rule We select Destination: VIP CARP DEDI_NIC_FO [image: 1590508941581-01-nat-pf.png] In the Rule appears the correct value of VIP CARP DEDI_NIC_FO. [image: 1590508950882-02-nat-pf.png] Firewall > NAT > Outbound: In the NAT Outbound Rule We select Translation > Address: VIP CARP DEDI_NIC_FO. [image: 1590509285180-03-nat-out.png] In the Rule appears the correct value of VIP CARP DEDI_NIC_FO. [image: 1590509397980-04-nat-out.png] We Edit and Change Firewall > Virtual IP > VIP CARP DEDI_NIC_FO (Type: CARP) => 90.90.90.90 Firewall > NAT > Port Forward: In the Rule appears the correct value of VIP CARP DEDI_NIC_FO. It's changed dinamically. [image: 1590509542613-05-nat-pf.png] Firewall > NAT > Outbound: In the Rule appears the old value of VIP CARP DEDI_NIC_FO. It's not changed dinamically. [image: 1590509637187-06-nat-out.png] I think that It's not correct. Is this the correct way of operating or should It change dinamically too? Regards, Ramsés

RRD intentionally aggregates data into larger intervals as the data gets older. The monitoring graphs are intended to provide troubleshooting information, not be a high-resolution, historical archive. For that you can query the device using something like cacti or zabbix or a plethora of others. Setting 8 hours x 1 minute resolution is pretty comprehensive. Anything longer than 8 hours and the resolution will be reduced.

@lifespeed So, don't select that. I don't know what you've done, but sometimes it's best to start from scratch, in case you did something you shouldn't have. Perhaps there's someone else here, who can help you with Comcast. My experience is with Rogers, where IPv6 works well.

I don't know why, but it started again on Sunday: Tue, 03 Mar 2020 02:00:18 +0100 (system): Scheduled backup Wed, 04 Mar 2020 02:00:19 +0100 (system): Scheduled backup ------- Sun, 24 May 2020 02:00:38 +0200 (system): Scheduled backup Mon, 25 May 2020 02:00:37 +0200 (system): Scheduled backup I haven't changed anything (not even a reboot).

I have no good reason for using 8.8.8.8; I did this as part of trying to diagnose this issue, as the behaviour I was observing was that the internet was unavailable, but the gateway was still reporting as up, my supposition was that the ISP was prone to upstream failures - but I can revert this. I don't follow the recommendation (my lack of knowledge). Are you saying that the gateway alarm is result in openvpn restarting, and (for some reason) - that this resulting in being me unable to make connections outbound from LAN to WAN?

Yes found that yesterday while fiddling with sysctl ;) Made a PR to update the doc : https://github.com/pfsense/docs/pull/125

So I created a script in /usr/local/etc/rc.d/ containing /sbin/ifconfig re0 promisc which solves the problem. But why all of a sudden pfsense started behaving like this?

AFAIK the Interface statistics are pulled from netstat counters and there is no way to reset them from the command line. The one and only way is to reboot. -Rico

This got me today. I can confirm the floating rule for ICMP solves the issue.

@stephenw10 Thanks a lot for your response Steve. I have just given up and factory reset pfsense. But your comment will be useful when I setup PIA (Yeah abbreviations are hard lol) VPN in a later date.

You can also achieve this with telegraf and the exec plugin (sysctl)

Got it. I have no issues waiting for p1 to appear I'm just trying to look at this as a learning opportunity. Thanks for all your help @teamits.

Software update on Mikrotik from 6.44.1 to 6.46.6 solved the problem. Sounds like Pfsense is handling some things a little bit differently than client/consumer OSes and this was an issue for Mikrotik. Thanks for help.

I installed in ZFS pfsense test environment I'm still trying, working for now, I continue sudden closings I will install on the real system when I get results

Glad to report it's fixed. After several existential crises I found the problem. Ends up while I was doing 498758967456798430674551 different things, I swapped some ports around, and got some bad routes. For whatever reason, PFSense preferred the bad routes to the good one. So I just went to "Diagnostics --> States --> Reset States" and reset all (literally the only option). Anyway, after giving everything a minute or two....it all just worked. I have no idea why those routes didn't clear out, but it's CERTAINLY a tool I'll remember in the future!!!

+1 there you go. ;-) -Rico