markus1505
Aug 09, 2017
view12519
view25
0
Goto Top

PfSense Firewallregeln: Internetfreigabe in verschiedenen VLANS

GermansolvedQuestionFirewallSecurity
Hallo zusammen,
ich habe mich durch die verschiedenen Anleitungen und Tutorials gearbeitet und jetzt läuft meine erste pfSense Installation auf dem Apu2C4 Board face-smile . An dieser Stelle noch einmal vielen Dank für die ganzen Tutorials.
Leider hänge ich jetzt an einer Stelle etwas und konnte im Forum nichts finden, dass mein Problem löst.

Ich habe verschiedene VLANS eingerichtet (VLAN 20 Privat, VLAN 30 IOT, …). Ich möchte von VLAN 20 auf alle anderen VLAN und das Internet zugreifen können. Dazu habe ich wie in den Tutorials beschrieben die Scheunentorregel erstellt. Dies funktioniert auch problemlos. Das VLAN 30 soll aber nur Zugriff auf das Internet bekommen. Leider klappt dies bei mir nicht. Ich habe dazu folgende Regel angelegt:

PASS Protocol: any, Source: VLAN30 net Port: any, Destination: WAN net, Port: any.

Leider bekomme ich so keine Internetverbindung am VLAN 30. Wenn ich hier testweise die Scheunentorregel anwende, funktioniert der Internetzugriff ohne Probleme.
Ich habe in einem anderen Beitrag gelesen, dass man die Scheunentorregel anwenden kann und die ungewünschten Funktionen dann mit weiteren DENY Regeln ausschließt. Allerdings finde ich die Möglichkeit nicht wirklich sinnvoll.

Habt ihr vielleicht eine Idee was ich falsch gemacht habe bzw. was ich ändern muss damit es funktioniert?

Vielen Dank für eure Hilfe.

Viele Grüße
Markus
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 345799

Url: https://administrator.de/contentid/345799

Printed on: April 25, 2024 at 00:04 o'clock

25 Comments
Latest comment
Goto Top
Member: chgorges
chgorges Aug 09, 2017 at 06:58:04 (UTC)
Goto Top
Zitat von @Markus1505:
Ich habe in einem anderen Beitrag gelesen, dass man die Scheunentorregel anwenden kann und die ungewünschten Funktionen dann mit weiteren > DENY Regeln ausschließt. Allerdings finde ich die Möglichkeit nicht wirklich sinnvoll.

Besser nicht.

Schick mal dein ganzes Regelwerk durch.

Dass Regeln von oben nach unten abgearbeitet werden, hast du beachtet? Heißt im Klartext, wenn du oben was verbietest, kannst du es weiter unten nicht mehr freigeben.
Member: ChriBo
ChriBo Aug 09, 2017 at 06:58:33 (UTC)
Goto Top
Hi,
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: WAN net, Port: any.
WAN net ist nicht "das Internet", sprich 0.0.0.0 ohne deine IPs der VLANs.
-
Was du zum Bleistift machen kannst:
1. Alias: meine_VLANs [hier setzt du alle IP ranges deiner VLANs rein]
2. deny Regel von VLAN30 nach Alias meine VLANs
3. die "Scheunentorregel, aber als Ziel: any
-
Gruß
CH
Member: aqui
aqui Aug 09, 2017 updated at 15:37:20 (UTC)
Goto Top
Die Regel ist komplett falsch !
Ist oben ja auch schon gesagt worden, denn scheinbar benutzt du die pfSense in einer Router Kaskade und dein WAN Port Koppelnetz was die Verbindung zum davorliegenden Router ist ist ja niemals das Internet.
Die Regel besagt das du vom VLAN 30 nur IP Ziele in diesem IP Netz erreicht und sonst gar nicht.
Wenn du also z.B. zu administrator.de im Internet surfen willst was die Ziel IP 82.149.225.21 hat dann siehst du schon dein Dilemma !!
Du solltest dir also noch etwas Know How in IP Adressierung anlesen face-wink

Richtig wäre die folgende Regel am VLAN 30 Interface:
  • BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 10 net, Port: any.
  • BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any.
  • PASS Protocol: any, Source: VLAN30 net Port: any, Destination: ANY (Internet), Port: any.
Das blockt dir den Zugriff in die anderen VLANs und lässt nur das Internet zu.

Das hat jetzt aber den Nachteil, das du von deinem VLAN 20 auch nicht mehr aufs VLAN 30 zugreifen kannst, was du ja nicht willst.
Hier hast du jetzt 2 Optionen:
1.)
Du lässt den Zugriff nur auf bestimmte Dienste und IPs im VLAN 20 zu. Das hat aber dann den gravierenden Nachteil das auch User aus VLAN 30 von sich aus diese Ziele in VLAN 20 erreichen.
Pfiffiger ist dann die Option...
2.)
Du änderst die Regeln etwas:
  • BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 10 net, Port: any.
  • PASS Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any. Advanced: Established Bit setzen.
  • PASS Protocol: any, Source: VLAN30 net Port: any, Destination: anyt, Port: any.
Die Option 2 lässt dann nur Antwort Pakete die ein Establised Bit im Layer 4 gesetzt haben durch.
D.h. User aus VLAN 30 kommen so nur ins Internet.
Sessions aber die vom VLAN 20 ins VLAN 30 initiiert werden und damit aus dem VLAN 30 beantwortet werden dürfen auch passieren.
Also immer vorher nachdenken und sich über die richtigen IP Adressen in den IP Paketen klar werden wie die aufgebaut sind und im Netz bewegen und dann das Regelwerk konfigurieren !!
Denk hier immer an die generellen Filter Regeln:
  • Filterregel wirken nur inbound
  • First Match wins: Sowie es eine Übereinstimmung in den Regelanweiungen gibt werden die folgenden Anweisungen NICHT mehr ausgeführt.
Eine intelligente Reihenfolge der Regeln zählt hier also bzw. ist essentiell wichtig für die Funktion !!
Member: Markus1505
Markus1505 Aug 10, 2017 at 05:36:39 (UTC)
Goto Top
Hallo zusammen,

erstmal vielen Dank für die Hilfe.

@chgorges Habe bisher noch keine weiteren Regeln angelegt. Wollte erstmal das die Basics funktionieren.

@aqui Nein ich benutze keine Router Kaskade. Am WAN Port der pfSense habe ich ein Zyxel VMG 1312 Modem (Empfehlung hier aus dem Forum) im Bridge Modus angeschlossen. Die Einwahl erfolgt, wie im Tutorial beschrieben per PPPOE-Einwahl direkt von der pfSense (1&1 DSL 16.000 Anschluss).

Ich werde mich am Wochenende nochmal hinsetzen und mich weiter einlesen und eure Empfehlungen umsetzen.

Ich werde berichten ob es geklappt hat.

Viele Grüße

Markus
Member: aqui
aqui Aug 10, 2017 updated at 08:58:52 (UTC)
Goto Top
Nein ich benutze keine Router Kaskade. Am WAN Port der pfSense habe ich ein Zyxel VMG 1312 Modem (Empfehlung hier aus dem Forum) im Bridge Modus angeschlossen.
Die Empfehlung hast du dann auch sehr gut und richtig umgesetzt. (War nicht ganz klar zu erkennen aus deiner o.a. Beschreibung)
Nur ändert das nichts an der Tatsache. "WAN net" bedeutet dann eben nur das Transfer IP Netz was vom Provider zu deiner Firewall geht.
Logischerweise ist in dem Provider Infrastruktur Netz natürlich kein IP Internet Server. Aber auch wenn, dann würdets du ja nur einzig die Server dort erreichen aber nichts anderes mehr in der großen, weiten Internet Welt.
Du erkennst vermutlich jetzt auch selber die Unsinnigkeit deiner Regel.
Ich werde berichten ob es geklappt hat.
Wir sind wie immer gespannt face-wink
Member: Markus1505
Markus1505 Aug 10, 2017 at 19:27:30 (UTC)
Goto Top
Hallo aqui,

ich habe mich eben doch schon hingesetzt und es versucht. Konnte soweit auch alles einstellen. Ich finde unter den Advanced Settings nur leider die Option Established Bit nicht. Konnte dazu auch nichts im Manual oder im Forum finden. Könntest du mir vielleicht nochmal einen Tipp geben, wo ich die Option genau finde bzw. wonach ich suchen muss.

Sorry für die vielen Rückfragen. Ist leider nicht ganz so einfach, wenn man neu in der Thematik ist.

Vielen Dank

Grüße
Markus
Member: aqui
aqui Aug 11, 2017 updated at 12:45:09 (UTC)
Goto Top
Sorry war vielleicht ein bischen salopp gesagt.
Genau ist es das gesetzet ACK (Acknowledge) Bit in the TCP Flags:
http://pfsensesetup.com/firewall-rules-in-pfsense-part-two/
Du darfst also nur Pakete mit gesetztem ACK Bit aus dem VLAN 30 in das VLAN 20 passieren lassen.
Member: Markus1505
Markus1505 Aug 16, 2017 at 05:54:35 (UTC)
Goto Top
Hallo zusammen, hallo aqui,

ich habe es am Wochenende mal versucht umzusetzen leider hat es nicht geklappt. Gestern habe ich die pfSense noch einmal neu aufgesetzt. Leider brachte das auch keinen Erfolg.

Ich habe folgendes eingestellt (VLAN30):

BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 10 net, Port: any.
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any. Advanced: ACK eingeschaltet.
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: any, Port: any.

Ich habe noch alles mögliche probiert, leider ebenfalls ohne Erfolg. Die Geräte aus VLAN 20/30 finden sich gegenseitig. Habe ich noch irgendetwas vergessen?

Die pfSense ist jetzt neu aufgesetzt mit den VLANS 10, 20 & 30. Alles ist Standard nur in VLAN 30 sind die oben beschrieben Regeln eingesetzt.

Viele Grüße

Markus
Member: aqui
aqui Aug 16, 2017 at 12:38:35 (UTC)
Goto Top
ich habe es am Wochenende mal versucht umzusetzen leider hat es nicht geklappt.
Schade... Dann hast du immer noch einen Konfig- bzw. Denkfehler in deinem Regelwerk.
Ein simpler Screenshot deiner Einstellungen hätte uns hier weitergeholfen und dir zu einem schnellen Erfolgserlebnis geführt.... Aber geschrieben gehts auch.
Leider weiss man nun auch nicht genau was du mit "leider hat es nicht geklappt..." jetzt genau meinst face-sad
Vermutlich nur den Zugriff von VLAN 20 auf Resourcen in VLAN 30, oder ??
VLAN 30 Internet Access sollte klappen, oder ??
Die Regel ist auch etwas falsch, weil das ACK Bit nur bei TCP basierten Protokollen setzbar ist. Dadurch das du UDP/TCP 53 nicht freigegeben hast funktioniert vermutlich auch kein DNS bei dir im VLAN 30.
So müsste eine sinnvollere Regel aussehen:
BLOCK Protocol: any, Source: VLAN30_net Port: any, Destination: VLAN 10_net, Port: any.
PASS Protocol: any, Source: VLAN30_net Port: any, Destination: any, Port: 53
PASS Protocol: TCP, Source: VLAN30_net Port: any, Destination: VLAN 20_net, Port: any. Advanced: ACK eingeschaltet.
PASS Protocol: any, Source: VLAN30_net Port: any, Destination: any, Port: any.
Das sollte dann eigentlich klappen.
Member: Markus1505
Markus1505 Aug 16, 2017 at 13:23:52 (UTC)
Goto Top
Hallo aqui,

kann gerne nochmal einen Screenshot machen , wenn ich Zuhause bin.

Ich habe nur im VLAN 30 die oben beschrieben Regeln eingefügt. In allen anderen VLANs sind keine Regeln hinterlegt.

Der Internet Access funktioniert. Ich bekomme allerdings von VLAN 30 ebenfalls eine Verbindung zu den Geräten in VLAN 20 und nicht nur von VLAN 20 auf 30. Die Geräte finden sich noch gegenseitig.

Ich werde heute Abend nochmal einen Screenshot ergänzen.

Vielen Dank und viele Grüße

Markus
Member: aqui
aqui Aug 17, 2017 at 10:42:34 (UTC)
Goto Top
In allen anderen VLANs sind keine Regeln hinterlegt.
Böses Faul !
Das ist dann fatal, denn bei einer Firewall gilt dann immer: "Alels was nicht explizit erlaubt ist, ist verboten !
Ohne ein Regelwerk an den anderen Internface wird dann NICHTS durchgelassen und jeder Traffic blockiert, ist ja klar.
Sollte man eigentlich wissen als Netzwerker !
An den Interfaces, physischen und VLAN Interfaces, die überall hin dürfen sollte also wenigstens ein:
PASS Protocol: any, Source: XYZ_net Port: any, Destination: any, Port: any.
stehen um Outbound Traffic zu erlauben !!
Ich bekomme allerdings von VLAN 30 ebenfalls eine Verbindung zu den Geräten in VLAN 20
Das zeigt dann aber das dein Regelwerk noch falsch ist am VLAN 30 Port !!
Member: Jensano
Jensano Mar 15, 2020 at 21:08:09 (UTC)
Goto Top
Zitat von @aqui:

BLOCK Protocol: any, Source: VLAN30_net Port: any, Destination: VLAN 10_net, Port: any.
PASS Protocol: any, Source: VLAN30_net Port: any, Destination: any, Port: 53
PASS Protocol: TCP, Source: VLAN30_net Port: any, Destination: VLAN 20_net, Port: any. Advanced: ACK eingeschaltet.
PASS Protocol: any, Source: VLAN30_net Port: any, Destination: any, Port: any. ##

Ich stehe gerade vor er selben Frage.
Habe ein VLAN für IOT Geräte und möchte denen nur Zugriff aufs Internet gewähren. Hatte es wie Markus1505 oben auch mit
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: WAN net, Port: any.
anfänglich versucht, da ich auch annahm am WAN Port hängt ja mein Modem und da das Internet drann. Naja ging halt nicht.

Ich dachte nur nach dem Motto "Es ist alles verboten bis es erlaubt wird" Ist die oben erwähnte Regel etwas kritisch. Man muss dabei erstmal den Verkehr zu anderen Interfaces verbieten/einschränken und dann ein "Pass Destination Any" setzen.

Was ist wenn man jetzt ein neues Interface dazubekommt. Dann darf dieses hier ja auf das neue Zugreifen, da es noch kein "Block" Eintrag in diesem hier bekommen hat und durch "Pass Destination Any" ja dann dahin darf. Da muss man also im Nachhinein daran denken das neu erstellte in diesem hier zu verbieten.

Gibt es da nicht ein Weg nur den Zugriff auf das Internet zu erlauben wenn am WAN Port ein Modem hängt und die PFSense sich mit PPPOE einwählt anstatt Dinge zu verbieten und den Rest (der ja dynamisch ist) zu erlauben?
Member: aqui
aqui Mar 16, 2020 updated at 08:42:15 (UTC)
Goto Top
Hatte es wie Markus1505 oben auch mit anfänglich versucht
Diese regel ist natürlich auch völliger Quatsch.
Leuchtet dir auch sicher selber ein wenn du sie und ihre Sinnhaftigkeit mal in Ruhe betrachtest !!
Diese Regel sagt ja das alles mit Absender Adressen aus dem VLAN30 und Zieladressen im WAN Netzwerk passieren darf.
Sie setzt also voraus das ALLE Internet Ziel IP Adressen sich vollständig im WAN Netzwerk Segment befinden.
Das das natürlich völliger Blödsinn und das das ganz Internet natürlich nicht im WAN IP Netz liegt versteht auch ein Dummie sofort !
Mit anderen Worten diese Regel ist vollkommener Unsinn und greift für gar nichts so das Internetzugriff weiter geblockt ist. Wenn überhaupt wäre:
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: any, Port: any.
richtig aber nicht dieser Unsinn ! (Logisch, denn die auf der Erde Milliarden verteilten Internet IP Netze willst du ganz sicher nicht einzeln in die Regel bringen, deshalb "any")
Dann darf dieses hier ja auf das neue Zugreifen
Nein ! Natürlich nicht !
Es darf lediglich auf das IP Netzwerk am WAN Port zugreifen ! Und nur da ! Kein Internet, keine anderen Firewall IP Segmente !
Ein BLOCK any any ist immer Default. Grundregel einer Firewall ! Es ist alles explizit verboten was nicht ausdrücklich erlaubt ist.
Eigentlich eine ganz einfache (und sinnvolle) Logik !
Gibt es da nicht ein Weg nur den Zugriff auf das Internet zu erlauben
Ja, natürlich ! Einfach mal etwas nachdenken !!!
  • Im Firewall Setting einen IP Netzwerk Alias mit dem Namen "RFC1918" erstellen der die folgenden IP Netze beinhaltet:
  • 10.0.0.0 /8, 172.16.0.0 /12 und 192.168.0.0 /16
  • Auf das Firewall Interface gehen und dort eine Regel erstellen: PASS IP Source: <interface_net> Destination: nicht RFC1918
  • Fertisch !
Das lässt dann sämtlichen Traffic durch der NICHT in private RFC1918 IP Netze geht die man gewöhnlich als lokes Interface an der Firewall hat.
alias
regel
Die Regel lässt Pingen des FW Interfaces zu und DNS Namensauflösung und blockiert alle Verbindungen in private RFC1918 IP Netze (man achte auf das Negations "!" in der Regel) und lässt Zugriff aufs Internet zu.
So einfach ist das mit etwas logischem Nachdenken. face-wink
Member: Jensano
Jensano Mar 16, 2020 at 22:50:10 (UTC)
Goto Top
Sie setzt also voraus das ALLE Internet Ziel IP Adressen sich vollständig im WAN Netzwerk Segment befinden.
Das ist ein sehr hilfreicher Satz gewesen und mein Denken zu korrigieren. Da habe ich auch noch was im Netz gefunden was ich auch sehr hilfreich fand.
Zitat von https://docs.netgate.com/pfsense/en/latest/firewall/firewall-rule-basics ...
WAN net - Please note this is not the internet, this is just the network wan is connected to, just like lan, or opt net aliases above. If your ISP puts you on a x.x.x/21 network, or a /29 or a /24 that is the network this refers too.. Not the whole internet.

Mit anderen Worten diese Regel ist vollkommener Unsinn und greift für gar nichts so das Internetzugriff weiter geblockt ist.
Nur Formell zum Verständniss: Es ist eine Regel und die lässt schon eine kleine Kommunikation auf das Netz da draußen zu? Siehe Zitat von Netgate. Nur gibt es da wahrscheinlich nicht soviel zu sehen.

Es darf lediglich auf das IP Netzwerk am WAN Port zugreifen ! Und nur da ! Kein Internet, keine anderen Firewall IP Segmente !
Wenn ich es richtig verstanden habe wird doch bei den Regeln von oben nach unten gearbeitet. Bedeutet doch bei der obigen Folgendes:

Die regeln werden von oben nach unten abgearbeitet
  1. BLOCK Protocol: any, Source: VLAN30_net Port: any, Destination: VLAN 10_net, Port: any.
  2. PASS Protocol: any, Source: VLAN30_net Port: any, Destination: any, Port: 53
  3. PASS Protocol: TCP, Source: VLAN30_net Port: any, Destination: VLAN 20_net, Port: any. Advanced: ACK eingeschaltet.
  4. PASS Protocol: any, Source: VLAN30_net Port: any, Destination: any, Port: any.

So nun mein Kauderwelsch im Kopf. Sorry durch das Schreiben meines Quatsches hoffe ich mehr Erkenntnisse zu erlangen.
  1. Es wird jeglicher Zugriff auf das VLAN10 geblockt
  2. Das VLAN30 darf hat auf jedes Netzsegment Zugriff über den Port 53
  3. Das VLAN30 hat über TCP Zugriff VLAN20
  4. VLAN30 hat überall Zugriff über jedes Protokoll über jeden Port (Scheunentor)

Die Nummer 4 verstehe ich nicht. Oder besser ich verstehe nicht was dann 2 und 3 für einen Sinn machen sollen. 1 Blockt erstmal den Zugriff auf VLAN10. Das kann dann auch ein nachfolgendes Scheunentor nicht ändern. Aber mit 2 und 3 erlaube ich ein bisschen wonach ich mit 4 alles erlaube. Die Reeln von 2 und 3 sind doch in 4 inkludiert.???

Weiter oben hast du auch eine Regel geschrieben wo ich ein Anstoß brauche
Richtig wäre die folgende Regel am VLAN 30 Interface:

BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 10 net, Port: any.
BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any.
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: ANY (Internet), Port: any.

Das blockt dir den Zugriff in die anderen VLANs und lässt nur das Internet zu.
Das hat jetzt aber den Nachteil, das du von deinem VLAN 20 auch nicht mehr aufs VLAN 30 zugreifen kannst

So nun mein Hirnsalat
Warum kann ich bei den Regeln nicht mehr von VLAN 20 auf VLAN 30 zugreifen? Hier sind doch erstmal nur Regeln für Source: VLAN30 gelistet. Da kann man doch immer noch beim VLAN 20 den Zugriff auf VLAN 30 erlauben. Das können diese Regeln hier bei VLAN 30 doch gar nicht verhindern.
Member: aqui
aqui Mar 17, 2020 at 08:08:53 (UTC)
Goto Top
Das ist ein sehr hilfreicher Satz gewesen und mein Denken zu korrigieren.
Diesen Irrtum begehen leider viele weil sie nicht in Ruhe mal nachdenken....
Sie denken das das Internet der WAN Port ist weil die Pakete da raus gehen. Das ist natürlich dann laienhaft gedacht, denn für die Regeln zählen ja immer die Ziel IP Adressen. Und diese IP Netze sind ja weltweit verteilt und eben NICHT das IP Netz am WAN Port.
wird doch bei den Regeln von oben nach unten gearbeitet.
Das ist richtig !
Es gelten die folgenden Grundregeln:
  • Filter nur inbound
  • Regeln werden der Reihe nach abgearbeitet
  • Es gilt "Forst match wins !" Sprich: Gibt es einen positiven Hit im Regelwerk werden die folgenden Regeln nicht mehr abgearbeitet.
Wenn man sich daran hält ist es ganz einfach und logisch ! face-wink
Zu deinem Regelwerk...
Es wird jeglicher Zugriff auf das VLAN10 geblockt
Jein ! Richtig ist: Es wird jeglicher Zugriff von VLAN 30 auf das VLAN10 geblockt.
Das VLAN30 darf hat auf jedes Netzsegment Zugriff über den Port 53
Richtig: Port UDP/TCP 53 ist DNS. Sprich DNS Anfragen aus dem VLAN 30 dürfen überall hin.
Das VLAN30 hat über TCP Zugriff VLAN20
Jein ! Ist generell richtig, gilt aber rein nur für Verbindungen die aus dem VLAN 20 aufgebaut (initiiert) werden (ACK Bit). Verbindungen die aus dem VLAN 30 ins VLAN 20 gehen werden weiterhin geblockt !
Regel 4.) Ist dann natürlich dann, sorry, Schwachsinn.
Logisch, denn sie konterkariert damit die Regeln 2. und 3. und macht das Regelwerk damit insgesamt unlogisch. Das hast du auch genau richtig erkannt das die Unsinn. Wozu verbietet man etwas wenn man dann doch ein Scheunentor aufmacht.
Warum kann ich bei den Regeln nicht mehr von VLAN 20 auf VLAN 30 zugreifen?
Auch hier gilt es wieder nachdenken.... face-wink
Du greifst von einem Host aus VLAN 20 auf einen VLAN 30 Host zu. Das IP Paket kommt auch noch am VLAN 30 Host an (sofern VLAN 20 keine Regeln hat !) und dann antwortet der VLAN 30 Host dem VLAN 20 Host und kabooom....
BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any.
schlägt zu und killt das Antwortpaket !
Du verstehst ?!?
Also niemals die Rückroute unterschlagen, was du hier in deiner Denke leider gemacht hast !!! face-wink
Member: Jensano
Jensano Mar 19, 2020 updated at 07:13:02 (UTC)
Goto Top
Jein ! Ist generell richtig, gilt aber rein nur für Verbindungen die aus dem VLAN 20 aufgebaut (initiiert) werden (ACK Bit). Verbindungen die aus dem VLAN 30 ins VLAN 20 gehen werden weiterhin geblockt !
Das ACK Bit ist das Bestätigungsbit eines "Servers" womit er auf eine Anfrage antwortet und damit sagt "Jawoll ich stimme der Verbindung zu" Wikipedia schreibt dazu das dabei jedoch auch ein SYN mit gesendet wird.
2020-03-19 06_58_54
Von 300px-Tcp-handshake.png: ???derivative work: Snubcube (talk) - 300px-Tcp-handshake.png (Imagen cogida de la wikipedia italiana.), CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=11680600

Fehlt dann hierbei nicht das TCP Flag SYN anstatt nur ACK? Was dann jedoch wieder bedeuten würde das VLAN30 ja dann auch eine Anfrage in das VLAN 20 senden kann, was man aber ja nicht will. Leider finde ich keine genaueren Erklärungen über die Funktion ACK / SYN Bit in PFSense und was da PFSense unter der Haube alles macht.

Du greifst von einem Host aus VLAN 20 auf einen VLAN 30 Host zu. Das IP Paket kommt auch noch am VLAN 30 Host an (sofern VLAN 20 keine Regeln hat !) und dann antwortet der VLAN 30 Host dem VLAN 20 Host und kabooom....
BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any.
schlägt zu und killt das Antwortpaket !
Also niemals die Rückroute unterschlagen

An die Rückroute hatte ich gedacht. Nur hatte ich hier folgendes gelernt.

  1. Generell ist per Default "Alles" geblockt (Wobei ich hier jetzt über "Alles" verwundert bin)
  2. Ich hatte gelesen das z.B. Verbindungen vom Internet nicht auf eigene Faust in mein LAN zugreifen können. Sinnvoll. Aber meine LAN Verbindung kann auf das Internet zugreifen. Hierfür muss das Internet mir jedoch auch antworten dürfen. Für diese Antworten sind die Ports dann offen sofern ICH die Anfrage gesendet habe. Somit ist doch in dem Fall nicht "Alles" per Default geblockt, da es ja erstmal keine spezielle Regel am WAN gibt die Antworten aus dem Internet passieren lässt.
  3. Wenn ich einem Netzwerk keine Regel gebe müsste ja alles, also auch die Antworten geblockt sein. Ansonsten würde ja auch eine Regel keinen Sinn machen, in der man explizit die Antworten erlaubt, wie bei PASS Protocol: TCP, Source: VLAN30_net Port: any, Destination: VLAN 20_net, Port: any. Advanced: ACK eingeschaltet. Ich kann aber ohne Probleme ein "Netzwerk 1" von "Netzwerk 2" anpingen und "Netzwerk 1" antwortet auch auch wenn bei "Netzwerk 1" keine Erlaubniss für ein Antwort Bit eingerichtet ist. Das würde sich doch auch irgendwie mit dem Zugriff auf das Internet über WAN widersprechen, da dieses mir doch auch Antwortet ohne das dort eine spezielle Regel für die Antworten erstellt ist.

BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any.
schlägt zu und killt das Antwortpaket !
Mit "Standard ist "Alles" geblockt" müsste das Antwortpaket doch auch ohne die Regel geblockt werden. Außer "Alles" ist nicht gleich "ALLES" Aber die dynamische Firewall lässt ja bekanntermaßen Antworten auf eine Anfrage automatisch durch.
Member: aqui
aqui Mar 19, 2020 at 08:22:12 (UTC)
Goto Top
Fehlt dann hierbei nicht das TCP Flag SYN anstatt nur ACK?
Theoretisch ja. Das Advanced Ruleset lässt das ja zu. Es wäre aber fatal wenn du das machst und beides abfragst um Traffic passieren zu lassen, denn dann kommt lediglich das Session Bestätigungs Paket durch was Syn und ACK gesetzt hat aber nicht die normalen Antwortpakete eine etablierten Session die rein nur ACK gesetzt haben. Sprich das blockt dann auch sämtlichen Traffic.
Etwas Nachdenken über den Paket Flow hilft hier also... face-wink
Wobei ich hier jetzt über "Alles" verwundert bin
Warum ?? Alles ist eben nun mal "Alles". DENY any any !
Aber meine LAN Verbindung kann auf das Internet zugreifen.
Das liegt daran weil der FW schon einen any any Regel nur für den LAN Port bei der Installation mitgegeben wurde. Das ist ein Zugeständnis der Macher an Anfänger, damit die nicht frustriert aufgeben weill sie die Grundregeln einer Firewall nicht kennen. Normal ohne das wäre auch das default LAN Interface geblockt. Bei professionellen Firewalls ist das übrigens immer so ! Dort geht gar nix.
2. Ist richtig da es eine SPI Firewall ist.
Member: Jensano
Jensano Mar 19, 2020 updated at 14:13:18 (UTC)
Goto Top
dann kommt lediglich das Session Bestätigungs Paket durch was Syn und ACK gesetzt hat aber nicht die normalen Antwortpakete eine etablierten Session die rein nur ACK gesetzt haben. Sprich das blockt dann auch sämtlichen Traffic.
Das geht leider aus den Wikipedia Beschreibungen nicht hervor. Setz man also in einer Regel das ACK & SYN gilt die Regel nicht als "Entweder oder" sondern nur als UND.
Aus dem Wikipedia habe ich nur entnehmen können:
  1. Anforder sendet SYN
  2. Angeforderter sendet SYN-ACK zurück (Hier brauch ich jetzt Hilfe. Sendet der Server dann ein ACK Bit oder ein SYN und ein ACK Bit? Beim zweiten Fall würde ich die Regel nicht verstehen, da du ja nur ACK über die Regel freigegeben hast und dann die Verbindung eigentlich nicht zu Stande kommen dürfte. Anderen Quellen (LINK) habe ich bereits entnommen das ein ACK und SYN gesendet wird. 😕)
  3. Anforderer sendet Daten mit ACK Bit
  4. Was ist mit den Daten die dann vom Server zurück zum Anforderer gehen? Wenn ich z.B. Daten vom Server zu mir kopieren möchte. Werden diese Daten dann immer nur mit einem reinen ACK Bit gesendet? Wie gesagt, du schreibst das zwar aber der Wikipedia habe ich das nicht entnehmen können.

Noch einmal ausgeholt
In der PFSense ist am WAN Interface per Default keine PASS Regel eingestellt. Dennoch kommen Antworten vom Internet durch bis zu meinen LAN Teilnehmern. Also stelle ich fest das die SPI Firewall ja genau das ermöglichen soll.
Im gleichen Zuge definierst du aber eine Regel "PASS Protocol: TCP, Source: VLAN30_net Port: any, Destination: VLAN 20_net, Port: any. Advanced: ACK eingeschaltet" welche jetzt Antworten aus dem VLAN30 in das VLAN20 ermöglichen soll. Das geht doch bereits ohne Regel oder nicht? Antworten tun doch Netzwerke auch ohne Regel. Wenn ich von VLAN20 in das VLAN30 zugreifen möchte dann muss ich doch nur eine Regel am VLAN20 erstellen die den Zugriff auf VLAN30 ermöglicht. Ich muss dann doch nicht am VLAN30 eine regel definieren das VLAN30 dem VLAN20 antworten darf. Auch am WAN ist doch keine Regel für die Rückantwort definiert.
Member: aqui
aqui Mar 19, 2020 at 16:13:39 (UTC)
Goto Top
da du ja nur ACK über die Regel freigegeben hast und dann die Verbindung eigentlich nicht zu Stande kommen dürfte.
Warum nicht ?!
Die Regel prüft ja lediglich nur auf das gesetzte ACK und das ACK ist ja gesetzt. OB das SYN gesetzt ist oder nicht ist der Regel egal. Die Praxis zeigt ja auch das es fehlerlos klappt. face-wink
Was ist mit den Daten die dann vom Server zurück zum Anforderer gehen?
Wireshark ist dein bester Freund !! Und das sogar noch ganz umsonst. face-wink
Dennoch kommen Antworten vom Internet durch bis zu meinen LAN Teilnehmern
Weil sie Stateful ist und Packete mit gesetztem ACK passieren lässt.
Das geht doch bereits ohne Regel oder nicht?
Ich meine nicht, aber teste ich jetzt auf der Stelle mal aus...
Member: Jensano
Jensano Mar 19, 2020 at 20:46:01 (UTC)
Goto Top
Ich habe es jetzt mal getestet. Nicht mit Wireshark, das muss ich mir jetzt nicht auch noch antun, aber mit einem normalen Zugriff auf einen Switch.

Ich sitze hier im 192.168.1.0 Subnet mit IP 192.168.1.200
Firewall Rule
2020-03-19 20_46_08
Hier darf man somit überall hin.

Im 192.168.3.0 Subnet sitzt ein Cisco Switch mit IP 192.168.3.200
Firewall Rule
2020-03-19 20_46_51
Die hier dürfen somit nirgens hin. Je doch nur wenn es nach deren Willen geht. Würde es auch Standardmäßig ohne Einträge nicht dürfen, habe aber zusätzlich nochmal ein BLOCK ANY probiert.

Ergebnis ist das ich von 192.168.1.200 auf den Switch mit 192.168.3.200 komme. Hatte ich eigentlich auch erwartet, da wie bei WAN auch keine Regel für die Rückantwort erforderlich ist. Aber ich bin noch weit am Anfang und lerne fleißig und kann mich mächtig irren.

Resumee
PASS Protocol: TCP, Source: VLAN30_net Port: any, Destination: VLAN 20_net, Port: any. Advanced: ACK eingeschaltet
macht für mich damit keinen Sinn an dieser Stelle, da nach Beschreibung eines TCP Handshakes der Empfänger auch ein SYN Bit senden können muss, dieses hierbei jedoch nicht definiert ist und die Regel nur nicht zu Problemen führt weil die Antwort auch ohne Regel zu Stande kommt.
...Mich mal weit aus dem Fenster gelehnt 🤠
Member: aqui
aqui Mar 20, 2020 updated at 14:16:24 (UTC)
Goto Top
So, ein Testaufbau zeigt das von dir beschriebene Filter Verhalten was bei einer SPI Firewall aber auch normal ist.
Sehr verwunderlich ist aber das ICMP Verhalten....

Testaufbau:
fwtest

LAN darf alles:
(ICMP ausgegraut, dazu später mehr)
filter2

OPT 1:
  • Darf DNS auflösen nur über die lokale IP der FW
  • Blockt global ALLES was in alle Privaten IP Netze geht
  • Blockt dediziert alle ICMP Pakte von LAN nach OPT1. (Diese Regel ist eigentlich völlig überflüssig, denn sie ist in der davor inkludiert. War ein Test)
filter3

Ergebnis:
  • TCP 80 (HTTP) Traffic vom LAN Client auf einen Webserver am OPT1 Client funktioniert trotz Filterregel an OPT1, was das SPI konforme Verhalten von Paketen verifiziert die mit gesetztem ACK Bit trotz Regel passieren können. Works as designed und bestätigt damit auch dein Ergebnis von oben.
  • Interessant ist aber ein Ping (ICMP) vom LAN aufs OPT1 !
  • Dieser funktioniert wider Erwarten auch, was er aber nach striker Regel Auslegung eigentlich NICHT dürfte. Die RFC1918 Regel blockiert ALLE Protokolle natürlich auch ICMP in jegliches privates IP Netz ! Komisch ?!
  • Gut, Vermutung war das die FW ggf. intelligenterweise auf ein erkanntes ICMP Echo den dazu korrespondierenden ICMP Echo Reply passieren lässt. Sehr ungewöhnlich aber denkbar....
  • Daher nochmal die (eigentlich überflüssige) explizite ICMP Blocking Regel die noch einmal explizit jeglichen ICMP Verkehr ind LAN Netz unterbinden soll !
  • Ergebnis: Geht auch nicht, wie erwartet ! ICMP Echo Reply (Pings) können trotz doppelter BLOCK Regel passieren ! Auch das Filtern ausschliesslich nach ICMP Echo Replys an OPT1 blockierte die Ping Antworten nicht was unverständlich ist !
  • Ergebnis 2: ICMP kann man bei der pfSense scheinbar explizit nur inbound am Interface filtern ! Ist die oben ausgegraute ICMP Block Regel am LAN Interface aktiv gehen dann erwartungsgemäß keine Pings mehr durch.

Das ICMP Verhalten ist schon recht ungewöhnlich aber muss man wohl so hinnehmen und entsprechend auf dem Radar haben wenn man Pings von Clients in Zielnetze oder die FW direkt unterbinden will.

Zur Kontrolle hab ich zusätzlich einmal über das Diagnostics Menü direkt auf dem OPT1 Port im Promiscous Mode gesniffert und der Trace zeigt dann das die Firewall trotz doppelter BLOCK Regel den ICMP Traffic passieren lässt:
filter1
Member: Jensano
Jensano Mar 20, 2020 at 18:01:18 (UTC)
Goto Top
aqui du bringst langsam mein mühsam aufgebautes Verständniss ins wanken 😉
Ich glaube ich habe dich mit meinen Fragen schon ganz durcheinander gebracht.

Ich zittiere mal die Rule Methodology
... traffic initiated from the LAN is filtered using the LAN interface rules. Traffic initiated from the Internet is filtered with the WAN interface rules. Because all rules in pfSense are stateful by default, a state table entry is created when traffic matches an allow rule. All reply traffic is automatically permitted by this state table entry.

Interessant ist aber ein Ping (ICMP) vom LAN aufs OPT1 !
Dieser funktioniert wider Erwarten auch, was er aber nach striker Regel Auslegung eigentlich NICHT dürfte. Die RFC1918 Regel blockiert ALLE Protokolle natürlich auch ICMP in jegliches privates IP Netz ! Komisch ?!
Warum ist das Komisch? Das ist doch ein ANTWORT PAKET auf eine ANFRAGE die ALLOWED wurde auf Grund einer Regel am LAN
"ALLOW LAN ANY".
Es werden mit deinen DENNY Regeln beim OPT1 doch nur Verbindungen geblockt die von OPT1 initiiert wurden. Dem OPT1 wird damit aber nicht verboten auf eine Anfrage vom LAN zu ANTWORTEN.
Das ist doch das Prinzip von stateful.

Das ICMP Verhalten ist schon recht ungewöhnlich aber muss man wohl so hinnehmen und entsprechend auf dem Radar haben wenn man Pings von Clients in Zielnetze oder die FW direkt unterbinden will.
Sollen die Clients die am OPT1 hängen keinen anpingen dürfen macht man eine DENNY ICMP am OPT1. Das bedeutet aber nicht das diese auf einen Ping aus einem anderen Netz nicht antworten dürfen.

Los jetzt sag mal das du mich hier die ganze Zeit auf die Schippe nimmst.
Member: aqui
aqui Mar 20, 2020 updated at 19:06:40 (UTC)
Goto Top
Ich glaube ich habe dich mit meinen Fragen schon ganz durcheinander gebracht.
Etwas... face-wink
Ich wollte das aber am lebenden Objekt mal selber sehen bevor man hier was behauptet face-wink !
Das ist doch ein ANTWORT PAKET auf eine ANFRAGE die ALLOWED wurde auf Grund einer Regel am LAN "ALLOW LAN ANY".
Und hier haben wir dich mal wieder erwischt indem du mal wieder nicht nachdenkst !
Ja sicher, was den LAN Port anbetrifft hast du zweifelsohne Recht. Es geht hier aber um den OPT1 Port also da wo die Antwort herkommt !
Bedenke zudem das ICMP nicht stateful ist wie TCP ! ICMP ist ein eigenes IP Protokoll !
Der Client im LAN triggert mit seinem Echo Request am Empfänger in OPT1 ein Echo Reply.
Die Regel an OPT1 verbietet aber explizit die Reply Antwort ins LAN weil dort als Protokoll ANY steht in alle RFC1918 Netze. Erwartungsgemäß sollte also der Echo Reply dann an diesem Filter scheitern.
Auch danach kommt nochmal ein expliziter Block der nur dediziert Echo Reply ins LAN Segment filtert. Auch das sollte die Antwort blocken. Also quasi zum Gürtel noch den Hosenträger !
Normal sollte die "Protokoll any" Regel aber allein schon reichen.
IPv6 kann hier auch keinen Streich spielen denn das ist generell gar nicht erlaubt.
Ergebnis:
Trotz dieses massiven Blocking Bollwerks kommen ICMPs trotzdem durch was irgendwie etwas komisch ist und nicht sein sollte. Oder ich mache hier auch einen Denkfehler...kann natürlich auch sein. face-big-smile
Und ja... ich habe den States Cache vor dem Test natürlich gelöscht !!!

Wiederholt man das ganze an einem Cisco Layer 3 Switch mit entsprechend analogen ICMP Access Listen verhält der sich exakt so wie erwartet. Die pfSense behandelt also ICMP Traffic irgendwie anders.
Um es nochmal zu wiederholen: Es geht hier rein nur um ICMP !! Mit TCP oder UDP verhält sich die FW absolut richtig.
Das ist doch das Prinzip von stateful.
Nein ICMP ist NICHT stateful sondern ein stateless Protokoll wie UDP.
Sollen die Clients die am OPT1 hängen keinen anpingen dürfen macht man eine DENNY ICMP am OPT1
Das ist richtig, das klappt auch. Es sollte aber auch funktionieren wenn man am anderen Ende filtert...stateless, siehe oben ! Der Cisco Router beweist ja das es logisch richtig geht.
Member: Jensano
Jensano Mar 21, 2020 at 07:48:09 (UTC)
Goto Top
Es geht hier aber um den OPT1 Port also da wo die Antwort herkommt !
Das ist mir schon klar. Ist aber mit WAN genauso. Da geht meine Anfrage auch im LAN ein und die Antwort geht am WAN ein. Und da kommen auch alle Antworten trotz BLOCK ANY durch. Auch Pings (ICMP) an z.B. google.

Da ich im ersten Jahr (und den darauffolgenden) im Fach Informatik gefehlt hatte 😉 muss ich mich nun durchlesen. Ich wusste nicht das die Funktion das etwas statefull abläuft vom Protokoll abhängig ist. Ich dachte das ist ein Grundsatz diese Anfragen und Antworten darauf zu steuern und so eingehenden Verkehr (sofern ich diesen angefordert hatte) zu erlauben.
Das kann ich mir auch nur mühsam erlesen wie z.B. auf Rule Methodology
Und da steht Because all rules in pfSense are stateful by default...
Da steht nichts von Unterschieden zu verschiedenen Protokollen. Das muss ich erst noch lernen.

In PFSense hat man für Protokolle die standardmäßig nicht statefull sind (wie auch immer das protokollspezifisch gemacht wird) eine "Krücke" (kann man das sagen?) über eine Zeitsteuerung eingebaut. Das betrifft auch ICMP.
Siehe Antwort vom Developer
Member: aqui
aqui Mar 21, 2020 at 07:59:28 (UTC)
Goto Top
ch wusste nicht das die Funktion das etwas statefull abläuft vom Protokoll abhängig ist.
Hättest du dir mit einfachem Nachdenken aber selber herleiten können face-wink
Wie sollte man auch ein Protokoll was NICHT stateful ist dann stateful behandeln ?! face-wink
Da steht nichts von Unterschieden zu verschiedenen Protokollen.
Leider ! Das ist so wie beim Frosch mit seinen Locken ! Dem nützt ein Kamm dann eher weniger ! face-wink
über eine Zeitsteuerung eingebaut.
Nein, das ist Unsinn mit einer Zeitsteuerung.
Das ist der State Cache. Die FW hält diese States eine zeitlang im Cache. Das gilt auch für non stateful Sessions.
Die sollte man deshalb beim Testen von Rules natürlich immer vorher löschen.
Menü Diagnostics => States => Reset States
GermansolvedQuestionFirewallSecurity
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 5 CommentsjstrickerWireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments