Verzweifle an einer Regel: Client zu Internet

[Patrick M. Hausen]

Wenn outbound auf automatic steht, dann wird ausgehend zum Internet für alle lokal angeschlossenen Netze geNATed. Meist ist das das, was man will.

Hat man noch eine interne Leitung zu einem anderen Standort oder aus anderen Gründen (Layer 3 Switch o.ä.) interne Routen, werden diese statisch gerouteten Netze nicht automatisch geNATed. Dann muss man hybrid oder manual verwenden.

Normalerweise brauchst du daran nichts zu ändern.

Also wenn du vom LAN aus ein "ping AP" absetzt, dann solltest du doch auf dem LAN der OPNsense die Pakete herein kommen sehen? Und dann guckst du, ob sie auch auf wLAN raus gehen. Und ob Antworten zum wLAN rein kommen? Und ob diese zum LAN wieder raus gehen?

Schön Stück für Stück.

[bread]

Danke fürs Dranbleiben  :D

Ich glaub, ich bin mächtig verwähnt von ipfire.
Irgendwie war da wirklich ALLES anders.

Ich habe in der Zwischenzeit was Seltsames festgestellt. Ich glaube irgendwas stimmt mit der Konfiguration der Interfaces nicht. Ich kann von LAN den 10er und zwei 192er Interfaces pingen (also das NIC selber quasi) aber nicht den 172er Bereich.

An sich habe ich sie alle gleich eingerichtet:
enable
prevent removal
static IPv4
none IPv6
172.16.63.1/24 (z.B. WLAN)

Wahrscheinlich müsste ich beim 10er /8 beim 172er /12 und beim 192er /16 machen, ist es relevant?
Es ist bei allen /24 als Standard gelassen und meines Wissens nach passt das auch. Suffixe ist allerdings so ne Sache... die ich nicht ganz checke.

Was mich noch sehr wundert.
Wenn ich für den AP mal testweise einen anderen Port nehme, dann bekommt der AP nur an dem WLAN-Port eine IP per DHCP, andere vergeben nichts. Alle Ports sind statisch eingerichtet. Von wo aus wird per DHCP auf dem WLAN-Port die IP an den angeschlossenen AP vergeben? Und das ist genau der Port, der nicht anpingbar ist.

Vielleicht sind es jetzt DIE Infos, die den Fehler aufzeigen  :o

/Edit:
Ok, ich Depp hab vergessen, dass ich extra bei WLAN DHCP-Bereich einegrichtet habe (macht ja Sinn). Es gibt ja dafür einen extra Einstellungsbereich.

Und BINGO mache ich bei einem anderen Port DHCP an und verbinden den AP, dann kann ich pingen UND erreiche das Ding endlich über WEB GUI. Also stimmt irgendwas mit den Einstellungen des WLAN-Ports nicht.

Was ich allerdings NICHT verstehe, warum ich den AP an einem anderen Port ohne eine FW-Regel erreichen kann!
Es ist die Floating-Regel (siehe oben im Bild): any --> ! private networks. Diese Regel erlaubt wohl nicht nur den Zugang zum Internet, sondern bricht alle verbote zwischen den Interfaces.

OK, ist habe @bimbar nicht verstanden:

Ich mache mir ein Alias "netgroup_internet_inverted", wo alles drin ist, was nicht internet ist (interne netze bei mir), dann eine Floating Regel accessgroup_internet -> ! netgroup_internet_inverted allow. In accessgroup internet ist alles drin, was ins internet können soll.

Jetzt habe ich meine Floating_Regel angepasst:
Private_NetworkDevices (alle, die ins Internet dürfen) --> ! Private_Networks (interne Netze)

Jetzt komm ich ins Internet, erreiche aber die anderen Interfaces nicht. So, wie es sein soll.
Verstehen tue ich diese Regel allerdings nicht. Ah... vielleicht dreht das ! die Logik so um, dass es heißt "Überall, aber NICHT in die Private_Networks"??

Jetzt habe ich die besagte Regel fürs andere Interface erstellt (LAN net --> Anderes Netz net) und ich kann den AP per Web GUI erreichen!

Es bleibt das Problem mit dem seltsamen WLAN Port  ;D Da stimmt etwas mit dem Port nicht.

Edit2:
Mittlerweile (wie du im englischen Post wahrscheinlich gesehen hast) habe ich die Einstellungen auf einen anderen Port übertragen und der Fehler ist mitgewandert. Also liegts nicht am Port, sondern an den Einstellungen dafür.

[Patrick M. Hausen]

Danke fürs Dranbleiben  :D

Oh ... viel aufzudröseln :)

Ich glaub, ich bin mächtig verwähnt von ipfire.
Irgendwie war da wirklich ALLES anders.

Was ist denn der Grund zum Wechseln? Ich meine, wenn es funktioniert und du damit klar kamst?

Wahrscheinlich müsste ich beim 10er /8 beim 172er /12 und beim 192er /16 machen, ist es relevant?
Es ist bei allen /24 als Standard gelassen und meines Wissens nach passt das auch. Suffixe ist allerdings so ne Sache... die ich nicht ganz checke.

Nein, nein, nein ... kommst du mit Netzmasken klar?

/24 ist nur eine neumodische Art, 255.255.255.0 zu schreiben. Sonst nichts.
/8 --> 255.0.0.0
etc.

Deine lokal angeschlossenen Netze sind in der Größe /24 schon ganz passend für die meisten Anwendungsfälle. Das heißt, du kannst rund 250 Geräte in jedes Netz hängen. Manchmal nimmt man auch /16 - da gehen dann rund 65000 Geräte, wobei so viele Systeme in einem flachen Ethernet nicht gesund sind. Aber vielleicht hat man eine Konferenz mit 1000 Teilnehmern, jeder bringt mindestens einen Laptop und ein Telefon ... /24 ist zu klein, und bevor man lang rummacht, nimmt mal halt /16. Mehr als eine handvoll Tausend an Geräten sind trotzdem nicht gut.

Wenn ich für den AP mal testweise einen anderen Port nehme, dann bekommt der AP nur an dem WLAN-Port eine IP per DHCP, andere vergeben nichts. Alle Ports sind statisch eingerichtet. Von wo aus wird per DHCP auf dem WLAN-Port die IP an den angeschlossenen AP vergeben? Und das ist genau der Port, der nicht anpingbar ist.

Der DHCP-Dienst ist natürlich nur für LAN ab Werk eingerichtet, und wenn du neue Interfaces hinzufügst, musst du auch für jedes DHCP einschalten und konfigurieren. Wie soll das sonst gehen?

Es ist die Floating-Regel (siehe oben im Bild): any --> ! private networks. Diese Regel erlaubt wohl nicht nur den Zugang zum Internet, sondern bricht alle verbote zwischen den Interfaces.

Nö. Quelle: any - Ziel: ! private networks bedeuted genau das. Die Regel gilt für jedes Quell-System, als Ziel sind aber nur Adressen erlaubt, die *nicht* in private_networks drin sind.

Dein Denkfehler ist womöglich, dass diese Regel für alle Pakete, die nicht auf diese Specs matchen, eben nicht gilt.

Also "any --> ! private_networks" heißt nicht, dass man die privaten Netze nicht erreichen kann. Es bedeutet, dass diese spezifische "allow" Regel auf alle Pakete angewandt wird, die von "any" in "etwas anderes als private_networks" gehen.

Pakete, auf die das nicht zutrifft, werden nicht automatisch geblockt, sondern es wird nun die nächste Regel in der Reihenfolge angeguckt, ob die vielleicht passt.

Regeln sind "was für Pakete genau? Quelle, Ziel, UDP/TCP, Gedöns?" und wenn diese Kriterien passen, dann "Aktion", meistens "allow", weil am Ende ja sowieso alles andere verboten wird. Passt die Regel nicht, ist das aber kein "deny", sondern es wird einfach die nächste Regel in der Liste angeguckt, ob die passt.

Guck dir deine Regeln noch mal in der Hinsicht an. Speziell, überleg dir mal, du willst von deinem PC z.B. auf den AP zugreifen per TCP auf Port 443 (ich rate jetzt mal, dass da das Web UI ist).

Dann werden die Regeln in der Reihenfolge

- Floating
- Interface Groups
- Interface

Und da einfach von oben nach unten angeguckt, bis eine gefunden wird, bei der die Kriterien matchen. Und dann, wenn diese gefunden ist, wird die konfigurierte Aktion ausgelöst: allow/deny.

Wird gar keine gefunden, fällt das Regelwerk durch bis zum Ende, wo immer ein Default "deny all" wartet, und das Paket wird geblockt.

Keine Ahnung wie IPfire das macht, aber glaub mir, jeder Packetfilter, mit dem ich in den letzten 30 Jahren zu tun hatte, macht das genau so.

[bread]

Was ist denn der Grund zum Wechseln? Ich meine, wenn es funktioniert und du damit klar kamst?

Ich wollte eine potentere FW und mehr Flexibilität, da habe ich mir die Protectli VP4630 geholt mit 6 Ports und ipfire unterstützt nur 4 Zonen, also 4 NICS, die anderen müssen als VLAN implementiert werden. Und ich habe bisher nichts mit VLAN zu tun gehabt und ehrlich gesagt... will ich auch nicht... ich will Kabel anfassen und in die Ports einstecken  :D

Nein, nein, nein ... kommst du mit Netzmasken klar?

mittelmäßig  8)

/24 bedeutet, dass nur die letzte Stelle, also von 1 bis 250 (warum eigentlich nicht 255?) genutzt werden kann. So war das glaub ich. Je weniger die Zahl, desto mehr IPs können genutzt werden. Obwohl ich das dann nicht verstehe, weil sich ja Subnet ändert. Aber das müssen wir hier nicht klären, sonst wirds zu unübersichtlich im Thread. Da muss ich mich bei Gelegenheit einlesen.

Also lasse ich alle bei /24

Was mir einfällt. Als ich Private_Networks gemacht habe. Sind es folgende geworden: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 Muss ich sie auch dort alle auf 24 setzen? Ich vermute stark.

Der DHCP-Dienst ist natürlich nur für LAN ab Werk eingerichtet, und wenn du neue Interfaces hinzufügst, musst du auch für jedes DHCP einschalten und konfigurieren. Wie soll das sonst gehen?

Habs vergessen, dass ich selbst für WLAN DHCP eingerichtet habe  :D
Bei ipfire ist die DHCP-Einrichtung direkt beim Interface, hier ist es in einem Extra Menüpunkt. Das ist verwirrend (zumindest für mich).

Also "any --> ! private_networks" heißt nicht, dass man die privaten Netze nicht erreichen kann. Es bedeutet, dass diese spezifische "allow" Regel auf alle Pakete angewandt wird, die von "any" in "etwas anderes als private_networks" gehen.

Aber warum war dann bei der Einstellung der Zugang von privaten Netzen untereinander möglich?

Jetzt habe ich ja
PrivateDevices (die ins Internet sollen, Subnetz-übergreifend) --> ! PrivateNetworks
Und ich komm damit ins Internet, aber nicht in die anderen Subnetze (wie es sein soll).
Dann verstehe ich den ! so, dass es wie ein "NEIN" wirkt. PrivateDevices sollen überall hin nur NICHT in die PrivateNetworks, korrekt?

Die Sache ist, dass das Scheitern vom Zugriff auf WLAN definitiv nicht mit den FW Regeln zu tun hat.
Es ist etwas an den Interface-Einstellungen vermute ich.
Es hat alles funktioniert als ich am anderen Port (192er) das Ganze ausprobiert habe. 172er klappt nicht, auch nicht, wenn ich ihn auf den zuvor funktionierenden 192er migriere (also dort einen 172er draus mache).

[Patrick M. Hausen]

Was mir einfällt. Als ich Private_Networks gemacht habe. Sind es folgende geworden: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 Muss ich sie auch dort alle auf 24 setzen? Ich vermute stark.

Nein, musst du nicht. Das sind einfach alle privaten (RFC 1918) Netze, die es überhaupt gibt. Daher ist es sinnvoll. in einer Regel zu sagen:

von: diesem Interface
nach: überall hin, aber nicht in irgendeines dieser privaten Netze

Du könntest ja in Zukunft weitere Interfaces hinzufügen.

192.168.0.0/16 enthält einfach alle möglichen Netze von 192.168.0.0/24, 192.168.1.0/24, ... bis 192.168.255.0/24 - 256 Stück.

Mit diesem "Subnetz-Kram" solltest du dich ein bisschen mehr befassen, der ist wichtig.

Zu der Frage "weshalb nur 250" - ich hatte "rund 250" geschrieben und "rund 65000". :)

Tatsächlich hat ein /24 eine Größe von 256 Adressen. x.y.z.0 bis x.y.z.255.

Davon sind die 0 und die 255 definiert durch das Protokoll, 255 ist die Broadcast-Adresse, so ein Paket geht an alle angeschlossenen Systeme. Bleiben als 254 von 256 nutzbar für deine Hosts. Und von den 254 wird eine die Firewall brauchen, oder was auch immer für ein Gerät der Router in diesem Netzwerk ist, bleiben 253 für Hosts/Clients.

So weit ins Detail wollte ich aber in dem Moment nicht gehen.

Bei einem /16 sind es 65536 Adressen und nach denselben Überlegungen 65533 für Clients, wobei wie schon gesagt mehr als ein paar Tausend keinen Sinn machen.

Also "any --> ! private_networks" heißt nicht, dass man die privaten Netze nicht erreichen kann. Es bedeutet, dass diese spezifische "allow" Regel auf alle Pakete angewandt wird, die von "any" in "etwas anderes als private_networks" gehen.

Aber warum war dann bei der Einstellung der Zugang von privaten Netzen untereinander möglich?

Weil diese Regel ja nicht gegriffen hat. Das Paket ging ja nicht von "any" nach "! private_networks"  - offensichtlich gab es weiter unten in der Reihenfolge eine Regel, die das erlaubt hat.

Jetzt habe ich ja
PrivateDevices (die ins Internet sollen, Subnetz-übergreifend) --> ! PrivateNetworks
Und ich komm damit ins Internet, aber nicht in die anderen Subnetze (wie es sein soll).
Dann verstehe ich den ! so, dass es wie ein "NEIN" wirkt. PrivateDevices sollen überall hin nur NICHT in die PrivateNetworks, korrekt?

Das "!" ist ein "nein", korrekt. Aber lies dir meinen letzten Beitrag nochmal durch. Diese Regel bedeutet nicht, "Verbindungen in private_networks sind verboten".

Sie bedeutet "diese Regel gilt für alle Pakete, bei denen die Quelle any und das Ziel nicht private_networks ist".

Kommt nun ein Paket mit einer beliebigen Quelle und dem Ziel private_networks, dann greift die natürlich nicht. Dann greift irgendeine der nachfolgenden Regeln.

Was du in der Regel angibst, sagt, für welche Pakete die "Action" gilt. Wenn die Regel nicht "matcht", passiert überhaupt nichts, sondern es werden alle folgenden Regeln abgeklappert, bis es eine gibt, die matcht.

Erst wenn gar keine zutrifft, landen wir beim "deny".

[bread]

Danke für die Subnetzerklärung, ja, da werde ich noch mehr eintauchen müssen.
Habe jetzt mal statt den IPs für Subnetze die Interfaces genommen. Funktioniert auch.

Weil diese Regel ja nicht gegriffen hat. Das Paket ging ja nicht von "any" nach "! private_networks"  - offensichtlich gab es weiter unten in der Reihenfolge eine Regel, die das erlaubt hat.

Es gab aber keine.

Sie bedeutet "diese Regel gilt für alle Pakete, bei denen die Quelle any und das Ziel nicht private_networks ist".

Ah! verstanden... aber da muss man ja bei OPNsense eine völlig eigene Logik lernen... puh  :D wie ne Fachsprache.
Oder ist es bei anderen FWs ebenfalls gängig und nur ipfire ist etwas für 'consumer'?

Mein WLAN-Problem verstehe ich allerdings weiterhin nicht.

[Patrick M. Hausen]

Sie bedeutet "diese Regel gilt für alle Pakete, bei denen die Quelle any und das Ziel nicht private_networks ist".

Ah! verstanden... aber da muss man ja bei OPNsense eine völlig eigene Logik lernen... puh  :D wie ne Fachsprache.
Oder ist es bei anderen FWs ebenfalls gängig und nur ipfire ist etwas für 'consumer'?

Alle Packetfilter funktionieren genau so.

Cisco IOS
Juniper JunOS
Livingston Portmaster
Linux IPchains
FreeBSD/OPNsense pf
FreeBSD IPFW
...

Keine Ahnung, was IPfire da tut.

Firewall-Regeln bestehen aus:

- einer Sammlung von Kriterien für Netzwerkpakete, die abgeprüft werden
- einer Aktion, die durchgeführt wird, wenn die Prüfung erfolgreich ist

Damit plus mit der generellen Angabe, dass die Regeln von oben nach unten abgearbeitet werden, bis irgendeine greift, kann man jede gewünschte Policy implementieren.

[bread]

Alle Packetfilter funktionieren genau so.

Dachte ichs mir schon. Ja, ipfire scheint da einen eigenen Weg zu gehen. Wohl eher schlichter, mit einer einfacheren Logik. Dafür aber wohl nicht so umfangreich, eher was für home Anwender.

Soll ich für das seltsame WLAN-Port-Problem nen eigenen Topic aufmachen?
Im Grunde ist es ein anderes Thema. Ins Internet komme ich mittlerweile.

Hier gehts weiter mit dem ausgelagerten Thema:
https://forum.opnsense.org/index.php?topic=41220.0

[bimbar]

Wenn dein WLAN ein 30stelliges zufälliges Passwort hat, und nur vertrauenswürdige Geräte drin sind, mache ich mir zumindest dahingehend keine Sorgen.

Klar, da kann man privat denk ich entspannt sein. Bei einem Firmennetzwerk macht es denk ich durchaus Sinn zu trennen. BYOD und Co.

Warum Floating? Die Regel gehört auf das LAN-Interface

Ich bin einfach dem Kollegen @bimbar gefolgt. Er setzt auf Floating.
Im Grunde hat man dann alle Regeln parat.
Gibt es Nachteile?

Ich denk, die Übersichtlichkeit leidet dann doch darunter. Vermutlich wäre das der Grund die Regeln doch auf dem jeweiligen Interface zu machen.

Habe die Regel im LAN erstellt. Von LAN net zu WLAN net und erreich das Ding trotzdem nicht.. hä?
Irgendwo stehe ich wohl auf dem Schlauch.

Hier gibt es viele Möglichkeiten, das zu strukturieren, von denen nicht unbedingt eine richtig und die andere falsch ist.
Ich bin kein Fan von den Interfaceregeln, weil wenn man mal was anders routen will, dann passen die Firewallregeln alle nicht mehr (hauptsächlich ein Thema bei größeren Umgebungen).
Außerdem bin ich Astaro geprägt, wo es die Möglichkeit nicht gab, Regeln an Interfaces zu hängen.
Vielleicht sind aber Interface spezifische Regeln schneller - falls das relevant ist.

[bimbar]

Danke für die Subnetzerklärung, ja, da werde ich noch mehr eintauchen müssen.
Habe jetzt mal statt den IPs für Subnetze die Interfaces genommen. Funktioniert auch.

Weil diese Regel ja nicht gegriffen hat. Das Paket ging ja nicht von "any" nach "! private_networks"  - offensichtlich gab es weiter unten in der Reihenfolge eine Regel, die das erlaubt hat.

Es gab aber keine.

Sie bedeutet "diese Regel gilt für alle Pakete, bei denen die Quelle any und das Ziel nicht private_networks ist".

Ah! verstanden... aber da muss man ja bei OPNsense eine völlig eigene Logik lernen... puh  :D wie ne Fachsprache.
Oder ist es bei anderen FWs ebenfalls gängig und nur ipfire ist etwas für 'consumer'?

Mein WLAN-Problem verstehe ich allerdings weiterhin nicht.

Jede Firewall hat ihre eigene Logik, das "!" als Verneinung aber kommt aus der Programmiersprache C und wird ziemlich universal verstanden.
Ansonsten ist allen gemein, daß es im Grunde Regelmaschinen sind, die in der Form "Paket Match -> Action" funktionieren.

[bread]

@bimbar: danke für die Infos!

Haste vielleicht noch Ideen zu meinem Port-Problem, welches ich mittlerweile in ein anderes Topic ausgelagert habe (siehe oben) :)

[Patrick M. Hausen]

@bread lass uns das doch am Freitag angucken - irgendwann ist über ein Forum echt Schluss :)

[bimbar]

@bimbar: danke für die Infos!

Haste vielleicht noch Ideen zu meinem Port-Problem, welches ich mittlerweile in ein anderes Topic ausgelagert habe (siehe oben) :)

Habe ich gelesen, da stimme ich Patrick zu, ich verstehe aus dem Post nicht, warum das nicht funktioniert, da ist wahrscheinlich irgendein Detail fehlkonfiguriert.