@mgcsec said in pfsense packet process order: @stephenw10 thank you! and then where are local services/plugins involved? for example Nginx in that chain? NAT=>FW=>Nginx=>NAT=>FW=>Upstream? For some services, yes, this is the processing order. But for others such as the IDS/IPS packages, this is the processing order: IDS/IPS => NAT => FW (for inbound traffic on WAN) IDS/IPS => FW => NAT (for inbound traffic on LAN)

Do that have the same capabilities? Try: ifconfig -vvvma Are those vmxnet NICs the pfSense VM has assigned currently? If not try assigning one to something and see if that responds to large packets. This seems likely to be an issue with the bxe driver or the NIC itself but we need to confirm that by, for example, showing vmx is not affected. Steve

Hi Steve - Brilliant suggestion. Evidently my password manager was pre-empting my updates. Now email works! Thanks, Neil

Aside from pcscd, you should also disable log compression when rotating on there. Given the output from top, it was the log compression that was having trouble keeping up with the rate of logs being written at the time. Status > System Logs, Settings tab, set Log Compression to None.

@johnpoz root cause analysis was suggested in a different forum. Wire shark did capture vlan traffic on port going to ESX host. But pktcap-uw did not capture any on vmnic. Promiscuous mode was enabled too. Switch configuration is correct. Only data point which I still could not figure out is wireshark trace contains icmpv6 but not icmp dhcp discovery. Neither ipv6 is enable on pfsense or unifi.

@rbarden I use NTOP-NG. But nothing is "free" in terms of cpu cycles or promiscious mode on the netcards. /Bingo

thank you

That doesn't seem like a huge number for 5 mins. I would expect far more if you were actually being used as part of an attack. That seems like it could just be a bad DNS server configured. Steve

@adrianoebm I seen that on a 3100 months ago when I restored configuration from a different device. I think the issue may have been packages trying to install that were not compatible but I ended up resetting it and not using it. I would suggest backing up the configuration and skip packages, then do a restore and see if that resolves.

Can you ping6 to other internal hosts? Is pfSense handing out those IPs via dhcpv6? That would imply it's receiving a prefix from the ISP. Steve

@ev4nsp479 Do you have a spare switch you can put between them? Comcast hardware sometimes will care if the MAC of your router changes unexpectedly, but powering off their router should start fresh.

Hmm, so if you just lose upstream connectivity there's not much pfSense can do. You probably need to find out exactly how it's failing. If the gateway is still responding try a traceroute when it's working and when it fails. Where is it failing?

@jimp Thank you!! That got it. I copied the files from the netgate fw up to my PC. I don't know why, but the netgate sg3100 did NOT have UCD-DISKIO-MIB.txt UCD-SNMP-MIB-OLD.txt so I copied them from the net-snmp 5.9.1 source tarball. I'm still missing the MIB for begemot.203 $ snmpwalk netgate-fw begemot.203 2>/dev/null BEGEMOT-MIB::begemot.203.0.0 = INTEGER: 0 BEGEMOT-MIB::begemot.203.100.0 = STRING: "/usr/local/etc/rrdbot" BEGEMOT-MIB::begemot.203.101.0 = STRING: "/var/run/snmp-regex.sock" and this is wrong: $ snmpwalk netgate-fw begemotIfMaxspeed 2>/dev/null BEGEMOT-MIB2-MIB::begemotIfMaxspeed.1.0 = Counter64: 2500000000 bps BEGEMOT-MIB2-MIB::begemotIfMaxspeed.2.0 = Wrong Type (should be Counter64): Timeticks: (100) 0:00:01.00 BEGEMOT-MIB2-MIB::begemotIfMaxspeed.3.0 = Wrong Type (should be Counter64): Timeticks: (0) 0:00:00.00 BEGEMOT-MIB2-MIB::begemotIfMaxspeed.4.0 = Wrong Type (should be Counter64): Timeticks: (100) 0:00:01.00 but I can live with that. I can't tell if I'm missing some more MIB file[s] or the BEGEMOT-LM75-MIB is broken, but $ snmpwalk netgate-fw sysLocation Unlinked OID in BEGEMOT-LM75-MIB: lm75SensorTemperature ::= { lm75SensorEntry 7 } Undefined identifier: lm75SensorEntry near line 153 of /usr/local/share/snmp/mibs/netgate/BEGEMOT-LM75-MIB.txt Unlinked OID in BEGEMOT-LM75-MIB: lm75SensorParent ::= { lm75SensorEntry 6 } Undefined identifier: lm75SensorEntry near line 145 of /usr/local/share/snmp/mibs/netgate/BEGEMOT-LM75-MIB.txt Unlinked OID in BEGEMOT-LM75-MIB: lm75SensorPnpInfo ::= { lm75SensorEntry 5 } Undefined identifier: lm75SensorEntry near line 137 of /usr/local/share/snmp/mibs/netgate/BEGEMOT-LM75-MIB.txt Unlinked OID in BEGEMOT-LM75-MIB: lm75SensorLocation ::= { lm75SensorEntry 4 } Undefined identifier: lm75SensorEntry near line 129 of /usr/local/share/snmp/mibs/netgate/BEGEMOT-LM75-MIB.txt Unlinked OID in BEGEMOT-LM75-MIB: lm75SensorDesc ::= { lm75SensorEntry 3 } Undefined identifier: lm75SensorEntry near line 121 of /usr/local/share/snmp/mibs/netgate/BEGEMOT-LM75-MIB.txt Unlinked OID in BEGEMOT-LM75-MIB: lm75SensorSysctlIndex ::= { lm75SensorEntry 2 } Undefined identifier: lm75SensorEntry near line 113 of /usr/local/share/snmp/mibs/netgate/BEGEMOT-LM75-MIB.txt Unlinked OID in BEGEMOT-LM75-MIB: lm75SensorIndex ::= { lm75SensorEntry 1 } Undefined identifier: lm75SensorEntry near line 105 of /usr/local/share/snmp/mibs/netgate/BEGEMOT-LM75-MIB.txt Unlinked OID in BEGEMOT-LM75-MIB: lm75Sensor ::= { begemotlm75Objects 1 } Undefined identifier: begemotlm75Objects near line 64 of /usr/local/share/snmp/mibs/netgate/BEGEMOT-LM75-MIB.txt Unlinked OID in BEGEMOT-LM75-MIB: begemotLm75Objects ::= { begemotLm75 1 } Undefined identifier: begemotLm75 near line 58 of /usr/local/share/snmp/mibs/netgate/BEGEMOT-LM75-MIB.txt Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorIndex ::= { lm75SensorEntry 1 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorSysctlIndex ::= { lm75SensorEntry 2 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorDesc ::= { lm75SensorEntry 3 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorLocation ::= { lm75SensorEntry 4 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorPnpInfo ::= { lm75SensorEntry 5 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorParent ::= { lm75SensorEntry 6 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorTemperature ::= { lm75SensorEntry 7 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75Sensor ::= { begemotlm75Objects 1 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorTable ::= { begemotLm75Objects 2 } Cannot adopt OID in BEGEMOT-LM75-MIB: begemotLm75Objects ::= { begemotLm75 1 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75Sensors ::= { lm75Sensors 1 } Cannot adopt OID in BEGEMOT-LM75-MIB: loosTempSensorEntry ::= { lm75SensorTable 1 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorTemperature ::= { lm75SensorEntry 7 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorParent ::= { lm75SensorEntry 6 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorPnpInfo ::= { lm75SensorEntry 5 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorLocation ::= { lm75SensorEntry 4 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorDesc ::= { lm75SensorEntry 3 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorSysctlIndex ::= { lm75SensorEntry 2 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorIndex ::= { lm75SensorEntry 1 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75SensorTable ::= { begemotLm75Objects 2 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75Sensor ::= { begemotlm75Objects 1 } Cannot adopt OID in BEGEMOT-LM75-MIB: begemotLm75Objects ::= { begemotLm75 1 } Cannot adopt OID in BEGEMOT-LM75-MIB: lm75Sensors ::= { lm75Sensors 1 } Cannot adopt OID in BEGEMOT-LM75-MIB: loosTempSensorEntry ::= { lm75SensorTable 1 } SNMPv2-MIB::sysLocation.0 = STRING: so I deleted BEGEMOT-LM75-MIB.txt and all the errors went away :) $ snmpwalk netgate-fw sysLocation SNMPv2-MIB::sysLocation.0 = STRING: Thanks again!!

@stephenw10 Thanks Steve your reply is really appriciated I'll go down the update route hopefully reslove the issue All the best, John

@csfshore As this doesn't appear pervasive, it must be something in my config. (Which is vanilla, honest ) When new release 21.09 is out, I will take it down to the bare metal and reinstall, unless I can figure out anything from the logs.

Anything is possible with the right script. But as you right pointed out there are security implications to that. You might consider using URL aliases which are already setup to pull lists from remote servers. https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html#url-aliases Have a look here for some ideas: https://docs.netgate.com/pfsense/en/latest/backup/remote-backup.html#alternate-remote-backup-techniques Steve

@stephenw10 As shared on another thread: Here is a series of screenshots that might help you help me. https://www.dropbox.com/sh/zbcxeaujmmfo4xf/AADDmYE3XDL2uZdbG62Ihayfa?dl=0 This might help resolve also this situation when I LOOSE my connection over wifi after a while. :/

See: https://docs.netgate.com/pfsense/en/latest/recipes/port-forwards-from-local-networks.html Steve

For future reference - could of spotted this problem right away by looking on the sniff when reply traffic went out the wan. Validating the mac address on the outgoing traffic.

Unlikely, it's just forwarding in and out between two directly connected subnets. Some MTU mismatch could cause that sort of problem. Steve