There's a FreeBSD port for it but based on little googling the pfSense package just wasn't maintained by anyone and was dropped. https://www.freshports.org/mail/spamd/ https://forum.pfsense.org/index.php?topic=100334.0

Since my last post I've tried: several cables several BIOS versions several combinations of BIOS settings (especially around the interrupts/serial console) almost all of the things on the boot problems page two hard disks ZFS/UFS 2 different versions of I350 firmware many combinations of loader.conf.local settings including disabling beastie_mode blanking out the SMBUS pins on the I350. All my experiments still end up with  "crash at the pfsense boot menu when there is traffic on the I350 during (or before) loading the kernel." The network configuration boots fine with a Watchguard X750e (but that is stuck on nano-bsd) Is there really nobody that can help? I did ask the mods several weeks back if they could move this thread to somewhere more appropriate - was there or did they not look? Is there any way to force the network ports to be disabled until the kernel  boots up? Thanks

@steve40: Hiya Meeks… I got all the suricata file matching stuff working ...thanks for your help I identify binary files and block them via an empty hash whitelist. Which basically turns the box into a carbon black operating at the gateway level.  Works like a charm. (as long as you got pass rules for microsloth and places you wanna get exes from) It all works like a charm UNTIL..... you go to download an executable from an HTTPS enabled site. So out of desperation I'm going to ask a stupid question Is there a way to intercept these files while passing through an HTTPS session? I've got MITM fully working but I'm guessing that suricata operates at the NIC card and Squid decrypts the packet way higher up the stack... I really really really don't wanna have to do virus checking via ClamAv By the way, I've got this whole setup running on a KVM hypervisor so I can get very creative If I need to thanks Suricata and Snort both work at the NIC card level (more or less).  When looking at the flow from the point of view of inbound traffic from the Internet, Suricata or Snort is the first thing the packet sees after leaving the NIC on the way into pfSense.  Any MITM stuff is farther down the line (or higher up in the stack if you want to think from that perspective).  So all Suricata is going to see is the raw HTTPS encrypted datastream. Bill

Hey there Normally you would assign your WAN interface to the NIC that's connected to your public IP address and your LAN interface to the private subnet. I would not recommend to assign your LAN interface to a private subnet and to your public IP address simultaneously in any case whatsoever. IMHO, the assignments should be like this: WAN -> public IP address provided by Azure (only) LAN -> private subnet (only) I don't think it's necessary or that it makes sense to add some virtual IP in this case. I'm not familiar with Azure, but if you can add more virtual interfaces to your pfSense VM, go ahead and add one if you need another private subnet. Now of course with this configuration you can not access the Web Configurator from the Internet. But I wouldn't recommend making it available to the Internet anyways. So if you can keep your Windows VM that's in the same private subnet, access the Web Configurator from there. Of course there are other options to get to what you're trying to achieve, but I think just using another VM in the same private subnet is the easiest way. Greetings, Philipp

Thx for the replies!  Although nmap reported only 1 dhcp sever on the network, I found an access point with dhcp turned.  I'm assuming this was the issue…..

Squid has a traffic management page that allows you to specify a maximum download size, and have it apply only to specific file extensions such as txt.

If you can ping other sites, but not the email server, the problem is likely with that server.  However, they may have pings blocked.

In case you haven't figured it out yet, firmware 1.5.11 (1.5.12?) breaks access to 1.1.1.1.  This ip is now some sort of internal ip within the gateway (bgw210).

All you have to do is Diagnostics > Packet Capture on WAN for port TCP 445 then run a scan. If you get a connection refused (CLOSED) but do not see the traffic on WAN, then something upstream is responding. If they are responding AND forwarding the traffic to you (which wouldn't make much sense) then you will see the SYN to port 445 on your WAN but no SYN/ACK response because you are blocking the port.

Ok, thanks for confirming.

Probably something changed at your ISP or they were doing maintenance etc. Certainly not unusual. Steve

@stephenw10: Yes, keep 400,000. As Johnpoz says above that will be the default value in the next release and in current 2.4.4 snapshots. Steve Got it / Thanks

ok look, I actually restored my config after I tried all the possible fixes, i tell you not even a vanilla installation fixes it, and i dont want to bother my self to resinstall pfsense just to post new logs. you can just use your imagination or common sense and think of those extra packages doesnt exits. I repeat, I restored my config after I tried everything and gave up posted here to ask help and thus those logs says. just fyi that pfblocker should not be causing issues anyway since it was disabled as I posted those logs.

@jsaad: Comcast calls them micro-outages which kills the remote desktop and the phone. It’s fairly common to see 2-10 seconds outages in cable modems, I see notifications all the time from our system and I normally see this on the same sites repeatedly. Usually ends up being signal fluctuations from somewhere up the street but the ISP don’t deem them problematic enough to fix. Higher latency and jitter are also known issues with these types of service and while most applications work fine with this, VDI and RDS do not. If your customer considers these application critical than they really need to look into a fiber solution. I prefer PRI over SIP for phones but it depends on the business and their current phone system. You could look at a low speed fiber for mission critical applications and push everything else out the modem.

Just a bump on my last question about how to use a DHCP special option setting for assigning VLAN's. Thanks.

Since you haven't checked "Don't pull routes", the NordVPN gateway will be your default gateway. That means that any traffic including that one from pfSense itself (DNS) is routed to the VPN gateway. However, that won't work, cause you are missing an outbound NAT rule for pfSense. So either check "Don't pull routes" in the client settings or add an outbound NAT rule for 127.0.0.0/8 to the NordVPN interface. The outbound NAT solution should avoid DNS leaks.