Firewall blockt vermehrt LAN to WAN Pakete - Wo ist der Fehler?

[tiermutter]

Moin zusammen,

bevor es zur Sache geht so wie ich es vor Jahren mal gelernt habe kurz einmal zu mir:
Ich nutze opnsense seit vergangenem Jahr für mein Heimnetz, insbesondere wegen des OVPN Servers und WAN Failover. Bei der Einrichtung und sonstigen Problemen habe ich mich immer hauptsächlich durch die Docs und Forenbeiträge geschummelt oder gemäß Try and Error ausprobiert... demnach hält sich meine Erfahrung mit der gesamten Materie etwas in Grenzen, außerdem bin ich GUI-Liebhaber der nur hobbymäßig Bezug zur IT hat

Beim Wechsel zu einem neuen ISP (Deutsche Glasfaser) im verganenen Monat habe ich auch meine Hardware gewechselt (Terra/ Wortmann RC100 G3) und opnsense 20.1.7 entsprechend neu aufgesetzt.
Mein ISP liefert mir CGNAT und natives v6, opnsense hängt direkt am Modem, alles läuft soweit einwandfrei.

Was mir auffällt sind jedoch Einträge in der FW-log auf die ich mir keinen Reim bilden kann, wobei igb0 und 10.13.12.0/24 mein LAN ist.

Code: [Select]

filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,34390,0,DF,6,tcp,76,10.13.12.60,172.217.16.138,46232,443,24,FPA,2298045867:2298045891,3739770163,376,,nop;nop;TS
Das gleiche tritt auch auf IPv6 und von unterschiedlichen Clients auf...
Wie kann es sein, dass hier Pakete geblockt werden, die vom LAN ins WAN gehen, obwohl eine default allow LAN to any Regel besteht?

Einschränkungen merke ich wie gesagt nicht, die Einträge sind nur ziemlich lästig und bereiten mir die Sorge, dass irgendwo doch der Wurm drin ist...

Sollten noch Infos benötigt werden stelle ich diese natürlich gern zur Verfügung, ich will jetzt nur nicht mit redundanten Infos um mich werfen...

Gruß

[JeGr]

IGB0 ist demzufolge dein LAN? Soweit ich den String richtig sehe, sind da die TCP Flags FPA aktiv. Das sind dann out of state Pakete, die ggf. verspätet kommen, die Firewall hat die Verbindung aber schon geschlossen/beendet. Deshalb werden die als "geblockt" dargestellt. Passiert bei kleineren Hängern/Rucklern mal oder kann auch gehäuft auftreten wenn bspw. Asynchrones Routing ein Problem aufwirft - sollte aber theoretisch in deinem Fall nicht sein, wie ich das verstanden habe. Wenn das nur ab und an mal passiert - ungefährtlich. Wenn es öfter auftritt, sollte man ggf. mal nachschauen, warum.

Grüße

[tiermutter]

Moin,

danke für Deine Rückmeldung... ja igb0 ist das LAN Interface.

"Tritt gelegentlich auf" war etwas unglücklich bzw. falsch formuliert:
Es tritt durchaus häufig auf, die logs sind quasi voll damit (seit gestern 22:45 bis heute 07:00 ca. 1000 Einträge).
Es sollte nur heißen, dass nicht alles komplett geblockt wird, da der Internetzugriff vom LAN ja nunmal funktioniert.

Asynchrones Routing (wenn ich es richtig verstanden habe mehrere default Gateways) sollte es hier zumindest nicht bewusst geben, wobei ich durchaus mehrere Gateways habe:

1. WAN_DG_DHCP6 (active)           WAN_DG    IPv6    250 (upstream)
2. WAN_DG_DHCP (active)            WAN_DG    IPv4    250 (upstream)
3. LTE_PPP                                    LTE              IPv4   254 (upstream)
4. WAN_htp_GWv4                      WAN_htp     IPv4     255

Nr. 2 und 3 sind in einer GW Group (Failover) und Nr. 3 wird nicht als upstream verwendet sondern dient lediglich (temporär) für den VPN Verbindungsaufbau über IPv4.
Für die GW Group exisitert eine entsprechende FW Regel auf LAN, die alles außer DNS an die GW Group leitet.

Ich habe mal die default pass rules auf LAN mitgeloggt um zu sehen, was um diese Meldungen herum passiert, eventuell gibt es hier ja einen Hinweis (den ich nicht sehen würde):
In rot default deny und grün default allow LAN to any; igb2 (blau) ist das WAN Interface, der Rest DNS.

2020-05-27T07:28:23   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61778,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:19   filterlog: 87,,,0,igb2,match,pass,out,4,0x0,,63,53494,0,DF,6,tcp,60,100.73.101.101,80.158.23.146,27337,80,0,S,121773098,,65535,,mss;sackOK;TS;nop;wscale
2020-05-27T07:28:19   filterlog: 101,,,0,igb0,match,pass,in,4,0x0,,64,53494,0,DF,6,tcp,60,10.13.12.60,80.158.23.146,57618,80,0,S,121773098,,65535,,mss;sackOK;TS;nop;wscale
2020-05-27T07:28:18   filterlog: 94,,,0,igb0,match,pass,in,4,0x0,,64,53583,0,DF,17,udp,84,10.13.12.60,10.13.12.2,36074,53,64
2020-05-27T07:28:18   filterlog: 94,,,0,igb0,match,pass,in,4,0x0,,64,53581,0,DF,17,udp,84,10.13.12.60,10.13.12.2,52120,53,64
2020-05-27T07:28:18   filterlog: 94,,,0,igb0,match,pass,in,4,0x0,,64,53580,0,DF,17,udp,84,10.13.12.60,10.13.12.2,36064,53,64
2020-05-27T07:28:15   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61777,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:11   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61776,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:10   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61775,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:09   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61774,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:08   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61773,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:08   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61772,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:08   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61771,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,

Leider bin ich nicht daheim um feststellen zu können was genau in diesem Moment abgerufen wurde, beim Client handelt es sich jedenfalls um ein Android Gerät.
Bei weiterer Beobachtung der logs ist auch festzustellen, dass das "Problem" nicht bei jeder Verbindung auftaucht sondern einiges so wie es soll durchgeht.

Gruß

[tiermutter]

Moin nochmal,

habe nun etwas herumgetestet:
Die Meldungen kommen auch, wenn ich den ISP wechsle (Prio in der gateway group).
Auch wenn ich die gateway group aus dem policy based routing nehme und direkt über das gateway gehe erscheinen diese Meldungen.
Die fw optimization stand auf normal, wie auf meiner vorherigen appliance auch.
Nachdem ich nun auf conservative umgestellt habe kommen die Meldungen nicht mehr, natürlich auf Kosten einer um 100% gestiegenen CPU auslastung. Von diesem workaround würde ich gerne absehen und frage mich natürlich warum das erst jetzt mit der neuen appliance auftritt.
Kommando zurück, ist nun doch wieder aufgetreten...

Hat dazu noch jemand eine Idee?

Gruß