17
PfSense IPv6 Routing
Hallo zusammen,
ich gehe mal davon aus, wenn das Wort IPv6 Fällt , ist der Beitrag schon entfernt.
ALso um was gehts.
Wir haben einen Server ins RZ gestellt und ein ipv4/ IPv6 Netz bekommen.
Standard /64 war ja klar.
Konfiguriert ist sowohl IPv4 als auch IipV6 auf dem Internet Interface.
Internetzugriff mittels NAT über ipv4 klappt problemlos.
Allerdings möchte ich nun das Global Unicast Iv6 direkt durch routen und jeder Vm ein eigene IPv6 geben.
Statische Adressen wären da wohl das einfachste neben SLAAC. Aber das lasse ich erstmal weg.
Also was habe ich gemacht:
Im WAN das statische IPv6 Eingetragen und als Upstream Gateway das IPv6 Gateway eingetragen.
Address: 2001:XXXX:XX::2/64
Gateway: 2001:XXXX:XX::1/64
Im LAN Interface aus /64 eine /68 mit einem Zusätzlichen HEX Zeichen gemacht
Address: 2001:XXXX:XX:1:2::1/68
Macht zur Netz trennung Sinn oder ?
Anschließend eine Routing Regel von LAN -- IPv6 --> Internet -- pass
Ich bekomme allerdings kein Netz mittels statischer Config auf den VMs.
Das Interne Gateway scheint ich nicht mal anpingen zu können.
Address: 2001:XXXX:XX:1:2::1/68
WIe bekomme ich das hin ?
Habe ich eventuell etwas vergessen ?
Vielen Dank
Christian
ich gehe mal davon aus, wenn das Wort IPv6 Fällt , ist der Beitrag schon entfernt.
ALso um was gehts.
Wir haben einen Server ins RZ gestellt und ein ipv4/ IPv6 Netz bekommen.
Standard /64 war ja klar.
Konfiguriert ist sowohl IPv4 als auch IipV6 auf dem Internet Interface.
Internetzugriff mittels NAT über ipv4 klappt problemlos.
Allerdings möchte ich nun das Global Unicast Iv6 direkt durch routen und jeder Vm ein eigene IPv6 geben.
Statische Adressen wären da wohl das einfachste neben SLAAC. Aber das lasse ich erstmal weg.
Also was habe ich gemacht:
Im WAN das statische IPv6 Eingetragen und als Upstream Gateway das IPv6 Gateway eingetragen.
Address: 2001:XXXX:XX::2/64
Gateway: 2001:XXXX:XX::1/64
Im LAN Interface aus /64 eine /68 mit einem Zusätzlichen HEX Zeichen gemacht
Address: 2001:XXXX:XX:1:2::1/68
Macht zur Netz trennung Sinn oder ?
Anschließend eine Routing Regel von LAN -- IPv6 --> Internet -- pass
Ich bekomme allerdings kein Netz mittels statischer Config auf den VMs.
Das Interne Gateway scheint ich nicht mal anpingen zu können.
Address: 2001:XXXX:XX:1:2::1/68
WIe bekomme ich das hin ?
Habe ich eventuell etwas vergessen ?
Vielen Dank
Christian
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 421330
Url: https://administrator.de/contentid/421330
Ausgedruckt am: 05.11.2024 um 12:11 Uhr
17 Kommentare
Neuester Kommentar
Moin ..
zumindest hast du etwas wesentliches nicht beachtet:
zudem solltest du zusätzlich lokale ipv6 konfigurieren.
VG
zumindest hast du etwas wesentliches nicht beachtet:
Hinweis: Die IPv6-Autokonfiguration funktionieren nicht mit weniger als 64 Bit im Interface Identifier. Das
von: https://www.elektronik-kompendium.de/sites/net/1902111.htm
von: https://www.elektronik-kompendium.de/sites/net/1902111.htm
zudem solltest du zusätzlich lokale ipv6 konfigurieren.
VG
Zitat von @fundave3:
ich gehe mal davon aus, wenn das Wort IPv6 Fällt , ist der Beitrag schon entfernt.
ich gehe mal davon aus, wenn das Wort IPv6 Fällt , ist der Beitrag schon entfernt.
Nein, wieso? Ist doch vollkommen legitim
Da du auf beiden Seiten der Firewall vom Prinzip her identische Netze hast, wirst du ohnehin Probleme bekommen - das könnte auch erklären, weshalb du bereits keinen Ping im internen Netz hinbekommst.
Und die Firewall kann eigentlich das Netz nur routen, wenn sie auch NDP-Proxy ist.
Denn momentan wird der Router des Providers für jede IPv6-Adresse per NDP fragen, wer die Pakete denn haben will - und das müsste dann deine Firewall beantworten.
Um diese beiden Probleme zu vermeiden solltest du den Hoster bitten, dir ein IPv6-Präfix über ein Transfernetz direkt auf die Firewall zu routen - dann hast du an WAN und LAN zwei disjunkte Netze und bekommst vor allen Dingen ein sauberes Routing ohne NDP-Proxy hin.
Bei richtigem Routing entfällt nämlich die Fragerei nach NDP und der Router adressiert alle Pakete des gerouteten Präfix direkt an deine Firewall.
Zitat von @ashnod:
zumindest hast du etwas wesentliches nicht beachtet:
zumindest hast du etwas wesentliches nicht beachtet:
Hinweis: Die IPv6-Autokonfiguration funktionieren nicht mit weniger als 64 Bit im Interface Identifier. Das
von: https://www.elektronik-kompendium.de/sites/net/1902111.htm
von: https://www.elektronik-kompendium.de/sites/net/1902111.htm
Dass die Autokonfiguration nicht funktioniert, ist bei statisch konfigurierten Adressen doch egal...
wenn das Wort IPv6 Fällt , ist der Beitrag schon entfernt.
Warum ? Ein spannendes und auch aktuelles Thema ! Außerdem entfernen kannst nur du als TO selber oder einer der Moderatoren hier Macht zur Netz trennung Sinn oder ?
Das musst du sonst ist logischerweise doch gar kein Routing möglich !Anschließend eine Routing Regel
Das ist keine Routing Regel sondern eine Firewall Regel !! Das solltest du nicht verwechseln !Ich bekomme allerdings kein Netz
Was meinst du genau damit ?? "Kein Netz" ist ja etwas laienhaft und oberflächlich. Du meinst du kannst keine anderen IPv6 Netze oder Hosts im Internet anpingen ??Dann stimmen entweder...
- deine Adressierung
- oder deine Firewall regeln nicht !!
Von den v6 Adressierungsfehlern die Kollege @LordGurke schon angesprochen hat mal gar nicht zu reden.
Grundsätzlich solltest du mal mit deinem Provider klären ob die ggf. die v6 Adressen per Prefix Delegation bekommst oder ob diese statisch sind und wenn letzteres der Fall ist welchen Prefix du zugewiesen bekommen hast ?
Meist sind das /56 die du dann entsprechend in /64 subnetten musst intern.
Für v6 PD findest du hier ein paar Infos:
https://docs.netgate.com/pfsense/en/latest/dhcp/dhcpv6-server.html
https://moerbst.wordpress.com/2016/07/31/ipv6mit-pfsense-an-dsl-der-tele ...
Guten Abend,
okay, ich glaue ich kann euch zumindest mal Folgen.
NDP macht Sinn - ICh will ja Öffentliche Adressen nach intern Routen. Da ist es natürlich legitim wohin die Pakete gehen.
So wie ich das jetzt verstanden habe, brauche ich für SLAAC ein /64 Prefix ?
Hmm, achso, klar da gabs ja noch die möglichkeiten der Bildung des interface identifiers. ( Anhand der MAC Adresse / Dynamisch.)
Stimmt, das hätte ich mir denken können.
Bekommen habe ich einen /64 Netz. KEin /56 - feste /64 . Alles weitere darf ich ja selber unterteilen.
Heißt ich brauche einen NDP PRoxy. Allerdings finde ich in der PFsense keine Funktion.
Tante Google hat mich auf ICMPv6 gebracht ? ISt doch was ganz anderes ?
Das IPv6 kompliziert wird, dachte ich mir, aber irgendwie muss das ja funktionieren.
Vielen Dank
okay, ich glaue ich kann euch zumindest mal Folgen.
NDP macht Sinn - ICh will ja Öffentliche Adressen nach intern Routen. Da ist es natürlich legitim wohin die Pakete gehen.
So wie ich das jetzt verstanden habe, brauche ich für SLAAC ein /64 Prefix ?
Hmm, achso, klar da gabs ja noch die möglichkeiten der Bildung des interface identifiers. ( Anhand der MAC Adresse / Dynamisch.)
Stimmt, das hätte ich mir denken können.
Bekommen habe ich einen /64 Netz. KEin /56 - feste /64 . Alles weitere darf ich ja selber unterteilen.
Heißt ich brauche einen NDP PRoxy. Allerdings finde ich in der PFsense keine Funktion.
Tante Google hat mich auf ICMPv6 gebracht ? ISt doch was ganz anderes ?
Das IPv6 kompliziert wird, dachte ich mir, aber irgendwie muss das ja funktionieren.
Vielen Dank
NDP ist das Adressauflösungsprotokoll, was bei IPv4 ARP war - und NDP ist einfach ein ICMPv6-Nachrichtentyp.
Was bei IPv4 zum Teil in eigene Protokolle zerlegt war ist bei IPv6 in ICMPv6 zusammengefasst. Es ist also quasi alles ICMPv6, bis auf DHCPv6, das ist weiterhin UDP
Ein NDP-Proxy ist daher funktionell identisch mit dem ARP-Proxy bei IPv4.
Hintergrund warum du den bei deinem Setup brauchst ist:
Wenn du zwei Geräte im Netzwerk hast (A und B), welche sich beide im selben Subnetz befinden, wird A per NDP/ARP fragen, wer denn diese IP-Adresse hat, damit er die MAC-Adresse herausfindet, an die er dann die Pakete adressieren muss.
B wird dann antworten, wobei sich aus der Antwort dann die eigene MAC-Adresse von B ergibt (denn von dort kommt ja das Paket) und die Kommunikation kann beginnen.
Wenn B nun dein Router ist und dahinter C steht, welcher sich aber im selben Subnetz wie A und B befindet, hast du ein Problem:
Die NDP/ARP-Anfragen erreichen ja nur B und werden von dem nicht weitergeleitet. Wenn A nun mit C kommunizieren will, müsste dein Router B auf die NDP/ARP-Anfragen antworten, damit die Pakete für C bei B ankommen, der das weiterleiten kann.
Das klingt nicht nur kompliziert und unschön, das ist es auch.
Besser wäre, dein Hoster würde dir ein zweites IPv6-Präfix routen. Oder dir ein Transfernetz zuweisen und dann das bestehende IPv6-Präfix über das Transfernetz routen.
Da sieht das Setup dann so aus:
Du hast A, das ist der Router deines Hosters. Dann hast du B, das ist deine Firewall. Und du hast C, das ist einer deiner Server.
Dein Hoster würde dir jetzt ein Transfernetz stellen - sagen wir mal 2001:db8:1:2:3:4::/112.
Daraus nimmt sich dein Hoster die Adresse ::a für sich und du benutzt ::b für deine Firewall.
Auf der WAN-Seite hat B also nun die Adresse 2001:db8:1:2:3:4::b/112.
Die LAN-Seite von B ist mit dem Präfix, welches du vom Provider erhältst, versehen - z.B.: 2001:db8:5678:6543::/64.
Dein Provider konfiguriert auf seinem Router eine statische Route:
2001:db8:5678:6543::/64 -> 2001:db8:1:2:3:4::b
Damit weiß der Router A, dass deine Firewall B das Routing für das Präfix übernimmt. Per NDP wird dann nur noch nach 2001:db8:1:2:3:4::b gefragt (was ja deine Firewall sowieso beantwortet), die Pakete für das geroutete Präfix werden dann an die selbe MAC-Adresse adressiert und der ganze Zirkus mit dem NDP-Proxy entfällt.
DAS wäre übrigens auch das bevorzugte Setup für IPv4-Netze, die hinter einer Firewall erreichbar sein sollen - da kann man sich aber leichter aus der Affäre winden, indem man NAT einsetzt. Sonst wäre auch dort ARP-Proxy notwendig, wenn du eine öffentliche IP direkt auf seinem Server hinter der Firewall ohne NAT haben willst.
Was bei IPv4 zum Teil in eigene Protokolle zerlegt war ist bei IPv6 in ICMPv6 zusammengefasst. Es ist also quasi alles ICMPv6, bis auf DHCPv6, das ist weiterhin UDP
Ein NDP-Proxy ist daher funktionell identisch mit dem ARP-Proxy bei IPv4.
Hintergrund warum du den bei deinem Setup brauchst ist:
Wenn du zwei Geräte im Netzwerk hast (A und B), welche sich beide im selben Subnetz befinden, wird A per NDP/ARP fragen, wer denn diese IP-Adresse hat, damit er die MAC-Adresse herausfindet, an die er dann die Pakete adressieren muss.
B wird dann antworten, wobei sich aus der Antwort dann die eigene MAC-Adresse von B ergibt (denn von dort kommt ja das Paket) und die Kommunikation kann beginnen.
Wenn B nun dein Router ist und dahinter C steht, welcher sich aber im selben Subnetz wie A und B befindet, hast du ein Problem:
Die NDP/ARP-Anfragen erreichen ja nur B und werden von dem nicht weitergeleitet. Wenn A nun mit C kommunizieren will, müsste dein Router B auf die NDP/ARP-Anfragen antworten, damit die Pakete für C bei B ankommen, der das weiterleiten kann.
Das klingt nicht nur kompliziert und unschön, das ist es auch.
Besser wäre, dein Hoster würde dir ein zweites IPv6-Präfix routen. Oder dir ein Transfernetz zuweisen und dann das bestehende IPv6-Präfix über das Transfernetz routen.
Da sieht das Setup dann so aus:
Du hast A, das ist der Router deines Hosters. Dann hast du B, das ist deine Firewall. Und du hast C, das ist einer deiner Server.
Dein Hoster würde dir jetzt ein Transfernetz stellen - sagen wir mal 2001:db8:1:2:3:4::/112.
Daraus nimmt sich dein Hoster die Adresse ::a für sich und du benutzt ::b für deine Firewall.
Auf der WAN-Seite hat B also nun die Adresse 2001:db8:1:2:3:4::b/112.
Die LAN-Seite von B ist mit dem Präfix, welches du vom Provider erhältst, versehen - z.B.: 2001:db8:5678:6543::/64.
Dein Provider konfiguriert auf seinem Router eine statische Route:
2001:db8:5678:6543::/64 -> 2001:db8:1:2:3:4::b
Damit weiß der Router A, dass deine Firewall B das Routing für das Präfix übernimmt. Per NDP wird dann nur noch nach 2001:db8:1:2:3:4::b gefragt (was ja deine Firewall sowieso beantwortet), die Pakete für das geroutete Präfix werden dann an die selbe MAC-Adresse adressiert und der ganze Zirkus mit dem NDP-Proxy entfällt.
DAS wäre übrigens auch das bevorzugte Setup für IPv4-Netze, die hinter einer Firewall erreichbar sein sollen - da kann man sich aber leichter aus der Affäre winden, indem man NAT einsetzt. Sonst wäre auch dort ARP-Proxy notwendig, wenn du eine öffentliche IP direkt auf seinem Server hinter der Firewall ohne NAT haben willst.
Achso, klar macht Sinn.
Danke für die Erklärung.
Okay, kann das sein, ich habe auf der WAN Seite das GLobal Unicast Netz /64 und auf der LAN Seite das gleiche.
Der komme bestimmt damit in konflikt ?
SLAAC hat schon mal funktioniert. Also die VM hat sich mittels SLAAC eine Adresse gegeben.
KAnn ich nicht einfach eine Netzwerkbrücke bauen für v6 ? Aber dann müsste v4 ja auch gebridged sein oder deaktiviert sein oder?
Ich werde das mal anfragen ob das geht. Könnten doch theoretisch auch PRivate Adressen sein oder ? fd00::/7
Vielen Dank
Christian
Danke für die Erklärung.
Okay, kann das sein, ich habe auf der WAN Seite das GLobal Unicast Netz /64 und auf der LAN Seite das gleiche.
Der komme bestimmt damit in konflikt ?
SLAAC hat schon mal funktioniert. Also die VM hat sich mittels SLAAC eine Adresse gegeben.
KAnn ich nicht einfach eine Netzwerkbrücke bauen für v6 ? Aber dann müsste v4 ja auch gebridged sein oder deaktiviert sein oder?
Ich werde das mal anfragen ob das geht. Könnten doch theoretisch auch PRivate Adressen sein oder ? fd00::/7
Vielen Dank
Christian
ich habe auf der WAN Seite das GLobal Unicast Netz /64 und auf der LAN Seite das gleiche.
Na ja diese Frage kannst du dir doch auch selber beantworten, oder ??"Ich habe auf der einen Seite des Routers 192.168.1.0 /24 und auf der anderen Seite 192.168.1.0 /24 "
Den Unsinn muss man in einem Admin Forum sicher nicht weiter kommentieren.
Wie bitte soll denn der Router bei doppelter IP Adressierung eine eindeutige Wegefindung sicherstellen ? In der IP Grundschule lernt man doch als Erstes das IP Adressen einzigartig zu sein haben in einem Netzwerk. Dagegen hast du ja mit dem obigen Design fundamental verstoßen und einen Kardinalsfehler im Adressdesign gemacht.
Das diese Grundlagen für IPv6 ebenso gelten ist evident.
KAnn ich nicht einfach eine Netzwerkbrücke bauen für v6 ?
Jein ! Generell und in der Theorie ja, hier aber klar NEIN !! Wieder etwas nachdenken...!Dein Router oder Firewall routet ja auch IPv4 zw. Segment A und B. Wenn du nun Segment A und B als Bridge definierst, dann bridgest du ja gleichzeitig auch IPv4. Das geht aber nicht denn dort nutzt du ja richtigerweise schon 2 unterschiedliche IP Netze wie es sein soll, musst also routen !
Physisch können diese beiden Segmente nicht gleichzeitig als Bridge und Router arbeiten. Leuchtet ein...
Außerdem lernt der Netzwerker ebenso in der IP Grundschule "Route where you can, bridge where you must !".
In einer gerouteten Umgebung wie bei dir, zumal an einer so wichtigen Stelle wie der Kopplung ins öffentliche Internet bridged man niemals, immer Routing.
Fazit also...lass dir von deinem Provider ein 2tes Segment geben wie Kollege @LordGurke schon sagt und gut iss.
Es ist auch völlig unüblich das der Provider dir ein /64 gibt, denn bei Global Unicasts kannst du das nicht weiter segmentieren, dort werden nur /64er minimal geroutet.
Hier solltest du übrigens auch mal dringenst reinsehen:
https://danrl.com/projects/ipv6-workshop/
Kostet nix und wird dir sehr helfen mit dem Thema !
Hallo Zusammen,
ja IPv6 ist generell nicht gerade mein Lieblingsthema stimmt.
Okay,
Ich habe euren Rat befolgt und folgendes erfahren.
Wir haben jetzt 2001:xxxx:x:/48 auf --> 2001:xxxx:x:1/64 geroutet bekommen und das erste /64 2001:xxxx:x:0 wird als Transfer Netz genutzt.
Hmm, jetzt komme ich gar nicht mehr zum Gateway.
ICh werde mich mal einlesen. Das ist ja furchtbar IPv6
Verzeiht mir.
ja IPv6 ist generell nicht gerade mein Lieblingsthema stimmt.
Okay,
Ich habe euren Rat befolgt und folgendes erfahren.
Wir haben jetzt 2001:xxxx:x:/48 auf --> 2001:xxxx:x:1/64 geroutet bekommen und das erste /64 2001:xxxx:x:0 wird als Transfer Netz genutzt.
Hmm, jetzt komme ich gar nicht mehr zum Gateway.
ICh werde mich mal einlesen. Das ist ja furchtbar
IPv6Verzeiht mir.
Auch das ist alles wie bei IPv4
Du gibst dem WAN-Interface deiner pfSense die Adresse 2001:xxxx:x:1/64.
Dem LAN-Interface gibst du dann eine Adresse aus dem gerouteten Präfix. Fertig.
Du gibst dem WAN-Interface deiner pfSense die Adresse 2001:xxxx:x:1/64.
Dem LAN-Interface gibst du dann eine Adresse aus dem gerouteten Präfix. Fertig.
Wir haben jetzt 2001:xxxx:x:/48 auf --> 2001:xxxx:x:1/64 geroutet bekommen und das erste /64 2001:xxxx:x:0 wird als Transfer Netz genutzt.
Perfekt !Damit ist das dann ein Kinderspiel !
Beispiel:
Deine /48er Adresse lautet z.B. 2001:dead:beef:: /48
Das subnettest du dann wie oben auch schon richtig gesagt in /64er Segmente.
Das erste /64er Subnetz was zum Routing auf den Provider benutzt wird ist dann
2001:dead:beef:0000::
Wenn hier im Transfer Netz jetzt der Provider Router die 2001:dead:beef::2 /64 hat dann gibst du der pfSense dahinter die 2001:dead:beef::1
Die Default Route :: /0 stellt du dann auf den Provider Router 2001:dead:beef::2 ein.
Fertisch !
Wenn du jetzt in der pfSense ins "Diagnostics" Menü gehst und dann dort unter "Ping" solltest du schon den Provider Router pingen können.
Dann noch deine lokalen LANs als /64er einrichten und gut iss. Z.B.:
2001:dead:beef:affe:: /64
2001:dead:beef:cafe:: /64
2001:dead:beef:bade:: /64
usw. usw.
v6 DNS Server noch einstellen auf den v6DNS des Providers, das wars.
Eigentlich kinderleicht und alles genau wie oben schon gesagt, exakt wie bei IPv4 !!
Bingo,
Tatächlich. Das Routing klappt.
Das ICMP musste ich durch erneutes hinzufügen von der IPv6 Default allow Regel erlauben aber sonst funktioniert alles einwandfrei.
Ehrlichgesagt bin ich mir noch nicht zu 100% Sicher , ob ich das alles so verstandanden habe, aber übertragen auf IPV4 macht das auf alle Fälle Sinn.
Vielen vielen Dank euch allen.
Hätte ich ein Öffentliches IPv4 NEtz wäre der teil doch genauso oder?
Eine Statische Route von meinem 1.0.0.0/8 Netz auf --> 1.0.0.0/16 und 10.2.1.1/16 für die Firewall und 1.3.1.0/16 für das LAN ?
Kann ich mir das in etwa so vorstellen ?
Tatächlich. Das Routing klappt.
Das ICMP musste ich durch erneutes hinzufügen von der IPv6 Default allow Regel erlauben aber sonst funktioniert alles einwandfrei.
Ehrlichgesagt bin ich mir noch nicht zu 100% Sicher , ob ich das alles so verstandanden habe, aber übertragen auf IPV4 macht das auf alle Fälle Sinn.
Vielen vielen Dank euch allen.
Hätte ich ein Öffentliches IPv4 NEtz wäre der teil doch genauso oder?
Eine Statische Route von meinem 1.0.0.0/8 Netz auf --> 1.0.0.0/16 und 10.2.1.1/16 für die Firewall und 1.3.1.0/16 für das LAN ?
Kann ich mir das in etwa so vorstellen ?
Tatächlich. Das Routing klappt.
Hattest du in einem Administrator Forum was anderes erwartet ?? Aber mal ehrlich das sind ja nun banale IP Grundlagen...!
ob ich das alles so verstandanden habe
Wo hapert es denn noch mit dem Verständnis ?? Vielleicht können wir da ja noch Licht ins letzte Dunkel bringen ??In jedem Falle solltest du etwas lesen zu dem Thema:
https://danrl.com/projects/ipv6-workshop/
Hätte ich ein Öffentliches IPv4 NEtz wäre der teil doch genauso oder?
Jepp, ganz genau ! Stinknormales IP Routing eben....Eine Statische Route von meinem 1.0.0.0/8 Netz auf --> 1.0.0.0/16 und 10.2.1.1/16 für die Firewall und 1.3.1.0/16 für das LAN ?
Etwas verschwurbelt was du da sagst zumal du auch noch 1er und 10er Netze wild durcheinanderbringst (Tippfehler ?!) aber letztlich ja wenn du es so meinst:
)Wie bereits gesagt...simpelste IP Routing Grundlagen !
Bingo,
Das ist eindeutig.
JA, jetzt macht es klick.
Eine Frage hätte ich da noch,
Die Firewall schiebt dann aber alles durch oder? Oder muss ich da mit Whitelist arbeiten ?
Ich habe das mal getestet mit einer Statischen Adresse auf einer VM.
SSH war sofort erreichbar.
Die Standard Regel ist von innen nach Außen alles , von außen das innen nix
Das ist eindeutig.
JA, jetzt macht es klick.
Eine Frage hätte ich da noch,
Die Firewall schiebt dann aber alles durch oder? Oder muss ich da mit Whitelist arbeiten ?
Ich habe das mal getestet mit einer Statischen Adresse auf einer VM.
SSH war sofort erreichbar.
Die Standard Regel ist von innen nach Außen alles , von außen das innen nix
JA, jetzt macht es klick.
Röchel....war ja eine schwere Geburt mit dir ! 
Die Firewall schiebt dann aber alles durch oder?
Ja !Da musst du natürlich dringend eine Regel erstellen.
Die einfachste ist inbound, also am Internet Interface, alles zu blocken was kein gesetztes ACK Bit hat !
So können nur v6 Pakete von außen die Firewall passieren die Antwort Pakete auf vom internen Netz initiierte Sessions sind.
So kann dann niemand direkt von außen auf die internen Netze zugreifen ! In die andere Richtung klappt aber alles.
Die Standard Regel ist von innen nach Außen alles , von außen das innen nix
Wäre natürlich Quatsch...weisst du auch selber.So würden ja auch alle Antwort Pakete hängen bleiben und nix geht mehr. Deshalb das ACK Bit !
@aqui:
Ich bin kein pfSense-Nutzer - aber es muss doch einen Weg geben, das schöner und weniger fehleranfällig zu lösen...
So würden z.B. RST- und FIN-Pakete ohne Grund verworfen (was zu merkwürdigen Verbindungsproblemen führen kann).
Eigentlich müsste die pfSense doch bestimmt stateful arbeiten können und so von alleine herausfinden können, welche Pakete zu einer bestehenden Verbindung gehören und welche nicht...
Ich bin kein pfSense-Nutzer - aber es muss doch einen Weg geben, das schöner und weniger fehleranfällig zu lösen...
So würden z.B. RST- und FIN-Pakete ohne Grund verworfen (was zu merkwürdigen Verbindungsproblemen führen kann).
Eigentlich müsste die pfSense doch bestimmt stateful arbeiten können und so von alleine herausfinden können, welche Pakete zu einer bestehenden Verbindung gehören und welche nicht...
@LordGurke
Ja du hast natürlich Recht und natürlich ist die pfSense auch Stateful ! Das war nur eine erste Quick and Dirty Lösung für den TO um ihn mal auf die richtige Fährte zu setzen das er auch mit mehr Attributen in der FW spielen kann als sich jetzt alles Netz einzelnd einzutragen.
Wie immer macht es Sinn sich das zuerst zu überlegen und dann in ein Regelwerk zu fassen.
Ja du hast natürlich Recht und natürlich ist die pfSense auch Stateful ! Das war nur eine erste Quick and Dirty Lösung für den TO um ihn mal auf die richtige Fährte zu setzen das er auch mit mehr Attributen in der FW spielen kann als sich jetzt alles Netz einzelnd einzutragen.
Wie immer macht es Sinn sich das zuerst zu überlegen und dann in ein Regelwerk zu fassen.
Hallo Ihr beiden,
Dankeschön. ICh musste seperate Regeln erstellen für jede VM.
Das scheint zu funktionieren.
Dankeschön. ICh musste seperate Regeln erstellen für jede VM.
Das scheint zu funktionieren.
