pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6

FNBalu

Hallo zusammen,

ich habe seit 3 Wochen einen Anschluss der Deutschen Glasfaser.
Im Zuge der pfSense Hardwareerneuerung habe ich jetzt erst einmal eine zweite pfSense zum Testen.

Deutsche Glasfaser hat CG-Nat, weshalb ich die IPv6 am WAN anliegen haben möchte um mir darüber Portforwards zu ermöglichen.

Nun habe ich z.B. nach der Anleitung von https://beechy.de/deutsche-glasfaser-ipv6-vs-pfsense/ auf DHCP6 alles versucht, aber es kommt keine IP.
Auch nach Stunden nicht und auch nicht nach mehrstündigem Abschalten.
Ich bekomme nur eine IP mit 100 beginnend, die natürlich nicht für den Fernzugriff taugt.

Hänge ich eine Fritzbox an den Anschluss (Anschluss steht auf kundeneigener Router) so bekommt die eine IPv6 und ein Präfix zugewiesen.
Was läuft bei der Fritzbox also anders als bei der pfSense?

Wie gesagt es ist vertraglich kein Router mitbestellt, es sollte als beides klappen.

JeGr

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

Ich bekomme nur eine IP mit 100 beginnend, die natürlich nicht für den Fernzugriff taugt.

Das wird sich auch nicht ändern, das ist eine CGNAT Adresse und DG benutzt CGNAT - du schreibst es ja selbst! DS-lite bekommt keine richtige Public Adresse sondern im Fall von CGNAT eine 100.x.y.z Adresse aus dem CGNAT Family Block die intern über deren Gateway dann nach außen umgewandelt wird.

Hänge ich eine Fritzbox an den Anschluss (Anschluss steht auf kundeneigener Router) so bekommt die eine IPv6 und ein Präfix zugewiesen.

Was läuft bei der Fritzbox also anders als bei der pfSense?

Dann musst du das IPv6 der Box korrekt konfigurieren. M.W. hatten wir hier schon mehrfach Kollegen die auch DG nutzen, die das IPv6 ganz gut hingekriegt haben. Müsstest du mal über die Suche schauen, gabs aber schon ein paar Mal. Ansonsten vielleicht einfach mal nachfragen, was genau DG gern für den Uplink via IP6 an Setting haben will. Ich kann mich wage erinnern, dass die da doch gerade am Umbauen waren und das früher über nen anderen Weg gehandhabt haben als jetzt, aber als nicht-Kunde bin ich da nicht so tief drin.

Cheers

polka44

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

https://beechy.de/deutsche-glasfaser-ipv6-vs-pfsense/

Ich habe vor knapp einem Jahr genau mit der Anleitung meine erste pfSense am DG Anschluss eingerichtet und eben erst eine weitere Installation damit vorgenommen.
Ich hatte als einzigen Stolperstein, dass ich mal die pfSense komplett hart durchstarten musste, damit sie per DHCPv6 korrekt ihre Adresse bezieht.
Und generell ist der DG DHCP sehr langsam, das merkt man immer, wenn man mal die pfSense durchstartet.
Kannst du mal einen Screenshot von deiner "Status/Interfaces" Seite schicken? Und hast du auch die empfohlenen LAN-Settings genutzt?
VG

FNBalu

@polka44 mahlzeit.

In der Zwischenzeit läuft es mit genau des selben Einstellungen.
Testweise habe ich mir über 2 Switches ein VLAN erstellt, dort rein WAN der deutschen Glasfaser geschickt und die pfSense neben mir im Büro hingestellt.
Die FritzBox hat in der Konstellation eine IPv6 bekommen, die pfSense nicht. Es kann also nicht alles falsch gewesen sein.

Als ich dann dachte ich versuche die Fehlerquelle mal auszuschließen und die pfSense in den Keller gebracht habe, wo sie ohne Umwege direkt angeschlossen ist am WAN, lief es.
Das verstehe mal einer.

Nun tue ich mich gerade etwas schwer mit einem Tunnelaufbau.
WAN hat ja jetzt eine eigene IPv6 und ich möchte weiterhin meine IPv4 Portforwards behalten.
Ich versuche mittels vServer der IPv4 und IPv6 hat etwas zu realisieren.
GRE scheitere ich gerade.
Hat so etwas, egal erstmal welches Protokoll jemand laufen?

Portmapper quasi.

JeGr

@fnbalu Ne bitte nix Portmapper. Portmapper ist ein Dienst und tut was anderes. :)

Aber ja, sowas kann man sich mit nem VPN recht gut bauen. OpenVPN (oder neuerdings Wireguard) draufpacken, forwarding etc. aktivieren (oder direkt nen VPS mit ner Sense ausstatten) und dann via v6 nen Tunnel bauen, über den v6 und v4 als Tunnelnetz laufen. Dann kann man die IP4 des VPS einfach durchreichen bzw. 1:1 NATten.

FNBalu

@jegr So etwas schwebt mir vor. Ich habe bei netcup einen kleinen VPS.
Der hat eine IPv4 und eine IPv6. Für meinen Geschmack benötigt pfSense doch aber 2 NICs, oder?
Die Idee hatte ich aber grundsätzlich auch schon.

Ich möchte quasi alles was über die IPv4 des VPS angesprochen wird direkt bei mir zu Hause am WAN Port über IPv6 anliegen haben und dann soll es intern mit IPv4 weiter gehen. Ich möchte hier kein IPv6 aufziehen, zumal es bei Arduino sowieso schlecht damit aussieht

JeGr

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

Der hat eine IPv4 und eine IPv6. Für meinen Geschmack benötigt pfSense doch aber 2 NICs, oder?

Nö nicht zwingend. Zudem bekommt sie automatisch das zweite, wenn du das OVPN bzw. das WG als Interface zuweist - schwupps hast du 2 Interfaces. WAN und das virtuelle VPN Interface (als LAN).

Ich kenne die Netcup VPS nicht, ob man da problemlos ne pfSense/FreeBSD hochziehen kann. Bei meinem 2€ Hetzner Cloud VPS gehts daher keine Garantie :) Aber ansonsten muss man eben mit dem Linux o.ä. Container OS was da läuft Vorlieb nehmen und ggf. sich ne Anleitung anschauen, wie das dort sinnvoll aufgesetzt wird mit OVPN oder WG - das hängt dann immer sehr vom OS ab (weil man u.a. IP Forwarding braucht fürs Routing, nen Filter wie IPtables oder Netfilter o.ä. etc.).

Aber möglich ist das. :)

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?