pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6
-
@fnbalu said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:
Wenn ich da statt der Lockout Regel definiere, dass admin.ddns.de da rein darf, dann reicht das sinngemäß, ja?
Wird dann gedroppt und die 443 gar nicht mehr angezeigt für die anderen?Man definiert ja nicht statt dem Lockout - oder meinst du dem allow any auf WAN? Dann natürlich.
Ansonsten ja, man kann ein Alias auch mit Domainname definieren und dieses wird dann (IMHO alle 15min) aktualisiert und im Filter neu eingeladen. IP4 oder IP6 oder beides kann darin enthalten sein und das erlaubt dann den Zugriff auch nur von diesem Alias aus. Alle anderen werden einfach geblockt als wäre der Port nicht offen - wie immer. -
@jegr Eben habe ich meine pfSense mal neu gestartet und warte nun mal wieder Minutenlang auf die IPv6. Das ist doch nicht normal. Das würde ja später auch ewig dauern, bis der VPN Tunnel wieder steht.
Nach einem Stromausfall etc -
@fnbalu Also wenn pfSense die v6 bekommt aber das eben erst sehr sehr spät, dann sehe ich da aber eher weniger ein pfSense Problem als eher ein Einstellungs- oder ISP Problem? Wenn sie gar keine bekäme OK, aber wenn sie eine bekommt und das dauert, dann würde ich ggf. mal beim ISP anfragen, was der Kram soll oder was er für Parameter möchte damit das ein wenig hurtiger geht. :)
-
@jegr So, die Deutsche Glasfaser habe ich jetzt zum Thema IPv6 Problem mal angeschrieben. Ich werde berichten. So kann es jedenfalls nicht bleiben.
Ich mache mir natürlich Gedanken zum Thema Wireguard und schaue Videos dazu.
Also ich möchte ja sämtlichen Traffic der über die IPv4 des Servers läuft bei mir zu Hause haben und dort kann meine pfSense diesen ja filtern. Oder macht vorher sondieren da mehr Sinn?-
Was ich mich aufgrund der IPv6 Problematik auch frage ist, ob ioch die Verbindung nicht auch mittels IPv4 aufbauen kann?
-
Zuerst war mal Site2Site angedacht, jedoch muss dann ja auch der Server (vps) die GegenIP kennen und da sind die Probleme siehe oben.
Geht da nicht auch VPS als Server und meine pfSense als Client?
Wie ich das verstehe, erstelle ich ein Tunnelnetzwerk wie bei OpenVPN ala 10.1.1.0, darüber läuft alles und würde dann, wenn keine Any/Any bei mir zu Hause ist, überall hinkommen.
Zu Hause würde ich dann sagen kommt etwas auf Port 80, so soll das bitte an 192.168.1.5 an Port 80 ankommen, wie gehabt.
Das müsste doch so auch als Client gehen und ich denke das ist dann wie EDV-Kossmann und was es da für Lösungen auch gibt, wenn man solch Raspi von denen nimmt.Die Regel beim vps müsste doch sein wan any wird an Ziel Tunnel gesendet (werde da wohl doch nur die HIGH Ports wie bisher annehmen anstatt alles)
Denke ich so gerade richtig? Gerade die IPv6 Geschichte tue ich mich so verdamt schwer gerade, das geht gar nicht.
-
-
@fnbalu Also ich möchte ja sämtlichen Traffic der über die IPv4 des Servers läuft bei mir zu Hause haben und dort kann meine pfSense diesen ja filtern. Oder macht vorher sondieren da mehr Sinn?
Das kannst du handhaben wie du möchtest und es kommt ja auch drauf an, ob du die komplette public IP einfach zu dir mappst durch den Tunnel oder nur gezielt irgendwelche Ports.
Was ich mich aufgrund der IPv6 Problematik auch frage ist, ob ioch die Verbindung nicht auch mittels IPv4 aufbauen kann?
Prinzipiell müsste das gehen, ja, da zwar hinter CGN bist aber trotzdem dann nach draußen gemappt wirst, dass du IPv4 auflösen kannst. Es kann aber sein, dass du in Hochzeiten wenn ggf. der Provider Auslastungsprobleme hat beim CGN dann Verbindungsprobleme bekommen könntest. Großprovider wie Vodafone (Kabel) etc. haben das schon hin und wieder. Da CGN/IPFT Gateways etc. oft in HW gebaut werden und HW teuer ist, wird da oft "gespart" so dass es dann in Spitzenzeiten gern zu Ladeproblemen bei v4 kommt. Ob das passiert - keine Ahnung, das ist von Provider zu Provider unterschiedlich.
Den Tunnel direkt via IPv6 aufzubauen wäre an der Stelle natürlich geschickter, wäre nicht anfällig gegen Probleme mit dem CGN und hätte dazu noch weniger Overhead weil IPv6 hier weniger Bytes für den Header "verschwendet" und damit dann minimal mehr Payload transportieren kann pro Paket.
Zuerst war mal Site2Site angedacht, jedoch muss dann ja auch der Server (vps) die GegenIP kennen und da sind die Probleme siehe oben.
Du denkst an IPsec? Oder an Wireguard? Verstehe nicht genau wo das herkommt. Wenn du an WG denkst, da ist es egal, das kann man auch "unidirektional" einrichten, dass nur eine Seite den Tunnel aufbaut. OpenVPN hat sowieso striktes Client->Server Prinzip und ist das egal.
Wie ich das verstehe, erstelle ich ein Tunnelnetzwerk wie bei OpenVPN ala 10.1.1.0, darüber läuft alles und würde dann, wenn keine Any/Any bei mir zu Hause ist, überall hinkommen.
Darüber wird geroutet, ja. Das Transfernetz ist aber meistens in irgendwelchen Regeln nicht in Verwendung und ist nur Routing Target. Du hast eigentlich keine Regeln wo das Source oder Destination ist.
Du kannst den VPS natürlich recht simpel einstellen und einfach alles erlauben (bis auf den Zugriff auf den VPS selbst), dann kannst du alles an deiner pfSense filtern.Zu Hause würde ich dann sagen kommt etwas auf Port 80, so soll das bitte an 192.168.1.5 an Port 80 ankommen, wie gehabt.
Nein, das geht nur, wenn du alles 1:1 NAT vom VPS an die pfSense Tunnel-IP schickst, dann kannst du von dort aus nochmal alles quasi pro Port weiter NATten auf andere IPs. Das ist dann aber doppelt geNATtet und muss eigentlich nicht sein. Du kannst das auch direkt auf dem VPS direkt schon korrekt NATten. Da du hier durch welche-auch-immer Tunnel ja eine Route für das/die internen Netze deiner pfSense pushst, kannst du dort auch direkt die internen Adressen als Destination verwenden und wenn das Ziel ordentlich geroutet wurde kann das Paket dann das Ziel über den Tunnel finden. Deine interne pfSense muss das dann nur via Regel erlauben :)
Die Regel beim vps müsste doch sein wan any wird an Ziel Tunnel gesendet (werde da wohl doch nur die HIGH Ports wie bisher annehmen anstatt alles)
Jein. Das ist keine Regel, sondern du müsstest schon die IP NATten - und dazu dann logisch die passende Regel erstellen, klar.
Cheers
-
@jegr Geplant ist ja Wireguard. Nur wenn es über IPv6 laufen soll, muss ich dieses Problem natürlich vorrangig lösen. Da muss der Provider mit ran.
Ich habe mich mal mit TUTs rumgeschlagen.
Ich habe nun einen Tunnel irgendwie laufen, zumindest sind einige Bytes gelaufen wegen der Keepalives. Aktuell natürlich noch über IPv4 wegen oben genannter Problematik.Was habe ich bisher getan.
Ich habe VPS Seitig einen Tunnel erstellt und einen Peer.Bei mir Zuhause auch einen Tunnel und einen Peer.
Gegenseitig bei den Peers die Public Keys. und bei mir zu Hause den Endpoint mit der Server IPv4 versehen.
Bei den Peers habe ich vorerst 192.168.1.0/24 als Netz genannt zum Testen.
Aktuell ist bei mir zu Hause von Wireguard aus auch eine Scheunentor Regel Any/AnyAktuell lässt es sich noch nicht pingen vom VPS aus. Ich muss da noch etwas herumprobieren.
Ich nehme an, ich muss nur vom Wireguard Inbound Regeln erstellen, da ich ja nicht über den VPS herausschicken möchte.Unklar ist mir auch nach wie vor die WAN Seite beim VPS. Ich kann ja jetzt tun_wg0 als Schnittstelle definieren. Muss ich das auch? Vergibt man da statisch dann die 10.0.0.1 beispielsweise?
-
@fnbalu nicht böse gemeint, aber meinst du nicht, dass du dir erst ein wenig Theorie drauf schaffen solltest, bevor du versuchst, so was in der Praxis umzusetzen?
-
@thiasaef Ich lese viel und schaue mir auch Tutorials an.
Natürlich gibt es Leute die machen so etwas beruflich. Ich jedoch nicht.Nun benötige ich so etwas allerdings auch.
Man lernt so auch dabei, so ist das nicht.Ich stelle mich gerade nur etwas doof an, zumal IPv6 eine komplett andere Vorgehensweise erfordert.
Die Kenntnis geht schon weit über Fritzbox hinaus, jedoch ist hier viel viel Neuland
-
@thiasaef das Problem fing halt mit dem Internet an.
Ich hatte zuvor, bzw..habe noch Telekom mit sagenhaften 2 Mbit.
Ich hatte Hybrid, aber der Burner ist auch das nicht.
Telekom liefert sauberen DualStack.
Man hat also wie früher die Ports mittels NAT geforwardet. Open VPN lief u.s.w.Nun hat sich die Möglichkeit mit der deutschen Glasfaser ergeben.
400 Mbit und die liegen auch an (1000 möglich)
Nachteil, es gibt nur IPv6 und die IPv4 ist CG-Nat.Somit komme ich von außen nicht drauf wie bisher.
Nun soll es aber so sein wie bisher und ich suche nach einem Umsetzer dafür.
So ein VPS besitzt ja eine IPv4 und wenn ich mich zu dem VPS verbinde, muss der mir nur alles weiter schicken, was er bekommt.
Soweit die Theorie.Ich lasse aktuell noch nicht die Telekom kündigen, möchte aber natürlich nicht 2 Provider bezahlen.
Aktuell ziehe ich die pfSense sowieso auf neue Hardware um, somit lässt sich das gut testen.Es soll die Telekom weg und die IPv4 soll mir der VPS ersetzen für 2.50€ mtl.
Nun muss ich mich halt damit rumschlagen. Und ich lerne wieder was dazu. Das Problem habe ich natürlich nicht alleine, sondern betrifft immer mehr Leute, deshalb schreibe ich detailliert was ich mache, falls andere das auch mal lesen irgendwann.Mein Tunnel wird als online angezeigt, aber ich habe noch einige Fehler, weshalb das noch nicht so richtig will.
Vorteil Wireguard gegenüber GRE ist die einseitige Verbindung und es reicht eine IPv4.
-
Sodele.
Nun bin ich weiter.Wireguard unterscheidet sich ja grundlegend zwischen Version 2.5.0 und 2.5.2
Was habe ich jetzt.
Die pfSense auf dem VPS hat die Tunnel IP 10.0.0.1 und die zu Hause 10.0.0.2
Die VPS pfSense darf auf 192.168.1.0 zugreifenDie Routen und Gateway sind angelegt. Aktuell alles noch über IPv4.
Ich kann die Firewall zu Hause pingen unter 192.168.1.1. Also muss der Tunnel ja soweit stehen.
Nur wir sieht das Regelwerk aus wenn ich Mappen möchte?
Ich hätte jetzt gesagt es kommt am WAN an und wird an die jeweilige IP weitergeleitet wenn ich NAT nutze wie vorher.Der Versuch war 8022 soll auf 443 der pfSense zu Hause mappen.
Aber meine Versuche endeten immer in @4(1000000103) block drop in log inet all label "Default deny rule IPv4"
Versucht habe ich die 8022 an WAN Adress aufzugreifen und Destination ist direkt die 192.168.1.1 oder aber versucht habe ich auch schon das Tunnelgateway.
Immer hing es an der Default Deny Rule, die ich nicht mal habe -
Ich nochmal.
Das ursprüngliche Problem mit der IPv6 wurde behoben.
Ich hatte von der alten pfSense die Config auf die neue Hardware gebügelt und die Interfaces manuell angepasst.
Irgendetwas scheint bei der Migration schief gelaufen zu sein, weshalb er keine IPv6 bezihen konnte.
Ich habe mit Hilfe des Administrator Forums die pfSense neu aufgesetzt, erstmal nur nackig und dann hat es funktioniert.
Später dann habe ich einige Sachen vereinzelt wieder importiert, nicht aber die Interfaces.Nun läufts
-
@fnbalu said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:
Sodele.
Nun bin ich weiter.Wireguard unterscheidet sich ja grundlegend zwischen Version 2.5.0 und 2.5.2
Was habe ich jetzt.
Die pfSense auf dem VPS hat die Tunnel IP 10.0.0.1 und die zu Hause 10.0.0.2
Die VPS pfSense darf auf 192.168.1.0 zugreifenDie Routen und Gateway sind angelegt. Aktuell alles noch über IPv4.
Ich kann die Firewall zu Hause pingen unter 192.168.1.1. Also muss der Tunnel ja soweit stehen.
Nur wir sieht das Regelwerk aus wenn ich Mappen möchte?
Ich hätte jetzt gesagt es kommt am WAN an und wird an die jeweilige IP weitergeleitet wenn ich NAT nutze wie vorher.Der Versuch war 8022 soll auf 443 der pfSense zu Hause mappen.
Aber meine Versuche endeten immer in @4(1000000103) block drop in log inet all label "Default deny rule IPv4"
Versucht habe ich die 8022 an WAN Adress aufzugreifen und Destination ist direkt die 192.168.1.1 oder aber versucht habe ich auch schon das Tunnelgateway.
Immer hing es an der Default Deny Rule, die ich nicht mal habeDieses Problem ist auch behoben.
Man benötigt 2 Regeln auf dem VPS.
Zum einen die Inbound Nat, die man ja kennt und dann unter outbound Nat (Hybride Erzeugung) eine Regel wo der Port auf den Wireguard Tunnel gelenkt wird.
Es passt wohl die Rückroute sonst nicht
