I was actually thinking that it might have to do with my ISP/line. I just switched from 50/5 to 150/10, have never had problems before. This happened two nights in a row at about the same time in the evening for the same period of time. So I'm thinking it might be something like you described. Do you or anyone else have any idea how I could trace the problem without asking everyone on my street about their internet usage routines?

Nice to see freebsd having 3.17 of iperf, but there was not real change from 3.1.6 - .7 was just some typo/doc changes nothing operational. If you want the current windows version I compile a new version when it comes out and make it open to the public internet.

I can get to the pfsense gui from the clients.  I can get to a webserver on the 192.168.20.n subnet from the devices on the 192.168.20.n subnet. All interfaces on the pfSense are up, with no errors. The only errors I see in the logs are: System, General (right after a reboot): Mar 27 15:35:41 dhcpleases: kqueue error: unkown Mar 27 15:35:40 dhcpleases: Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such process. Mar 27 15:35:40 dhcpleases: /var/etc/hosts changed size from original! Mar 27 15:35:38 dhcpleases: /var/etc/hosts changed size from original! While maybe not an error, I do see these in the DHCP logs: Mar 28 05:23:28 dhcpd: uid lease 192.168.20.243 for client b8:27:eb:1c:bc:3e is duplicate on 192.168.20.0/24 Last gateway log entry: Mar 27 12:44:38 dpinger: send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 71.123.236.1 bind_addr 71.123.236.4 identifier "WANGW " The firewall log does show this periodically, which I think may be odd: x Mar 28 05:31:10 WIRELESS 0.0.0.0 224.0.0.1 IGMP

I have turned off the "forwarder," in "services -> DNS resolver," and that seems to have completely stabilized my firewall. No more notifications, no more errors, no more crashes (so far).

I recently bulk added 256 VLANs / Interfaces to an existing pfSense box with some python script and had this exact same issue, web panel slows to a crawl on certain pages and delivers 504 on interface_assign.php Figured it was my own dumb fault and tbh it's taken me far longer than it should have to find this thread and that bug report!  ::) Thanks for posting, saved me half a day of bother. :)

That is exactly what I am afraid of.  Maybe I will see if I can lock the router in a cabinet.  Not perfect, but probably better than nothing.

Thanks for a speedy hint  ;D Hmm not sure about whether it is changing, I left the mac adress boxes blank on my lan and lan_port interfaces. Maybe I could generate random macs to put in the spoof boxes and that would stop it?

Installing FreeBSD packages not included in the Package Manager is doable but not recommended. By doing so you introduce security vulnerabilities to your firewall, not a good place to add unnecessary vulnerabilities. Especially when you are adding it for a nice to have feature that you don't need at all. If you must, then search for the forums for how to do it, it can be done.

Hense my apology.

NC360T is Intel  82571EB  based card that is supported by FreeBSD. I currently have one box running  with same chipset and have no problems with cable detection. Does it work on gigabit link? Do you have problem with both ports? Card have LEDs on the both ports, do the LEDs ON/blink when the cable is connected?

I also have a similar problem (Vlan 40 Mnet) .

Are you experiencing across the across the board packet loss (the internet doesn't work at all), or is it particular to your monitor target address? If you are not experiencing across the board packet loss, the easiest guess is that the problem is to particular your monitor address. Try using a different address, such as a google public address such as 8.8.8.8 for monitoring and see if the issue goes away. If it does, you can use traceroute to help you choose an appropriate monitor address.