Default deny rule question

[eblot]

Hi,

I was looking at the firewall logs, and there are not deny packets I fail to understand, e.g.:


    LAN      Aug 29 10:48:09   192.168.83.173:50928   17.252.76.99:5223   tcp   Default deny rule


192.168.83.0/24 is my LAN, the WAN net is 192.168.29.0/24
If I get it right, the deny comes from the floating, automatically generated rules, that applies if no other rule match.


    IPv4+6 *   *   *   *   *   *   *   Default deny rule  (last match)


However, one of the (default) LAN rules is:


    IPv4 *   LAN net   *   *   *   *   *   Default allow LAN to any rule  (first match)


Devices on LAN seems to be able to access the Internet (through the WAN). I'm posting this very message from this configuration.

Why could cause the "Default deny rule" to apply on these packets and how to troubleshoot this issue?
I do not get why these packets seem to be blocked and I'm still able to access the Internet... Do I misinterpret these log entries?

Thanks.

[marcri]

Have a look at the TCP-flags, maybe they differ

[eblot]

TCP flags on LAN net rules are all deselected.

I do not know how to get the one from the generated rules, as there is no "edit" button... :-(

[fruit]

I had problems with Default deny rules a few weeks back but this was IPv6, or seemed to be, and large mails getting out:- https://forum.opnsense.org/index.php?topic=13744.0. ('Allow IPv6' is now within Firewall => Settings => Advanced)

I can't see that there would be a connection - but then I cannot understand how or why the solution to my issue worked

[eblot]

I do not think it is related to IPv6, as log shows only IPv4 addresses. This is still a mystery for me...

[franco]

Default deny for "legit" traffic is an indication for state tracking failures which the firewall is by default set to drop. Look for network loops or bad switches, sometimes a simple power cycle is enough.

If not use sloppy pass rules in your LAN to avoid drops / logs associated with bad state packets.

Basically this is not a firewall problem: it observes your packages out of order for an external reason so there is no fix on the firewall as it can only enforce strict state for in order packets or you explicitly allow it to ignore its keen observation.


Cheers,
Franco

[eblot]

Look for network loops or bad switches, sometimes a simple power cycle is enough.

There's only a single switch and one access point (with an embedded switch) on the LAN side.  I will try to remove each of them one after another thanks.

Am I right to assume that if a LAN packet is dropped and logged, the issue comes from the LAN and not another nework (WAN here)?

If not use sloppy pass rules in your LAN to avoid drops / logs associated with bad state packets.

I'm not sure to understand how to do that...?

Basically this is not a firewall problem [...]

Ok. Is there a way in the firewall to add more debug info about the reason for the rejection/drop?

Thanks,
Emmanuel.

[eblot]

I just observed this one:


lo0      Aug 30 16:25:40   127.0.0.1:3493   127.0.0.1:9388   tcp   Default deny rule


lo0 is not a physical device, why would the localhost denied to talk to itself?

and looking back in history, there are much more similar issues on localhost...

[Serius]

I'm also interested, as I'm having the same problem, and I would bet that never seen this before the last update.
Did you find the cause for this? I don't think it may be caused by bad hw, as I only have a wan modem and a L2 switch.

Code: [Select]

TLAN Aug 30 16:18:43 192.168.10.55:46524 74.125.133.92:443 tcp Default deny rule
TLAN Aug 30 16:18:43 192.168.10.55:46524 74.125.133.92:443 tcp Default deny rule
TLAN Aug 30 16:18:43 192.168.10.55:46524 74.125.133.92:443 tcp Default deny rule
TLAN Aug 30 16:18:43 192.168.10.55:46524 74.125.133.92:443 tcp Default deny rule
TLAN Aug 30 16:18:43 192.168.10.55:40513 216.58.211.42:443 tcp Default deny rule
TLAN Aug 30 16:18:43 192.168.10.55:44061 31.13.83.51:443 tcp Default deny rule
TLAN Aug 30 16:18:42 192.168.10.55:44061 31.13.83.51:443 tcp Default deny rule
TLAN Aug 30 16:18:42 192.168.10.55:46011 172.217.17.10:443 tcp Default deny rule
TLAN Aug 30 16:18:41 192.168.10.55:40513 216.58.211.42:443 tcp Default deny rule
TLAN Aug 30 16:18:41 192.168.10.55:46011 172.217.17.10:443 tcp Default deny rule
TLAN Aug 30 16:18:41 192.168.10.55:46011 172.217.17.10:443 tcp Default deny rule
TLAN Aug 30 16:18:41 192.168.10.55:40513 216.58.211.42:443 tcp Default deny rule

For the nonce, it seems to affect wifi devices accesing internet (google cdns I would say) because I've seen my phone, wifes and the TV (android)

TLAN is my trusted lan and it has no other rules than default. Also, I don't know if it's normal that the floating rules seem to have order inverted, so "default deny rule" sits the first of them.

[eblot]

I'm also interested, as I'm having the same problem, and I would bet that never seen this before the last update.

I'm not sure how it was before the last update, but I'm sure there is something new (and worse): every time I apply (edit, add, delete, ...) a FW rule, the changes are actually committed, but my browser never recover: I have to stop the current request, and reload manually... I never noticed this issue before, but I'm not sure it is tied to a peculiar OpnSense release.

[Serius]

every time I apply (edit, add, delete, ...) a FW rule, the changes are actually committed, but my browser never recover: I have to stop the current request, and reload manually...

Yes! I also experienced this. Not always, but from time to time.
Look, all the IPs being blocked now are from Google netherlands:
216.58.211.42, 172.217.17.10, 172.217.17.4 All google
161.117.71.92 And this one is Aliexpress cloud. Should be normal as I have a Xiaomi phone and Aliexpress app intalled.

I have deactivated bogon nets detection in case.

PS. I have created a manual default block rule in my wan interface and I'll be monitoring the floating one.
In my case, I have internet connection through a ISP router that doesn't put into bridge, so I have to configure a DMZ and the traffic between the "modem" and opnsense it's using private ips schema. Perhaps that will indicate a pattern.
Now an amazon cdn blocked: 34.216.252.86 -> United States Portland Amazon Technologies Inc.

[l0stnyc]

I had this problem as well during 19.7.2.  I saved the config followed by a restore and it went away.  I figured the config got corrupted after some change.

[Serius]

That's the version in which I started to get problems.

I just updated from 1.9.2 to 1.9.3 and now it's worse. I've seen internal NFS blockages (I have rules allowing) and one strange line with both external IPs as source and destination.
I'm starting to get scared of this. I think I will activate the silly firewall in the ISP router.