(Gelöst) Default deny rule IPv4 (1000000103)

Bordi

Hallo

Ich hab in den vergangen Tagen vermehrt in den logs verbracht, und neben vielem anderem dies entdeckt.


BLOCK  Apr 7 11:33:47	LAN	Default deny rule IPv4 (1000000103)	  ps4.lan.ip:60174	  34.210.105.103:443	TCP:FA
BLOCK  Apr 7 11:33:46	LAN	Default deny rule IPv4 (1000000103)	  ps4.lan.ip:60147	  34.208.79.59:443	TCP:FPA

Ich habe weit früher für die PS eine statische Outbound NAT Regel angelegt.


WAN  ps4lanip/31  *  *  *  WAN adress  *  √  PS4 AON

```_> Die 31 wegen der um 1 höheren wlan-ip._

Doch so wie ich den logeintrag verstehe ist es ja der PS4 der HTTPS-Zugriff auf einen externe Server verweigert worden. ??? Nur wie kann das sein? Ich habe in den Firewall regeln keinen Eintrag der das verbieten würde.

Grimson

@Bordi:

Hallo

Ich hab in den vergangen Tagen vermehrt in den logs verbracht, und neben vielem anderem dies entdeckt.
Apr 7 11:33:47	LAN	Default deny rule IPv4 (1000000103)	  ps4lanip:60174	  34.210.105.103:443	TCP:FA
Apr 7 11:33:46	LAN	Default deny rule IPv4 (1000000103)	  ps4lanip:60147	  34.208.79.59:443	TCP:FPA
WANPS4 AON

Und, was willst du uns damit sagen?

Edit: https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection RTFM ist immer wichtig.

Bordi

Endschuldige das war keine Absicht. Ich hatte wohl irgendwie gespeichert bevor ich fertig war. Ist jetzt behoben.

Edit: https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection RTFM ist immer wichtig.

Ist ja gut und recht, aber der EasyRoule Eintrag vermochte das es auch nicht beheben.

Grimson

@Bordi:

Ist ja gut und recht, aber der EasyRoule Eintrag vermochte das es auch nicht beheben.

Bitte die obige Seite so lange lesen bis du den Inhalt komplett verstanden hast.

Bordi

Es wäre sehr nett wen du davon ausgehen könntest das RTFM & RBA stets voran gehen, und ich nur Frage wenn ich es doch nicht kapiert habe. Selbsverständlich meine ich dass nicht fordernd, und wenn du es selbst nicht besser erklären kannst als auf diverse fremdsprachige Quellen zu verweisen, erübrigt sich das wohl auch.

Grüsse ;)

Lösung: Schlussendlich hat es gereicht die state table settings etwas konservativer einzustellen. https://doc.pfsense.org/index.php/Advanced_Setup#Firewall.2FNAT

JeGr

Was Grimson da recht hart ausgedrückt hat ist, dass du "eigentlich" gar nichts hättest machen müssen. FA und FPA State Pakete bei 443/SSL Verbindungen sind gern mal im Log. Die KANNST du nicht wegblocken, außer du blockst gezielt diese States weg, was keinen Sinn macht (im Normalfall). Die Easyrule greift nicht, weil alle Regeln normalerweise NUR Syn Pakete matchen (Verbindungsaufbau). Hier sinds aber keine S sondern FA (Fin Ack) oder FPA (Push Fin Ack) Pakete. Also welche, die eh schon sagen, dass die Verbindung geschlossen werden soll(te). Daher völlig hinfällig. Die Pakete tauchen nur dann auf, wenn die Verbindung gelahmt hat und der Paketfilter vorher schon den State weggeworfen hat (meist weil bereits ein Reset oder Fin kam). Wenn dann noch eine verspätete Antwort vom Server kommt, dass man zustimmt die Verbindung zu schließen, dann gibts eben keine Zuordnung mehr und man wirft das Paket als unwichtig weg.

That's it und das steht eben so in dem Dokument drin: "This happens because on occasion a packet will be lost, and the retransmits will be blocked because the firewall has already closed the connection."

Zusätzlich kann das bei asymmetrischem Routing oder MultiWAN manchmal auftreten, das würde aber auf schlechte oder problematische Routen/Netwerksetups hinweisen.

Gruß