@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

Yeah, I would start out with some basic shaping here using PRIQ. Put RDP and VoIP as high priority and everything else low. Start out as simple as you can, it's easy to end up with something far too complex for traffic shaping. Steve

Yes I would still reinstall from there but if you are trouble-shooting that I'd run: pkg-static -d update That will show you whatever issue is preventing it see updates. Steve

@stephenw10 I had them bridged, but missed removing DHCP from the first interface. I redid the config with DHCP on the bridge and it works fine now. Thanks!

@stephenw10 said in Comm Error Packages Section: Do you have that installed only on the Primary perhaps? Why are you running 2.5.2-RC and not Release? Are you actually running different versions on each node? That will break sync for good reason. Steve

Yes, the ix ports are generally not compatible with SFP-RJ45 modules. We have seen some reports of modules working but if do it's by luck only! The SoC NICs cannot read the module data. Steve

Not easily. Not via the normal interfaces assign dialogue certainly. I would probably generate a basic config file and import it for this. Or just assign one of the 1G NICs as WAN initially so you can access it and create the LAGG in the GUI vefore deploying it. Steve

Yes, that's correct. LAN side clients should be using the pfSense LAN IP as their gateway. pfSense should only have one gateway itself though in a simple setup like that. If it has more that one (probably wrong) it might be choosing the wrong one. Setting the default gateway to WAN_DHCP does not hurt in any case. Steve

Yes, exactly. You could allow access only to an alias containing a list of known MS IPs. Then block access to everything else on port 80 and 443. Or just on all ports if you need to. You can probably use either a URL alias or via pfBlocker to create that alias and update it automatically. Something like this: https://forum.netgate.com/topic/137691/office365-ip-list Steve