Device Reboot, Not a Kernel Panic

johnpoz

Also there is a port 0 block, high up in the rules.. That you wouldn't be able to remove without considerable effort..

block drop quick inet proto tcp from any port = 0 to any label "Block traffic from port 0"
block drop quick inet proto udp from any port = 0 to any label "Block traffic from port 0"
block drop quick inet proto tcp from any to any port = 0 label "Block traffic to port 0"
block drop quick inet proto udp from any to any port = 0 label "Block traffic to port 0"
block drop quick inet6 proto tcp from any port = 0 to any label "Block traffic from port 0"
block drop quick inet6 proto udp from any port = 0 to any label "Block traffic from port 0"
block drop quick inet6 proto tcp from any to any port = 0 label "Block traffic to port 0"
block drop quick inet6 proto udp from any to any port = 0 label "Block traffic to port 0"

beachbum2021

@johnpoz current rules

johnpoz

Those are the rules pfsense shows you, there are quite a few hidden rules.

If you want to see the full rule set

pfctl -sr
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html

beachbum2021

@johnpoz i wasnt aware of this, i will open a shell and verify. TYVM

johnpoz

I love the comment when you look at
/tmp/rules.debug

Above those rules ;)

# We use the mighty pf, we cannot be fooled.

beachbum2021

@johnpoz unable to post in text as the site is saying it's spam but i believe these were the rules you were refering to.

bmeeks

I am beginning to suspect that maybe Suricata is actually on your WAN interface and not your LAN (or else it is on both). Suricata lives between the NIC and the kernel network stack, so when on the WAN it will see traffic before firewall rules have been applied.

However, seeing WAN traffic with a destination of one of your internal RFC1918 IP addresses is weird.

Do you, or did you, by chance have a misconfigured device on your LAN? That would explain this traffic. Because if that device had the 154.21.21.141 IP, it would have sent its traffic to the gateway (pfSense) in order to reach your internal 192.168.1.103 host. Again, on the LAN Suricata would see the traffic before the firewall rules would (for inbound traffic on that interface).

beachbum2021

i cant speak for what may have been misconfigured at the time of posting but it's possible I had accidently enabled it at that time but at this moment it's only enabled on the LAN and OPT1 which are both internal. Is it possible that the firewall had crashed before the reboot and logged some free flowing traffic?

bmeeks

@beachbum2021 said in Device Reboot, Not a Kernel Panic:

i cant speak for what may have been misconfigured at the time of posting but it's possible I had accidently enabled it at that time but at this moment it's only enabled on the LAN and OPT1 which are both internal. Is it possible that the firewall had crashed before the reboot and logged some free flowing traffic?

It's just really weird for the traffic to have that 192.168.1.103 address as the destination if the capture was directly off the NIC (which is the way Suricata would have gotten it on the WAN interface by way of libpcap). Traffic on the WAN should normally have the public IP of your firewall as the destination (for most users with NAT).

beachbum2021

@bmeeks im with you, i think the IP spam and the reboot are not related and there may have been a temporary misconfiguration. The M.2 drive I installed two weeks ago could have faulted and it's just a coincidences both of these anomalies occurred at the same time. I'm not sure there's much that can be done at this point unless the issue returns in the same facet.