pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6

FNBalu

@jegr das klingt interessant. Ja, ich kann zum einen aus geschätzt 20 verschiedenen Images wählen, habe aber auch die Möglichkeit ein Image via FTP hochzuladen und davon zu booten.
Sprich die Installation müsste klappen.

Eine Art Site2Site VPN wo meine private pfSense der Client ist und aktiv die Verbindung aufbaut, umgeht ja außerdem auch die Gefahr, sollte sich doch mal, warum auch immer die private IP ändern.
So baue ich die Verbindung zu einer statischen IP auf. GRE wäre da ja anders.

Ich kenne es privat halt nur mit 2 NICs mindestens.
Bisher habe ich mit meinem grundierten Fundwissen und diversen Foren auch alles immer irgendwie hinbekommen. Ich bin weiß gott kein Profi, eher meilenweit davon entfernt, sehe aber was ich so machen kann.
Nur wie richtet man das dann quasi ein, wenn sinngemäß die 192.168.1.1 ja so nicht ansprechbar ist? Über Console?

Bisher nutze ich noch die alte pfSense und die neue im Test. Ich möchte auch die Telekom Leitung über kurz oder lang abstoßen. Doppelte Kosten und so.
Bisher verbinde ich mich mit sagenhaften 2 Mbit / 1 Mbit in das Heimnetz, natürlich mit IPv4 und genau das möchte ich irgendwie wieder realisieren und muss laufen bevor ich die Telekom mit Dualstack abstoße. Deshalb ein 2,50€ vServer

FNBalu

Ich habe mich eben mal an pfSense versucht.
Ich habe es installiert, habe an WAN die IPv4 anliegen und kam direkt von extern drauf über eben diese IP.
Step1 das Adminpasswort geändert, dann konnte ich spielen.

Im Servercontrolpanel steht von der IPv6 Geschichte
XXXX:XXXX:XX:XX8::/64 wurde mir zugewiesen (extra X)
Nun habe ich statisch erstmal bei WAN XXXX:XXXX:XX:XX8:: im 128er Subnet gesetzt, das dürfte ja soweit passen, weil die erste IP

Nun könnte ich mir ein virtuelles Interface erstellen und diesem die nächste IP geben, verstehe ich das richtig???

JeGr

@fnbalu said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:

So baue ich die Verbindung zu einer statischen IP auf. GRE wäre da ja anders.

GRE kann vor allem nur IPs und keinen Fallback/Failover :)

Nur wie richtet man das dann quasi ein, wenn sinngemäß die 192.168.1.1 ja so nicht ansprechbar ist? Über Console?

Normalerweise per Console dann das WAN aufmachen, damit man auf die UI kommt, dann seine IP hinterlegen und die WAN Freigabe auf <nurmeineIP> als Source hinterlegen. DynDNS für IP4 oder IP6 hilft dann dass das immer korrekt ist.

Dann einfach ganz normal einrichten :)

WAN aufmachen via Console ist recht einfach:

pfSense Shell
Punkt 12) PHP shell + pfSense tools
playback enableallowallwan

Zack wird eine allow any WAN rule angelegt.

Nun habe ich statisch erstmal bei WAN XXXX:XXXX:XX:XX8:: im 128er Subnet gesetzt, das dürfte ja soweit passen, weil die erste IP

Nee, 128er ist ja wie /32 bei IP4 eine einzelne IP. Du bekommst ja nen /64 also wäre /64 auch korrekt. Dein Gateway ist aber wahrscheinlich nicht im gleichen Netz oder ein fe80::1 oder?

Aber wenns nu erstmal funktioniert, dann kann man zumindest weiter mit dem Tunnel machen. OVPN S2S Tunnel basteln, auf beiden Seiten das Interface dann als OPTx zuweisen und benennen und aktivieren und dann hast du auf der VPS Seite sein 2. Interface.

Dann erst würde ich überhaupt mit irgendwelchen Public IP6 o.ä. rumspielen :)

FNBalu

@jegr said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:

GRE kann vor allem nur IPs und keinen Fallback/Failover :)

Da hätte man dann dementsprechend auch immer die IP checken müssen und den Tunnel ändern. Das sollte einfacher gehen.

Normalerweise per Console dann das WAN aufmachen, damit man auf die UI kommt, dann seine IP hinterlegen und die WAN Freigabe auf <nurmeineIP> als Source hinterlegen. DynDNS für IP4 oder IP6 hilft dann dass das immer korrekt ist.

Dann einfach ganz normal einrichten :)

WAN aufmachen via Console ist recht einfach:

pfSense Shell

Punkt 12) PHP shell + pfSense tools

playback enableallowallwan

Zack wird eine allow any WAN rule angelegt.

Das schaue ich mir nachher mal an.
Thema auf meine WAN IP begrenzen. Ich habe CG-Nat, theoretisch würde ja selbst diese IPv4 dafür ausreichen um den Benutzerkreis stark zu minimieren. IPv6 nutze ich halt nicht und da kein Client das nutzt, zeigt mir www.wieistmeineip.de auch keine IPv6 Nutzung an.
Jedoch sehe ich die öffentliche IPv4 nicht direkt, nur eine 100er

Nee, 128er ist ja wie /32 bei IP4 eine einzelne IP. Du bekommst ja nen /64 also wäre /64 auch korrekt. Dein Gateway ist aber wahrscheinlich nicht im gleichen Netz oder ein fe80::1 oder?

Ganz genau, fe80::1 ist mein Gateway. IPv6 ist noch Neuland für mich. Wenn ich da /64 angebe, bleibt doch gar nichts mehr übrig für andere Geschichten oder?
Ist das nicht analog IPv4, wenn ich da ein 16er Subnet angebe und mir damit 254 x24er Subnets kaputt mache??

Ich habe mir mal errechnen lassen, was ich da habe.
18.446.744.073.709.551.616 IPs bedeutet das 64er Subnet. Das sind ja mehr als Manhatten Fenster hat.
Unfassbar.

Da sollte man doch dann wenigstens auf ein 116er Subnet einstellen, was den letzten 4er Block dann noch unterscheidet und 4096 Adressen bedeutet, nehme ich an.
Oder muss ich alle am WAN anliegen haben???

Aber wenns nu erstmal funktioniert, dann kann man zumindest weiter mit dem Tunnel machen. OVPN S2S Tunnel basteln, auf beiden Seiten das Interface dann als OPTx zuweisen und benennen und aktivieren und dann hast du auf der VPS Seite sein 2. Interface.

Dann erst würde ich überhaupt mit irgendwelchen Public IP6 o.ä. rumspielen :)

Meinst nicht noch mal sauber pfSense neu aufsetzen und direkt die richtigen IPs zuweisen?

Der OpenVPN Tunnel muss dann ja über IPv6 gehen. Da dann die WAN IP des VPS angeben und fertig? Geht meine private pfSense dann automatisch über IPv6 raus??

Was ich mich noch frage ist mein privates VPN. Bisher nutze ich OpenVPN nur alleine und habe mir den Zugriff auf all meine internen Subnetze gegeben. Das muss ich dann natürlich überdenken.
Auch glaube ich, dass ich mich dann wohl kaum noch an meiner pfSense darüber anmelde, sondern auch beim VPS, oder nicht? Oder VPN über VPN?
Oder gar Wireguard nutzen für meinen Zweck??

JeGr

@fnbalu said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:

Jedoch sehe ich die öffentliche IPv4 nicht direkt, nur eine 100er

Du nicht, aber wenn du auf eine Seite gehst, die dir die IP4 anzeigt, mit der du ankommst, wird das irgendeine Public IP sein und garantiert KEINE 100.x Adresse :) Das ist dann auch die Adresse mit der du beim VPS ankommen würdest, daher DynDNS.

@fnbalu said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:

Ganz genau, fe80::1 ist mein Gateway. IPv6 ist noch Neuland für mich. Wenn ich da /64 angebe, bleibt doch gar nichts mehr übrig für andere Geschichten oder?

Nein, das ist Unfug ;) Du definierst mit der Prefix Maske ja wie bei einer IP das Netz in der die IP gültig ist. Und du hast ein /64er bekommen, keine einzelne /128 IP6. Und nein das ist nich adäquat zu IP4 /16, sondern zu /24. /64 ist die kleinste IPv6 Prefixgröße die man als Provider ausgeben soll, da im Gegensatz zu IP4 bei IP6 wesentlich mehr Adressen in Gebrauch sind und sein können. Daher werden wesentlich mehr Adressen gebraucht. Und auch wen das so viele IPs sind, ist das eine Milchmädchenrechnung ;) da man bei IP6 möglichst viel automatisieren/automatisch machen möchte und nicht unbedingt statisch ausrolt. Daher hat die einzelne IP6 wesentlich weniger Relevanz.

Da sollte man doch dann wenigstens auf ein 116er Subnet einstellen, was den letzten 4er Block dann noch unterscheidet und 4096 Adressen bedeutet, nehme ich an.
Oder muss ich alle am WAN anliegen haben???

Das entscheidest gar nicht du, sondern der ISP der dir das /64 zur Verfügung stellt und wie oben gesagt wird das bei VPS meist per MAC oder sonstwie auf die VM aufgeschaltet, so dass du da gar keine andere Wahl hast, als den Adressraum auf dem WAN zu haben. Viele Provider geben dir aber gern und problemlos ein zweites IPv6 Netz und können das dann routen - und dann kannst du damit machen was du willst :)

auf ein /116 er Netz...

Nein. Theoretisch kann man das machen, aber praktisch funktioniert IPv6 nur/am Besten mit nichts kleinerem als IPv6 Prefixen da alles <64bit der Addressraum ist und alles >64bit der Prefixraum. Wenn du anfängst den Adressraum manuell kleinzuschneiden - was man machen kann aber nicht soll (RFCs etc) - funktionieren diverse Dienste nicht mehr. Bspw. basiert SLAAC für die automatische IP6 Vergabe darauf, dass auf dem Interface ein /64er Prefix anliegt und nichts Kleineres, da sonst der Algorithmus der Berechnung der IP6 fehlschlägt. Usw. usw.

Es hat schon Gründe, dass das RIPE vorschreibt/vorgibt, dass man keine Netze/Prefixe kleiner als /64 vergeben soll. Und da es mit IP6 privacy extensions und IP rotation sein kann, dass alleine ein Client am Tag locker ein paar dutzend IP6s verbrät kann man die Rechnung mit den "aber das sind XY IPs" so im Vergleich mit IP4s nicht bringen :)

Zudem gibt es so viel Prefix Space, dass wir kein Problem hätten, jedem Client ein /64er zuzuweisen der eines haben wollen würde. Und hätten trotzdem noch genug Prefix Space. Man kann da einfach nicht die gleiche Denke wie von IP4 anwenden, das ist ein komplett neuer und teils anders funktionierendes Protokoll und IP Stack. Andere Regeln :)

@fnbalu said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:

Meinst nicht noch mal sauber pfSense neu aufsetzen und direkt die richtigen IPs zuweisen?

Kann man machen :)

@fnbalu said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:

Der OpenVPN Tunnel muss dann ja über IPv6 gehen. Da dann die WAN IP des VPS angeben und fertig? Geht meine private pfSense dann automatisch über IPv6 raus??

Muss nicht, macht aber Sinn - weniger Overhead!
Und klar, wenn du als Server IP eine IP6 einträgst, kann der Client sich natürlich nur per IP6 verbinden ;)

@fnbalu said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:

Auch glaube ich, dass ich mich dann wohl kaum noch an meiner pfSense darüber anmelde, sondern auch beim VPS, oder nicht? Oder VPN über VPN?
Oder gar Wireguard nutzen für meinen Zweck??

Wenn deine private pfSense keine IP4 hat, dann kannst du dich trotzdem natürlich via IP6 direkt einwählen wenn du "woauchimmer" ordentliches IP6 hast. Oder im Mobilnetz, da wird IP6 ja auch inzwischen groß ausgerollt und zumindest bei den meisten großen ISPs unterstützt (auch wenn es meist am Endgerät liegt, dass es nicht eingeschaltet ist). Ob du da OVPN oder WG nutzt ist dir überlassen.

Und wenn du die Public IP4 quasi durchroutest durch den VPN Tunnel kannst du dich natürlich direkt bei deiner Sense anmelden. Aber ja du könntest die Einwahl auch auf dem VPS machen und dann einfach weiterrouten. Möglichkeiten gibts einige :)

FNBalu

@jegr Mahlzeit,

gut, hast recht, das Thema IPv6 bedarf ein Umdenken.
LAN1 würde sich ja auch über WAN die IP besorgen.
Quasi vergibt die pfSense kaum noch selbst IPs, sondern vergibt diese im Auftrag.

Nur zum Thema IP zum Login.
Ich hatte jetzt testweise erstmal einen HighPort genommen, da man ja nicht die 443 offen haben muss, was jeder Portscanner erkennt.
Wo ich gestern drauf wollte, ging gar nichts mehr und in der console überschlugen sich die Drops, also hat den schon jemand gescannt gehabt.

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?

Ich kann die ddns Geschichte über mein Webhosting ganz komfortabel machen, das geht wohl.
Ich könnte sogar die IP dahinter ganz entfernen, dann kommt niemand drauf.
Nur muss die pfSense das DDNS Update dann ja quasi erkennen. Da muss ich mal schauen, da sie sich ja nicht selbst einwählt oder es halt genattet ist.

JeGr

@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.

FNBalu

@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

JeGr

@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. :)

FNBalu

@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.

JeGr

@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

FNBalu

@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/Any

Aktuell 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?

thiasaef

@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?

FNBalu

@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

FNBalu

@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.

FNBalu

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 zugreifen

Die 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

FNBalu

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

@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 zugreifen

Die 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

Dieses 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