Default deny rule being hit, even though ALL traffic is allowed.

[foss-johnny]

Hi,

I'm looking in the Live Firewall logs for my LAN interface, and I can see that the default deny rule is periodically blocking 443 traffic, even though my firewall policy for that interface has a rule that allows all ports and protocols.

How can I track down what is causing this?
Is there a way to run a debug trace, and see what object in OPNsense is triggering this and determine why it's not being allowed out based on the interface rule?

Most tcp 443 traffic is being allowed, just randomly some of it is being blocked. It's also happening on other ports too, not just tcp 443.

Thanks!

[Patrick M. Hausen]

Click on the details for one of those blocking incidents and post them.

The most common cause of unexpected "default deny" is asymmetric routing. So a diagram of your network would also be helpful.

[Patrick M. Hausen]

Please attach here. I categorically block so called "image hosting services".

[foss-johnny]

Please attach here. I categorically block so called "image hosting services".

[foss-johnny]

Click on the details for one of those blocking incidents and post them.

The most common cause of unexpected "default deny" is asymmetric routing. So a diagram of your network would also be helpful.

Here's a basic network diagram:

[foss-johnny]

Just checked the details of the log file, and can see it's for protocol 6, which is IPv6.

I added in a specific interface rule for IPv6, however I'm still seeing traffic being blocked in the Live Logs.

Do I need to setup IPv6 somewhere else as well?

What's strange is that the source address is in IPv4 format, not IPv6.

[meyergru]

Do you actually see blocked websites or are these just random log entries? One that you posted is from Google and it has a FIN-ACK state.

Therefore, potentially, you see artifacts from QUIC traffic - I see those, too.

You can test if you allow HTTP3/QUIC traffic and see if the test triggers those log entries. Wait a bit, it may be that the TCP stream must be closed to cause a log entry.

[foss-johnny]

Do you actually see blocked websites or are these just random log entries? One that you posted is from Google and it has a FIN-ACK state.

Therefore, potentially, you see artifacts from QUIC traffic - I see those, too.

You can test if you allow HTTP3/QUIC traffic and see if the test triggers those log entries. Wait a bit, it may be that the TCP stream must be closed to cause a log entry.

Thanks for your suggestion. I was able to browse to the cloudflare page without issues. Looking in the live view log, I don't see a blocked entry for it either.

It's prodominately tcp 443, but have noticed other ports too; 5223 and 6159.

I haven't put my finger on anything that is not working that I can consistently use as a test. Everything seems to be working.

I'm seeing the blocked traffic originate from multiple different clients.

[pfry]

Just checked the details of the log file, and can see it's for protocol 6, which is IPv6. [...]

In this case it's referring to TCP. HTTPS protocol over TCP protocol over IPv4 protocol, so to speak.

[...] One that you posted is from Google and it has a FIN-ACK state. [...]

An over-aggressive session timeout or lost ACKs could cause this, but either would seem highly unusual.

The direction seems odd, but it's been a while since I watched enough TCP streams. Does the server normally close the TCP session?

I don't see any "FA" logs on my firewall (",FA," in "Firewall: Log Files: Plain View"). Offhand - I didn't care to wait for a full search. I do use QUIC, as I listen to YT in the morning.