Linux apt update/upgrade stopped working
-
But is the block still in the table?
-
@maddy_in65 said in Linux apt update/upgrade stopped working:
@stephenw10
Tested apt updates by disabling & uninstalling Snort but no luckSnort (and Suricata), when running in Legacy Mode Blocking, utilizes the pfSense firewall engine for blocking an IP address. It does so by making a system call that results in placing the IP to be blocked into a pre-defined
pf
table called snort2c. This is the table @stephenw10 is asking you about. Even when you disable the Snort service, or if you remove the package, any IP addresses that have been previously added to that snort2cpf
table remain there and the blocks will persist.You can clear the table three ways: (1) when Snort is installed, go to the BLOCKS tab and click the button to remove all blocked hosts; (2) use the option under DIAGNOSTICS > TABLES in pfSense to display the snort2c table and remove any resident IP addresses; or (3) by rebooting the firewall. Rebooting clears the table of IP addresses because the table is purely a RAM construct.
BUT, I don't think Snort is your problem here. Way back up you showed a screenshot of the BLOCKS tab from Snort, and there were zero blocked hosts displayed. That means Snort is not blocking anything. It reads the snort2c table contents directly and displays them on that tab, so if the tab shows no blocks then the table is empty.
-
@stephenw10
There is no host entry in snort2c table. -
Mmm, not Snort then. It sure 'feels' like Snort though because it definitely blocks apt update traffic if you just enable all the signatures. I've seen that myself.
Something else is preventing it on that VLAN then. Is there anything else the traffic passes through? Filtering on an access point or similar?
Otherwise I would be looking at states and running packet captures to see what's actually happening.
Steve
-
@maddy_in65 From what you've posted it seems like only outbound traffic to port 80 from the problem VLAN is failing. Maybe run
grep ' 80 ' /tmp/rules.debug
and look for something other than the standard "anti-lockout rule"?