88
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Mahlzeit,
ich bin nach wie vor dabei, eine Lösung zu erarbeiten um meine Portforwardings, welche bei der Telekom durch die IPv4 möglich waren auf meinen neu dazugekommenen CG-Nat Anschluss der Deutschen Glasfaser umzusetzen.
Da die Telekom leide rnur 2 Mbit anbietet, war das leider keine Alternative.
Ich habe mir bisher den Thread "Feste IP via GRE" und selbiges über Wireguard angesehen, werde da aber noch nicht so ganz schlau draus.
Ich möchte nicht sämtlichen Traffic eines Gerätes über eines Gerätes über den Tunnel laufen lassen.
So sieht es bisher aus.
Ich habe gerade mal wieder eine zweite pfSense auf dem VPS laufen.
Der Wireguard Tunnel steht, die Gateways sind eingerichtet.
Ich kann von der VPS pfSense die 192.168.1.45 pingen.
Der Traffic läuft also dann über den Tunnel. Nach meinem Verständnis funktioniert der VPN Teil.
Nun möchte ich vereinzelte Ports wie bisher weiterleiten.
In dem Test hängt an der 192.168.1.45 ein kleiner Shelly, der Port 80 offen hat.
Bisher konnte ich bei der Telekom-Leitung via NAT festlegen, dass der Traffic über WAN ankommt und mir Port 6666 auf Port 80 umgesetzt werden soll.
Dementsprechend konnte man von überall aus im Browser mittels DDNS oder IP:6666 direkt auf den Webserver zugreifen.
Nun habe ich mangels der mir zugeteilten IPv4 den VPS am laufen und ich möchte eigentlich nur das selbe wie früher erreichen.
IPdesVPS:6666, der Traffic soll dann, da 192.168.1.45 über den Tunnel laufen und auf dem Endgerät den Webserver zur Verfügung stellen.
Wie gesagt der Tunnel steht und aktuell ist beim Wireguard auch eine Scheunentor Regel.
Was für Regeln bedarf es um den Traffic einzuschleusen?
ich bin nach wie vor dabei, eine Lösung zu erarbeiten um meine Portforwardings, welche bei der Telekom durch die IPv4 möglich waren auf meinen neu dazugekommenen CG-Nat Anschluss der Deutschen Glasfaser umzusetzen.
Da die Telekom leide rnur 2 Mbit anbietet, war das leider keine Alternative.
Ich habe mir bisher den Thread "Feste IP via GRE" und selbiges über Wireguard angesehen, werde da aber noch nicht so ganz schlau draus.
Ich möchte nicht sämtlichen Traffic eines Gerätes über eines Gerätes über den Tunnel laufen lassen.
So sieht es bisher aus.
Ich habe gerade mal wieder eine zweite pfSense auf dem VPS laufen.
Der Wireguard Tunnel steht, die Gateways sind eingerichtet.
Ich kann von der VPS pfSense die 192.168.1.45 pingen.
Der Traffic läuft also dann über den Tunnel. Nach meinem Verständnis funktioniert der VPN Teil.
Nun möchte ich vereinzelte Ports wie bisher weiterleiten.
In dem Test hängt an der 192.168.1.45 ein kleiner Shelly, der Port 80 offen hat.
Bisher konnte ich bei der Telekom-Leitung via NAT festlegen, dass der Traffic über WAN ankommt und mir Port 6666 auf Port 80 umgesetzt werden soll.
Dementsprechend konnte man von überall aus im Browser mittels DDNS oder IP:6666 direkt auf den Webserver zugreifen.
Nun habe ich mangels der mir zugeteilten IPv4 den VPS am laufen und ich möchte eigentlich nur das selbe wie früher erreichen.
IPdesVPS:6666, der Traffic soll dann, da 192.168.1.45 über den Tunnel laufen und auf dem Endgerät den Webserver zur Verfügung stellen.
Wie gesagt der Tunnel steht und aktuell ist beim Wireguard auch eine Scheunentor Regel.
Was für Regeln bedarf es um den Traffic einzuschleusen?
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: 1161214871
Url: https://administrator.de/contentid/1161214871
Ausgedruckt am: 02.11.2024 um 22:11 Uhr
88 Kommentare
Neuester Kommentar
Es bedarf lediglich einer Port Forwarding Regel unter Firewall - NAT - Port Forward
Int: WAN, Protocol TCP, Source Addr.: *, Source Port: *, Destination: WAN Address, Port: 6666, Redirect Traget IP: Single Host IP:192.168.1.45, Redirect Traget Port: 80, Add associated Filter Rule
Der Zugang mit TCP 6666 auf die WAN Port IP von Any sollte erlaubt sein wird aber sofern du das automatische Ruleset Erstellen nicht deaktiviert hast im Security Setup automatisch passieren.
Int: WAN, Protocol TCP, Source Addr.: *, Source Port: *, Destination: WAN Address, Port: 6666, Redirect Traget IP: Single Host IP:192.168.1.45, Redirect Traget Port: 80, Add associated Filter Rule
Der Zugang mit TCP 6666 auf die WAN Port IP von Any sollte erlaubt sein wird aber sofern du das automatische Ruleset Erstellen nicht deaktiviert hast im Security Setup automatisch passieren.
Ich habe das jetzt mal umgesetzt.
Dir VPS-PfSense scheint es nicht zu blocken, jedoch geht es auch nicht.
Die 6666 habe ich mal geändert, das war auch ein fiktiver Port. Normal gingen da immer High Ports, das müsste ich dann mal schauen.
Auf der Heim-pfSense kommt doch der Traffic dann nicht über Wan, sondern über den Wireguard Tunnel, oder?
Es gibt einmal Wireguard, welches eine Any/Any hat und dann gibt es durch das hinzugefügte Interface des Tunnels ja noch jewils die 10.0.0.1 bzw 2er Schnittstellen.
Brauchen die auch Beidseitig eine Regel?
Dir VPS-PfSense scheint es nicht zu blocken, jedoch geht es auch nicht.
Die 6666 habe ich mal geändert, das war auch ein fiktiver Port. Normal gingen da immer High Ports, das müsste ich dann mal schauen.
Auf der Heim-pfSense kommt doch der Traffic dann nicht über Wan, sondern über den Wireguard Tunnel, oder?
Es gibt einmal Wireguard, welches eine Any/Any hat und dann gibt es durch das hinzugefügte Interface des Tunnels ja noch jewils die 10.0.0.1 bzw 2er Schnittstellen.
Brauchen die auch Beidseitig eine Regel?
Auf der Heim-pfSense kommt doch der Traffic dann nicht über Wan, sondern über den Wireguard Tunnel, oder?
Richtig !Die neue Ziel Adresse ist nach dem Port Forwarding ja nicht mehr die WAN IP der VPS pfSense sondern die 192.168.1.45 die du ja als Target IP angibst. Die pfSense "sieht" dann in ihre Routing Tabelle über welches Interface sie gehen muss um das 192.168.1.0er IP Netz zu erreichen und dort sollte das wg0 Tunnel Interface des Wireguard stehen zum Ziel.
Das kannst du dir auch selber ansehen wenn du dir in der pfSense unter "Diagnostics" einmal die Routing Tabelle ansiehst.
Fürs Troubleshooting hilfreich ist auch mal über das gleiche Menü die Packet Capture Funktion zu aktivieren und das WAN Interface zu belauschen. Den .pcap File siehst du dir dann mit dem Wireshark an. Dort solltest du dann die eingehenden TCP 6666 Frames sehen und wenn du das gleiche auf dem wg0 Interface machst solltest du die weiter gerouteten TCP 80 Frames zum Shelly sehen.
Brauchen die auch Beidseitig eine Regel?
Du hast doch geschrieben das die beide einen any zu any Regel haben. Damit lassen sie ja dann alles durch.
Hast du auf der VPS pfSense auf dem
WAN-Interface eine passende Firewall-Regel erstellt?
WAN-Interface eine passende Firewall-Regel erstellt?
Das sollte die Port Forwarding Regel, sofern automatische Ruleset nicht deaktiviert wurde, automatisch erledigen.
In jedem Falle sollten auf dem WAN Port 2 Regeln zu sehen sein. Screenshot wäre sicher hilfreich.
In jedem Falle sollten auf dem WAN Port 2 Regeln zu sehen sein. Screenshot wäre sicher hilfreich.
Sodele, ich setze mal Bilder rein, die sagen mehr als tausend Worte.
Ja, es gibt sogar 3 Regeln. Ich habe den Admin Zugang über einen Alias beschränkt.
Man muss ja auch dem wg Interface eine Zuordnung verpassen, die sieht so aus.
Ist die 32 da richtig? oder 24 wegen Netz?
Die Wireguard Scheunentor Regel (vorerst bis es läuft)
Das Tunnel Interface hat nichts. Ist das richtig?
Die Routen. Die 10.0.0.1 ist die IP der eigenen Seite. Oder bedarf es da der Gegenseiten?
VPS-Seitig die Peers. In dem Fall das 192.168.1.0 Netz vorerst
Und natürlich die NAT Geschichte, die sich automatisch erstellte
Das ist jetzt alles von der VPS Seite.
Bei mir zu Hause natürlich analog dazu.
Ja, es gibt sogar 3 Regeln. Ich habe den Admin Zugang über einen Alias beschränkt.
Man muss ja auch dem wg Interface eine Zuordnung verpassen, die sieht so aus.
Ist die 32 da richtig? oder 24 wegen Netz?
Die Wireguard Scheunentor Regel (vorerst bis es läuft)
Das Tunnel Interface hat nichts. Ist das richtig?
Die Routen. Die 10.0.0.1 ist die IP der eigenen Seite. Oder bedarf es da der Gegenseiten?
VPS-Seitig die Peers. In dem Fall das 192.168.1.0 Netz vorerst
Und natürlich die NAT Geschichte, die sich automatisch erstellte
Das ist jetzt alles von der VPS Seite.
Bei mir zu Hause natürlich analog dazu.
Die Maske der Allowed IPs im WG Tunnel ist falsch. Die sollte auf /32 stehen für die jeweils gegenüberliegenden Tunnel Interfaces. Siehe Wireguard Anleitung hier. Richtig lesen und umsetzen hilft also wirklich ! 
Für den WebGUI Zugriff via WG Tunnel benötigst du keine Regel auf dem WAN Port. Das wäre ja auch unlogisch, denn am WAN Port kommt der verschlüsselte WG Tunnel an und das WAN Interface kann niemals in den verschlüsselten Tunnel sehen und dort irgendwelche Regelwerke auf die im VPN Tunnel transportverschlüsselten IP Pakete ausführen. Das wäre Unsinn und würde ein VPN ja ad absurdum führen wenn das ginge. Das WAN Interface "sieht" vom VPN ja nur verschlüsselten Traffic.
Relevant ist dafür immer nur das Tunnel Interface, denn nur dort kommen ja die unverschlüsselten VPN Daten raus und das steht bei dir eh auf any any, erlaubt also erstmal alles.
Da musst du wohl noch etwas Finetuning am Setup machen...
Für den WebGUI Zugriff via WG Tunnel benötigst du keine Regel auf dem WAN Port. Das wäre ja auch unlogisch, denn am WAN Port kommt der verschlüsselte WG Tunnel an und das WAN Interface kann niemals in den verschlüsselten Tunnel sehen und dort irgendwelche Regelwerke auf die im VPN Tunnel transportverschlüsselten IP Pakete ausführen. Das wäre Unsinn und würde ein VPN ja ad absurdum führen wenn das ginge. Das WAN Interface "sieht" vom VPN ja nur verschlüsselten Traffic.
Relevant ist dafür immer nur das Tunnel Interface, denn nur dort kommen ja die unverschlüsselten VPN Daten raus und das steht bei dir eh auf any any, erlaubt also erstmal alles.
Da musst du wohl noch etwas Finetuning am Setup machen...
Erstellt hatte ich den Tunnel besch einem anderen Video Tutorial, dass muss ich gestehen. Video
Die extra Regel auf WAN ist auch nicht für den Tunnel gedacht, dass was Du sagst leuchtet ein. Die Regel ist für Portscanner. Ich habe es auf 443 gelassen und wenn jemand die statische IP hat, so kommt er nicht an das GUI. Sprich ich benutze das GUI ohne VPN
Die extra Regel auf WAN ist auch nicht für den Tunnel gedacht, dass was Du sagst leuchtet ein. Die Regel ist für Portscanner. Ich habe es auf 443 gelassen und wenn jemand die statische IP hat, so kommt er nicht an das GUI. Sprich ich benutze das GUI ohne VPN
Das Konfig GUI sollte man aus guten Gründen generell niemals im Internet freigeben egal welche Router oder Firewall.
Also bei Allowed IPs jeweils nur die andere gegenüberliegende IP und auf diese mit der 32 begrenzen.
Bei der VPS dementsprechend die 2 und umgekehrt.
Und dass er den Bereich 192.168.1.0 erreicht erfährt er dann über die Static Routes?, dieses Bild habe ich gestern vergessen
Edit: Ich habe das jetzt so wie bei Peers verstanden:
Jedoch geht dann kein Ping mehr
Kann es sein, dass es gravierende Unterschiede zwischen pfSense 2.5.0 und 2.5.2 was Wireguard angeht, gibt?
Bei der VPS dementsprechend die 2 und umgekehrt.
Und dass er den Bereich 192.168.1.0 erreicht erfährt er dann über die Static Routes?, dieses Bild habe ich gestern vergessen
Edit: Ich habe das jetzt so wie bei Peers verstanden:
Jedoch geht dann kein Ping mehr
Kann es sein, dass es gravierende Unterschiede zwischen pfSense 2.5.0 und 2.5.2 was Wireguard angeht, gibt?
Und dass er den Bereich 192.168.1.0 erreicht erfährt er dann über die Static Routes?
Nein, die Routen werden bei WireGuard automatisch übermittelt. Statische Routen sind nicht erforderlich. Nennt sich dort Cryptokey_Routing.Kannst du bei aktivem Tunnel auch in der Routung Tabelle und Diagnostics sehen.
Sind diese hinderlich? Das steht ja echt im krassen Widerspruch mit der Videoanleitung
Statische Routen haben, wie du als Admin Profi ja selber weisst, immer die höhere Priorität. Sie "töten" damit also dynamisch gelernte Routen. Passt man hier nicht auf killt man damit also seine IP Connectivity im VPN. Wenn das Protokoll also eine dynmaische Route Propagation macht sollte man dort besser nicht mit eigenen Routen sowas "verschlimmbessern"
Besser also immer sich an die Original Anleitung des WG Entwicklers halten. 😉
Besser also immer sich an die Original Anleitung des WG Entwicklers halten. 😉
Wenn ich mal Admin Profi wäre...
Also ich habe jetzt die Routen entfernt. Auch habe ich beidseitig die pfSenses neu gestartet und siehe da es geht wieder kein Ping durch.
Ich wiederhole meine Frage noch mal. Kann es sein, dass das in 2.5.2 komplett anders abläuft?
Es sieht auch alles komplett anders aufgebaut aus!
Edit: WireGuard has been removed from the base system in releases after pfSense Plus 21.02-p1 and pfSense CE 2.5.0, when it was removed from FreeBSD.
If upgrading from a version that has WireGuard active, the upgrade will abort until all WireGuard tunnels are removed. For more details, see the Release Notes
WireGuard is available as an experimental add-on package on pfSense Plus 21.05, pfSense CE 2.5.2, and later versions. The settings for the WireGuard add-on package are not compatible with the older base system configuration.
Das ist von der Netgate Seite.
Da muss ich wohl noch etwas weiter suchen.
There is an issue in this release with port forwarding on pfSense CE software installations with multiple WANs, see #11805 for details.
hmpf
Also ich habe jetzt die Routen entfernt. Auch habe ich beidseitig die pfSenses neu gestartet und siehe da es geht wieder kein Ping durch.
Ich wiederhole meine Frage noch mal. Kann es sein, dass das in 2.5.2 komplett anders abläuft?
Es sieht auch alles komplett anders aufgebaut aus!
Edit: WireGuard has been removed from the base system in releases after pfSense Plus 21.02-p1 and pfSense CE 2.5.0, when it was removed from FreeBSD.
If upgrading from a version that has WireGuard active, the upgrade will abort until all WireGuard tunnels are removed. For more details, see the Release Notes
WireGuard is available as an experimental add-on package on pfSense Plus 21.05, pfSense CE 2.5.2, and later versions. The settings for the WireGuard add-on package are not compatible with the older base system configuration.
Das ist von der Netgate Seite.
Da muss ich wohl noch etwas weiter suchen.
There is an issue in this release with port forwarding on pfSense CE software installations with multiple WANs, see #11805 for details.
hmpf
Das ist gut möglich, denn der offizielle Support ist in der 2.5.2 Version ja entfernt worden und kann derzeit nur über ein Beta Package extern nachinstalliert werden.
Ggf. als Alternative dann OPNsense nehmen, denn dort ist es weiterhin nativ enthalten. OPNsense nutzt einen aktuelleren BSD Kernel und WG Kernel Support.
Ggf. als Alternative dann OPNsense nehmen, denn dort ist es weiterhin nativ enthalten. OPNsense nutzt einen aktuelleren BSD Kernel und WG Kernel Support.
Das ist natürlich ein richtiger Aufwand, da alles neu aufgebaut werden muss wenn man auf OPNSense umstellt
Die Frage ist, was da in Zukunft besser ist.
Ich wäre ja auch bereit etwas zu bezahlen, aber es muss im Rahmen bleiben.
Da gab es ja vor einiger Zeit schon mal Diskussionen drüber und viele wanderten ab.
Ich selber habe mich an pfSense gewöhnt.
OPNsense ist natürlich schon anders vom Menü, aber natürlich ist das auch lernbar.
Wireguard kann man nachinstallieren und es sieht jetzt halt ganz anders aus.
Man hat nun auch Interfaces und kann Regeln erstellen u.s.w..
Man muss aber auch die Routen selbst erstellen.
Ich kann ja die entfernte 45er IP pingen, aber die Weiterleitung geht nicht.
Kann es vielleicht der Fehler sein der genannt wurde?
Die Frage ist, was da in Zukunft besser ist.
Ich wäre ja auch bereit etwas zu bezahlen, aber es muss im Rahmen bleiben.
Da gab es ja vor einiger Zeit schon mal Diskussionen drüber und viele wanderten ab.
Ich selber habe mich an pfSense gewöhnt.
OPNsense ist natürlich schon anders vom Menü, aber natürlich ist das auch lernbar.
Wireguard kann man nachinstallieren und es sieht jetzt halt ganz anders aus.
Man hat nun auch Interfaces und kann Regeln erstellen u.s.w..
Man muss aber auch die Routen selbst erstellen.
Ich kann ja die entfernte 45er IP pingen, aber die Weiterleitung geht nicht.
Kann es vielleicht der Fehler sein der genannt wurde?
Die Kardinalsfrage ist immer ob ein Port Forwarding auf eine nicht lokale IP Adresse auf einem Gerät funktioniert bzw. im Routing Prozess dann weiter geroutet wird. Einfache Konsumer Router wie z.B. auch die FritzBox scheitern an sowas. Cisco, Mikrotik und Co. können das aber problemlos.
Bis dato selber noch nie auf einer pfSense gemacht deshalb fehlt mir da jetzt die Erfahrung. Ich setze das hier im Lab mal auf und checke das mal.
Bis dato selber noch nie auf einer pfSense gemacht deshalb fehlt mir da jetzt die Erfahrung. Ich setze das hier im Lab mal auf und checke das mal.
Dann warte ich mal ab, was Dein test hervorbringt.
Von der Theorie her müsste ich doch testweise vorerst auch nur auf dem VPS auf OPNsense gehen, da dies ja der Punkt wäre, wo die Pakete rein sollen.
Von der Theorie her müsste ich doch testweise vorerst auch nur auf dem VPS auf OPNsense gehen, da dies ja der Punkt wäre, wo die Pakete rein sollen.
Ich habe, weil es am schnellsten gehen sollte, mal kurzzeitig OPNSense auf dem VPS installiert. Das GUI ist echt ganz anders aufgebaut, da wird einem ja schwindelig.
Jedoch lief es absolut hakelig und instabil. Woran das liegt, konnte ich nicht ergründen und bin auf den alten Zustand zurück.
Ob ich mal 2.5.0 versuche, dass die 2.5.2 doch buggy ist?
Oder warten auf 2.6 bzw. dort testen?
Jedoch lief es absolut hakelig und instabil. Woran das liegt, konnte ich nicht ergründen und bin auf den alten Zustand zurück.
Ob ich mal 2.5.0 versuche, dass die 2.5.2 doch buggy ist?
Oder warten auf 2.6 bzw. dort testen?
da wird einem ja schwindelig.
Ja, man muss sich heftig umgewöhnen... Ggf. schaff ich das die Tage es mal zu testen.
Ich könnte sogar meinen VPS als Testumgebung anbieten
Moin,
ich habe es gerade mit meinen zwei per OpenVPN verbundenen pfSenses getestet. Klappt einwandfrei.
VG
ich habe es gerade mit meinen zwei per OpenVPN verbundenen pfSenses getestet. Klappt einwandfrei.
VG
👍 Danke fürs Feedback !
@BirdyB Vielleicht ist Wireguard ja fehlerhaft?
Meine Config sieht ja oben.
Tunnel herstellen ist das eine, dass lassen wir mal aus.
Aber von den Regeln ist da was anders?
Wireguard soll etwas performanter sein, da nichts verschlüsselt werden muss
Meine Config sieht ja oben.
Tunnel herstellen ist das eine, dass lassen wir mal aus.
Aber von den Regeln ist da was anders?
Wireguard soll etwas performanter sein, da nichts verschlüsselt werden muss
Wireguard soll etwas performanter sein, da nichts verschlüsselt werden muss
Wie muss man den Satz denn jetzt verstehen ?? VPN und nix verschlüsseln ist ja ein Widerspruch in sich ! 🤔
Naja, anders und dadurch kann man richtig was durchschieben
Bahnhof ? Ägypten ? Nachts ist's kälter als draußen....
Such doch nicht das Haar in der Suppe, wenn ich es nicht fachlich ausgedrückt habe.
Sollte ich auch mal schauen ob OpenVPN was wird?
Sollte ich auch mal schauen ob OpenVPN was wird?
Das war mitnichten böse gemeint !! Man kann den Satz nur schlicht und einfach nicht verstehen zum Kontext, deshalb die Ratlosigkeit was du damit eigentlich zum Ausdruck bringen wolltest.
Hast ja recht.
Dann versuche ich es anders zu formulieren.
Wireguatd ist nicht so rechnenintensiv und schafft höheren Durchsatz.
Aus dem Grund eine ich darauf setzen.
Jedoch muss das ja auch irgendwie buggy sein, da es ja nicht zu laufen scheint.
Was für eine Rechenleistung sollte man präferieren?
Ich glaube der Xeon D1518 ist etwas Oversized.
Ein C3558 mit 4 Kernen wird reichlich sparsamer sein, oder?
Dann versuche ich es anders zu formulieren.
Wireguatd ist nicht so rechnenintensiv und schafft höheren Durchsatz.
Aus dem Grund eine ich darauf setzen.
Jedoch muss das ja auch irgendwie buggy sein, da es ja nicht zu laufen scheint.
Was für eine Rechenleistung sollte man präferieren?
Ich glaube der Xeon D1518 ist etwas Oversized.
Ein C3558 mit 4 Kernen wird reichlich sparsamer sein, oder?
und schafft höheren Durchsatz.
Im Vergleich zu OpenVPN ist das richtig. Zu IPsec ists gleich.Ich glaube der Xeon D1518
Oha, naja, kommt drauf an. Wenn du 1000 oder 2000 Clients bedienen musst oder ne 10G oder 40G Leitung passt das wieder ! 🤣Ohne das du Rahmenbedingungen nennst kann man doch nur wild rumraten, weisst du auch selber !
400 Mbit zu Hause mit maximal 5 VPNs soll das werden.
Ich glaube die Aufrüstung ist zu hoch gesetzt 🙈
Bis 1 Gigabit kann ich buchen, mal schauen.
4 Vlans
Virenscan oder so etwas aktuell nicht aktiv.
So etwas wie Pihole oder pfblocker kommt wohl noch.
Allerdings habe ich da 6x 1000er NIC und 2x 10 Gbit SFP
Ich glaube der c3558 wird reichlich weniger verbrauchen
Ich glaube die Aufrüstung ist zu hoch gesetzt 🙈
Bis 1 Gigabit kann ich buchen, mal schauen.
4 Vlans
Virenscan oder so etwas aktuell nicht aktiv.
So etwas wie Pihole oder pfblocker kommt wohl noch.
Allerdings habe ich da 6x 1000er NIC und 2x 10 Gbit SFP
Ich glaube der c3558 wird reichlich weniger verbrauchen
Dafür reicht ein einfaches APU4 Board allemal aus oder ein kleiner Intel
https://www.varia-store.com/de/produkt/103563-pc-engines-apu4d2-embedded ...
https://www.ipu-system.de/produkte/ipu450.html
Alles drüber ist natürlich nicht schlechter...
https://www.varia-store.com/de/produkt/103563-pc-engines-apu4d2-embedded ...
https://www.ipu-system.de/produkte/ipu450.html
Alles drüber ist natürlich nicht schlechter...
Ich nutze gerne Supermicro, schon wegen dem IPMI
Supermicro ist, wie immer, eine sehr gute Wahl !
Eben hatte ich mal wieder den Antrieb weiter den Fehler zu suchen.
Ich konnte bei mir das Wireguard Paket updaten.
Weiterhin habe ich den Tunnel auf IPv6 umgestellt.
Alles neu gestartet, aber das war es immer noch nicht. Das ist doch echt kurios
Ich konnte bei mir das Wireguard Paket updaten.
Weiterhin habe ich den Tunnel auf IPv6 umgestellt.
Alles neu gestartet, aber das war es immer noch nicht. Das ist doch echt kurios
Welchen "Fehler" hast du denn jetzt noch ??
Wie gesagt, der Tunnel steht. Ich kann von der entfernten pfsense einen Clienten, auf den das Nat laufen soll, pingen.
Aber der Forward geht partout nicht.
Eben habe ich alles was Wireguard heißt mal entfernt und OpenVPN ans laufen gebracht.
Bei der entfernten pfSense die internen Netze bekannt gemacht, bei der heimischen nichts.
Ich kann von der entfernten pfsense wieder pingen, aber der Forward geht auch wieder nicht.
Bei meiner heimischen ist OpenVPN in der Firewall aktuell ein Scheunentor
Ich komme nicht von extern auf die entfernte Firewall ohne VPN, nur IP:Port und werde wie gewünscht geforwardet.
Aber der Forward geht partout nicht.
Eben habe ich alles was Wireguard heißt mal entfernt und OpenVPN ans laufen gebracht.
Bei der entfernten pfSense die internen Netze bekannt gemacht, bei der heimischen nichts.
Ich kann von der entfernten pfsense wieder pingen, aber der Forward geht auch wieder nicht.
Bei meiner heimischen ist OpenVPN in der Firewall aktuell ein Scheunentor
Ich komme nicht von extern auf die entfernte Firewall ohne VPN, nur IP:Port und werde wie gewünscht geforwardet.
Könntest du mal eine Layer 3 Skizze des Setups posten ? Dann kann man das im Labor mal testen.
Moin aqui.
Das ist so etwas wie im Startpost oder?
Ich würde das sonst erweitern.
Sprich links ein Smartphone einzeichnen, welches die 94 IP mittels Port aufruft und dann sollte es nach rechts rüber genattet werden.
Ich nutze HighPorts und der soll mittels Nat auf 192.168.1.45:80 umgesetzt werden.
Die linke Firewall blockt allerdings alles weg durch Standard Regel obwohl ja eigentlich durch das Nat die Firewall geöffnet wird.
Pingen geht die 192.168.1.45 ja auch
Das ist so etwas wie im Startpost oder?
Ich würde das sonst erweitern.
Sprich links ein Smartphone einzeichnen, welches die 94 IP mittels Port aufruft und dann sollte es nach rechts rüber genattet werden.
Ich nutze HighPorts und der soll mittels Nat auf 192.168.1.45:80 umgesetzt werden.
Die linke Firewall blockt allerdings alles weg durch Standard Regel obwohl ja eigentlich durch das Nat die Firewall geöffnet wird.
Pingen geht die 192.168.1.45 ja auch
Das ist so etwas wie im Startpost oder?
Ja, die Zeichung reicht.... Nur um das nochmal zu rekapitulieren:
- VPS Firewall und lokale Firewall haben eine Site-to-Site VPN Verbindung ( Tunnel intern 10.0.0.0 /24)
- Lokales LAN der lokalen Firewall 192.168.0.0 /24
- Du möchtest ein Port Forwarding machen auf der VPS Firewall z.B. TCP 80 auf einen HTTP Host im 192.168.0.0er Netz, richtig ?
Generell klappen sollte es. Zumindestens wenn man nach "pfsense port forwarding via vpn tunnel" sucht gibt es diverse Hits.
https://forum.netgate.com/topic/130335/port-forwarding-into-remote-vpn-n ...
Checken wir das also mal...
Ja so in der Art.
Ich würde das über den VPS Natten lassen.
94.16.x.y:55555 soll über den Tunnel auf 192.168.1.45:80 ankommen.
Eigentlich wie normales Nat, nur halt über den Tunnel.
Bei Wireguard und OpenVPN waren jeweils die routen vorhanden und vom VPS konnte ich jeweils die 192.168.1.45 pingen.
Schlussfolgerung für mich, dass grundsätzlich die Tunnel stehen und die Routen halbwegs passen.
Beim VPS steht sofort das es über die Standard Deny Regel abgewiesen wird.
Dabei ist es grundsätzlich ja nichts anderes wie bei einer Nat Geschichte bei vollständigem Dual Stack, welcher mir leider jetzt vorenthalten bleibt.
Ich würde das über den VPS Natten lassen.
94.16.x.y:55555 soll über den Tunnel auf 192.168.1.45:80 ankommen.
Eigentlich wie normales Nat, nur halt über den Tunnel.
Bei Wireguard und OpenVPN waren jeweils die routen vorhanden und vom VPS konnte ich jeweils die 192.168.1.45 pingen.
Schlussfolgerung für mich, dass grundsätzlich die Tunnel stehen und die Routen halbwegs passen.
Beim VPS steht sofort das es über die Standard Deny Regel abgewiesen wird.
Dabei ist es grundsätzlich ja nichts anderes wie bei einer Nat Geschichte bei vollständigem Dual Stack, welcher mir leider jetzt vorenthalten bleibt.
Ich würde das über den VPS Natten lassen.
Das machst du ja so oder so immer wenn du dort mit Port Forwarding arbeitest ! Anders ginge es ja auch nicht.
Beim VPS steht sofort das es über die Standard Deny Regel abgewiesen wird.
Genau DAS steht ja auch im o.a. Link...und wie man es fixt.
Den habe ich mir natürlich angesehen.
Wie ich das verstanden habe, ist das ein Gateway Problem, dass der Client quasi falsch zurück antwortet.
Sehe ich das so richtig?
Also die Gegenseite als Gateway?
Wie ich das verstanden habe, ist das ein Gateway Problem, dass der Client quasi falsch zurück antwortet.
Sehe ich das so richtig?
Also die Gegenseite als Gateway?
Heute mal ein Test mit IPsec gemacht aber das schlägt fehl. Ist auch irgendwie erwartbar, denn für die IPs existieren keine SD in der Phase 2.
Captured man den Tunneltraffic mit über die Capture Funktion unter Diagnostics wird das auch bestätigt. Der geforwardete Traffic kommt erst gar nicht erst in den Tunnel. Wie gesagt unter IPsec ist das verständlich. Allerdings müsste man das realistischerweise nochmal mit VTI Interfaces testen. Gut möglich das es damit klappt. Im normalen IPsec Tunnel Mode dürfte das nicht erwartungsgemäß supportet sein.
Siehe dazu auch hier: https://forum.opnsense.org/index.php?topic=17381.0
Allerdings verweist der o.a. Foreneintrag auch auf einen Workaround mit dem es dennoch funktionieren soll über statische BINAT Einträge:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html
So oder so ist das bei OpenVPN eine völlig andere Situation, da es ein SSL basiertes VPN ist mit völlig anderem Protokoll Handling ohne diese SD Problematik wie oben.
Der o.a. Link beschreibt ja auch das das fehlerfrei klappen soll...zumindestens mit der pfSense.
Es ist also einen zweiten Versuch mit OpenVPN wert !
Eine Suche nach "pfsense port forward openvpn" ergibt auch einige Treffer.
Captured man den Tunneltraffic mit über die Capture Funktion unter Diagnostics wird das auch bestätigt. Der geforwardete Traffic kommt erst gar nicht erst in den Tunnel. Wie gesagt unter IPsec ist das verständlich. Allerdings müsste man das realistischerweise nochmal mit VTI Interfaces testen. Gut möglich das es damit klappt. Im normalen IPsec Tunnel Mode dürfte das nicht erwartungsgemäß supportet sein.
Siehe dazu auch hier: https://forum.opnsense.org/index.php?topic=17381.0
Allerdings verweist der o.a. Foreneintrag auch auf einen Workaround mit dem es dennoch funktionieren soll über statische BINAT Einträge:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html
So oder so ist das bei OpenVPN eine völlig andere Situation, da es ein SSL basiertes VPN ist mit völlig anderem Protokoll Handling ohne diese SD Problematik wie oben.
Der o.a. Link beschreibt ja auch das das fehlerfrei klappen soll...zumindestens mit der pfSense.
Es ist also einen zweiten Versuch mit OpenVPN wert !
Eine Suche nach "pfsense port forward openvpn" ergibt auch einige Treffer.
Oh weia, das sind ja Klimmzüge nur für eine IPv4 Erreichbarkeit.
Danke erstmal für Deine Mühe.
Ich schaue mir das mal in Ruhe die nächsten Tage an.
Ob dieses Szenario mit Wireguard gehen könnte? Bei OpenVPN müsste ich schauen, der Tunnel war nicht so recht stabil.
Danke erstmal für Deine Mühe.
Ich schaue mir das mal in Ruhe die nächsten Tage an.
Ob dieses Szenario mit Wireguard gehen könnte? Bei OpenVPN müsste ich schauen, der Tunnel war nicht so recht stabil.
Sollte eigentlich, denn das ist ja auch ein SSL basiertes VPN !
So, hier die OpenVPN Variante mit der es, wie zu erwarten, fehlerfrei klappt...zumindestens "fast" fehlerfrei...
OpenVPN Tunnel zur pfsense-2 up an running...
Routing Tabelle:
Hier kann man sehen das die eingehenden Pakete sauber in den OpenVPN Tunnel geroutet werden, denn der Packet Capture wurde schon auf dem OpenVPN Tunnelinterface auf der Serverseite gezogen.
Ein Paket Capture auf der anderen Seite (pfsense-1) zeigt ebenso das auch da diese Pakete fehlerfrei ankommen.
zumindestens nicht ohne die Lösung von @colinardo.
Das zeigt dann ein Wireshark Trace am Webserver:
(Nicht wundern die Webserver IP ist auf .104) geändert worden !)
Der tcpdump Output direkt vom Webserver zeigt das Dilemma ebenfalls:
Der via VPN Server geforwardete Client aus dem Internet (hier simuliert 10.99.1.142) kommt wunderbar am Webserver an, wie man ja auch oben an den Wireshark und tcpdump Traces sehen kann. Der Webserver antwortet auf dieses Client Paket auch vorschriftsmässig. Das ACK, WIN, ACK geht aber endlos so weiter weil das Server Antwort Paket am Client immer verworfen wird.
Warum ist das so....?!
Die Antwort Ziel IP Adresse des Paketes vom Webserver ist korrekt, nämlich die des Clients also 10.99.1.142.
Die lokale Firewall pfsense-1 muss aber nun nach ihrer lokalen Routing Tabelle gehen um das Paket zum Client zu routen und die besagt eben nicht das das Antwortpaket über den Tunnel zur pfsense-2 geht (was es eigentlich müsste) sondern direkt über ihre lokale Default Route zum Provider. (OpenVPN macht hier Split Tunneling im Site-to-Site Mode)
Damit bekommt sie durch das Outbound NAT der lokalen pfsense-1 jetzt als Absender IP aber die WAN IP 10.99.1.99 !
Der Client (10.99.1.142) aber erwartet natürlich eine Antwort IP vom Server 10.11.1.149 weil er sein TCP 8080 Paket ja DA hingesendet hat. Draufhin killt der TCP/IP Stack im Client sofort die TCP Session und die Verbindung kommt nicht zustande....
Fazit: So wird es also NICHT klappen...
Ein OpenVPN Gateway Redirect wäre zwar eine Lösung, denn das würde den gesamten Traffic der pfSense-1 durch den Tunnel routen. Praxistauglich ist das aber natürlich nicht, denn sämtlicher Outbound Traffic der pfSense-1 auch lokaler müsste sich durch den VPN Tunnel zur pfSense-2 quälen.
Jetzt wird auch klar warum die Lösung der o.a. Links nur mit bidirectional NAT (1:1) klappen kann, denn das per Port Forwarding in den Tunnel weitergeleitete Paket darf NICHT die ursprüngliche Absender IP behalten sondern muss per BINAT eine lokale Absender IP aus der Firewall bekommen die das Port Forwarding macht um wieder über den Tunnel zurückgeroutet zu werden und dann von dort ins Internet zu gehen.
Nur so ist sichergestellt das die Rückroute auch wieder mit der richtigen Absender IP am Client ankommt !!
Hoffe das bringt für dich etwas Licht ins Dunkel und bestätigt letztlich die Lösung wie sie ja auch im pfSense Forum und in der Knowledgebase diskutiert wurde.
Testaufbau:
Setup OVPN Serverseite mit Port Forwarding:
Sniffer Trace der NAT Pakete Serverseite:
Ein Paket Capture auf der anderen Seite (pfsense-1) zeigt ebenso das auch da diese Pakete fehlerfrei ankommen.
Warum es nicht klappen kann...
zumindestens nicht ohne die Lösung von @colinardo.Das zeigt dann ein Wireshark Trace am Webserver:
Der tcpdump Output direkt vom Webserver zeigt das Dilemma ebenfalls:
root@webserver:/home# tcpdump -i eth0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:53:28.846279 IP 10.99.1.142.53161 > 192.168.1.104.http: Flags [S], seq 491464061, win 64240, options [mss 1288,nop,wscale 8,nop,nop,sackOK], length 0
16:53:28.846518 IP 192.168.1.104.http > 10.99.1.142.53161: Flags [S.], seq 3474302136, ack 491464062, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
16:53:29.096687 IP 10.99.1.142.58231 > 192.168.1.104.http: Flags [S], seq 3289310713, win 64240, options [mss 1288,nop,wscale 8,nop,nop,sackOK], length 0
16:53:29.096922 IP 192.168.1.104.http > 10.99.1.142.58231: Flags [S.], seq 1728949974, ack 3289310714, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
16:53:29.848864 IP 10.99.1.142.53161 > 192.168.1.104.http: Flags [S], seq 491464061, win 64240, options [mss 1288,nop,wscale 8,nop,nop,sackOK], length 0
16:53:29.849052 IP 192.168.1.104.http > 10.99.1.142.53161: Flags [S.], seq 3474302136, ack 491464062, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 Warum ist das so....?!
Die Antwort Ziel IP Adresse des Paketes vom Webserver ist korrekt, nämlich die des Clients also 10.99.1.142.
Die lokale Firewall pfsense-1 muss aber nun nach ihrer lokalen Routing Tabelle gehen um das Paket zum Client zu routen und die besagt eben nicht das das Antwortpaket über den Tunnel zur pfsense-2 geht (was es eigentlich müsste) sondern direkt über ihre lokale Default Route zum Provider. (OpenVPN macht hier Split Tunneling im Site-to-Site Mode)
Damit bekommt sie durch das Outbound NAT der lokalen pfsense-1 jetzt als Absender IP aber die WAN IP 10.99.1.99 !
Der Client (10.99.1.142) aber erwartet natürlich eine Antwort IP vom Server 10.11.1.149 weil er sein TCP 8080 Paket ja DA hingesendet hat. Draufhin killt der TCP/IP Stack im Client sofort die TCP Session und die Verbindung kommt nicht zustande....
Fazit: So wird es also NICHT klappen...
Ein OpenVPN Gateway Redirect wäre zwar eine Lösung, denn das würde den gesamten Traffic der pfSense-1 durch den Tunnel routen. Praxistauglich ist das aber natürlich nicht, denn sämtlicher Outbound Traffic der pfSense-1 auch lokaler müsste sich durch den VPN Tunnel zur pfSense-2 quälen.
Jetzt wird auch klar warum die Lösung der o.a. Links nur mit bidirectional NAT (1:1) klappen kann, denn das per Port Forwarding in den Tunnel weitergeleitete Paket darf NICHT die ursprüngliche Absender IP behalten sondern muss per BINAT eine lokale Absender IP aus der Firewall bekommen die das Port Forwarding macht um wieder über den Tunnel zurückgeroutet zu werden und dann von dort ins Internet zu gehen.
Nur so ist sichergestellt das die Rückroute auch wieder mit der richtigen Absender IP am Client ankommt !!
Hoffe das bringt für dich etwas Licht ins Dunkel und bestätigt letztlich die Lösung wie sie ja auch im pfSense Forum und in der Knowledgebase diskutiert wurde.
Uff. Das ist nichts für mal abends auf dem Sofa angesehen.
Ich muss das mal in Ruhe auseinander klamüsern auf meine IPs
Das wird wohl die sinnvollste Lösung sein nehme ich an.
EDV Kossmann liefert da ja dann sicher fertige Lösungen.
Aber vom Grunde muss es ja das selbe sein.
Ganz banal 6to4 limitiert dann ja auf TCP u.s.w.
Einfach schade, dass die Deutsche Glasfaser keine IPv4 anbietet, auch nicht gegen Aufpreis (Privat natürlich)
Ich muss das mal in Ruhe auseinander klamüsern auf meine IPs
Das wird wohl die sinnvollste Lösung sein nehme ich an.
EDV Kossmann liefert da ja dann sicher fertige Lösungen.
Aber vom Grunde muss es ja das selbe sein.
Ganz banal 6to4 limitiert dann ja auf TCP u.s.w.
Einfach schade, dass die Deutsche Glasfaser keine IPv4 anbietet, auch nicht gegen Aufpreis (Privat natürlich)
Es kommt sogar noch schlimmer.... aber wie schon gesagt @colinardo hat unten schon die einfache Lösung dafür parat! 😉
Ich habe einmal einen Wireshark Trace auf dem Client PC im Internet gemacht der den Zugriff via Port Forwarding und Tunnel in der pfSense-2 macht:
Du kannst an der Mac Adresse des Webserver Antwort Frames Nummer 4 (gelbe Markierung) auf den SYN des Clients deutlich sehen das dieser ACK Antwortframe des Webservers (192.168.1.104) auch direkt am Test-Client (10.99.1.141) wieder ankommt und das der Absender damit in der Tat die pfSense-1 (WAN Port) ist. Genau also wie oben beschrieben.
Der Antwortframe geht also de facto NICHT zurück über den Tunnel was er aber müsste !!
Was noch übler ist, ist die Tatsache das vermutlich durch das im TCP Antwortframe gesetzte ACK Bit der Antwortframe NICHT über den NAT Prozess der pfSense-1 rennt sondern direkt geroutet wird. Du kannst das deutlich am ACK Antwortframe des Servers erkennen, denn der nutzt als Absender IP die interne RFC 1918 IP 192.168.1.104 im Internet (rote Markierung). Diese IP darf normal niemals im Internet auftauchen. Der Antwortframe wird also NICHT geNATet von der Firewall !!
Im realen Internet Leben würdest du am Client diesen ACK Frame niemals mehr sehen, denn am Providerport an dem die Firewall ja klemmt werden in real Life alle diese privaten RFC 1918 Frames sofort weggelöscht durch ACLs auf den Provider Routern. Man sieht das (falsche) Verhalten also nur im Labor so. In real würde der ACK Frame gar nicht am Client ankommen.
Fazit vom Fazit:
Ohne BINAT wird das nix !
Im Ernst, die DG kann wohl nix dafür oder zumindestens waren sie zu langsam. Grund ist:
https://www.heise.de/newsticker/meldung/Das-war-s-mit-IPv4-Adressen-in-E ...
Ggf. pfiffig sein. Da wo Glasfaser ist nutzt diese im Tandem auch die Telekom und die hat noch jede Menge freie IPv4 Adressen.
Ich habe einmal einen Wireshark Trace auf dem Client PC im Internet gemacht der den Zugriff via Port Forwarding und Tunnel in der pfSense-2 macht:
Du kannst an der Mac Adresse des Webserver Antwort Frames Nummer 4 (gelbe Markierung) auf den SYN des Clients deutlich sehen das dieser ACK Antwortframe des Webservers (192.168.1.104) auch direkt am Test-Client (10.99.1.141) wieder ankommt und das der Absender damit in der Tat die pfSense-1 (WAN Port) ist. Genau also wie oben beschrieben.
Der Antwortframe geht also de facto NICHT zurück über den Tunnel was er aber müsste !!
Was noch übler ist, ist die Tatsache das vermutlich durch das im TCP Antwortframe gesetzte ACK Bit der Antwortframe NICHT über den NAT Prozess der pfSense-1 rennt sondern direkt geroutet wird. Du kannst das deutlich am ACK Antwortframe des Servers erkennen, denn der nutzt als Absender IP die interne RFC 1918 IP 192.168.1.104 im Internet (rote Markierung). Diese IP darf normal niemals im Internet auftauchen. Der Antwortframe wird also NICHT geNATet von der Firewall !!
Im realen Internet Leben würdest du am Client diesen ACK Frame niemals mehr sehen, denn am Providerport an dem die Firewall ja klemmt werden in real Life alle diese privaten RFC 1918 Frames sofort weggelöscht durch ACLs auf den Provider Routern. Man sieht das (falsche) Verhalten also nur im Labor so. In real würde der ACK Frame gar nicht am Client ankommen.
Fazit vom Fazit:
Ohne BINAT wird das nix !
Einfach schade, dass die Deutsche Glasfaser keine IPv4 anbietet
Jeder bekommt halt den Provider den er verdient und die DG ist für diese IP Adressproblematik berühmt berüchtigt ! Im Ernst, die DG kann wohl nix dafür oder zumindestens waren sie zu langsam. Grund ist:
https://www.heise.de/newsticker/meldung/Das-war-s-mit-IPv4-Adressen-in-E ...
Ggf. pfiffig sein. Da wo Glasfaser ist nutzt diese im Tandem auch die Telekom und die hat noch jede Menge freie IPv4 Adressen.
Erstmal ist man ja 2 Jahre gebunden.
Ich hätte auch gerne mein T weiter gehabt.
Das die IPv4 zur Neige gehen oder gar alle sind wissen wir ja. Die Telekom hat, da auch historisch gewachsen quasi so viele um jedem 2 zuzuteilen.
Die DG hat ihr Netz offen, jeder kann sich einmieten.
Faktisch genutzt wird es aktuell nicht.
Vodafone hat ein Test und die Telekom auch. Aber für alle ist das nichts.
Vielleicht ist in 2 Jahren ja alles anders und ich kann zurück zur Telekom?
2 Mbit Telekom wäre meine Alternative gewesen. Hybrid ist es ja auch nicht wirklich und der Router...
Die anderen Geschichten mit stumpfer Umleitung offen werden doch wohl auch nicht gehen oder wenn dann nur TCP und kein UDP oder nicht?
Sprich alles was ankommt, wird auf die DDNS IPv6 weitergeleitet ohne Tunnel u.s.w.
6 Tunnel u.s.w.
Ich hätte auch gerne mein T weiter gehabt.
Das die IPv4 zur Neige gehen oder gar alle sind wissen wir ja. Die Telekom hat, da auch historisch gewachsen quasi so viele um jedem 2 zuzuteilen.
Die DG hat ihr Netz offen, jeder kann sich einmieten.
Faktisch genutzt wird es aktuell nicht.
Vodafone hat ein Test und die Telekom auch. Aber für alle ist das nichts.
Vielleicht ist in 2 Jahren ja alles anders und ich kann zurück zur Telekom?
2 Mbit Telekom wäre meine Alternative gewesen. Hybrid ist es ja auch nicht wirklich und der Router...
Die anderen Geschichten mit stumpfer Umleitung offen werden doch wohl auch nicht gehen oder wenn dann nur TCP und kein UDP oder nicht?
Sprich alles was ankommt, wird auf die DDNS IPv6 weitergeleitet ohne Tunnel u.s.w.
6 Tunnel u.s.w.
Ich hätte auch gerne mein T weiter gehabt.
Zu der Erkenntnis kommen 99% der Nutzer... Aber BINAT wird dich retten...
Du, das wusste ich vorher schon.
Nur habe ich auf dem Dorf keine Alternative.
Und dann klingelt jemand, bzw haben wir es mit gepushed und bietet einem die Faser bis ins Haus.
Das ist besser als Vectoring je sein kann.
Wenn dann in der Zukunft die Telekom die Leitung nutzt und im Pop eigene Technik installiert, wäre es genial.
Solch Chancen mit Glasfaser gratis gibt's nicht oft
Nur habe ich auf dem Dorf keine Alternative.
Und dann klingelt jemand, bzw haben wir es mit gepushed und bietet einem die Faser bis ins Haus.
Das ist besser als Vectoring je sein kann.
Wenn dann in der Zukunft die Telekom die Leitung nutzt und im Pop eigene Technik installiert, wäre es genial.
Solch Chancen mit Glasfaser gratis gibt's nicht oft
Aber eigentlich bedient die DG doch auch Business Kunden und für die sind v4 IPs zwingend. Es muss also auch möglich sein öffentliche v4s dort gegen Mehrkosten zu bekommen. Hat hier m.W. auch mal einer der Forenteilnehmer der DG Kunde war bestätigt.
Ich bin jedoch Privatkunde und es bedarf da einen unverhältnismäßig teureren Vertrag.
Würde man sagen mach nen 5er oder 10er Locker und Du bekommst die IPv4, dann wäre ich bereit.
Da sind die allerdings noch nicht hinter gekommen oder es lassen sich die teuren Business Anschlüsse schlechter vermarkten.
Würde man sagen mach nen 5er oder 10er Locker und Du bekommst die IPv4, dann wäre ich bereit.
Da sind die allerdings noch nicht hinter gekommen oder es lassen sich die teuren Business Anschlüsse schlechter vermarkten.
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html
Das scheint recht sinnig. Nur muss ich aktuell erstmal schauen, wo man diese zusätzlichen Adresse erstellt.
Wie ich das sehe ist Binat Phase 2 nur IPSec und ich weiß nicht wie ich das auf Wireguard übertragen kann
Oder ist das bei dem VPS Nat auf Desrination TunnelIP und auf der privaten Ourbound von der TunnelIP auf die 192.168.1.45?
Das scheint recht sinnig. Nur muss ich aktuell erstmal schauen, wo man diese zusätzlichen Adresse erstellt.
Wie ich das sehe ist Binat Phase 2 nur IPSec und ich weiß nicht wie ich das auf Wireguard übertragen kann
Oder ist das bei dem VPS Nat auf Desrination TunnelIP und auf der privaten Ourbound von der TunnelIP auf die 192.168.1.45?
Vermutlich gilt das generell für alle VPN Protokolle. Der Link oben beschreibt das ja auch anhand der modernenren VTI Interfaces.
Die haben den großen Vorteil das sie genau wie physische Interface zu konfigurieren sind und sich auch so verhalten.
Dieses Tutorial behandelt das Thema VTI: Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Das wäre in der Tat nochmal einen Versuch wert.
Die haben den großen Vorteil das sie genau wie physische Interface zu konfigurieren sind und sich auch so verhalten.
Dieses Tutorial behandelt das Thema VTI: Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Das wäre in der Tat nochmal einen Versuch wert.
Bei IPsec kann man vti anscheinend erstellen, aber wie erstellt man sonst eine virtuelle Schnittstelle?
Oder ist IPsec auch eine Option für mich?
Geht das auch, dass ich die bei Wireguard die Verbindung zum VPS auf die statische IP aufbaue oder braucht es Beide wie bei GRE?
Oder ist IPsec auch eine Option für mich?
Geht das auch, dass ich die bei Wireguard die Verbindung zum VPS auf die statische IP aufbaue oder braucht es Beide wie bei GRE?
aber wie erstellt man sonst eine virtuelle Schnittstelle?
Wireguard und OpenVPN machen das ja automatisch. IPsec mit VTIs auch. Bei Cisco Routern sagst du ganz einfach int tunnel 1 in der Konfig und schon ist das Interface erstellt. Eigentlich ganz easy...
Oder ist IPsec auch eine Option für mich?
Wie ist das gemeint ?? Generell oder bezogen auf dein ganz spezielles Anforderungsprofil oben ?? Wenn Letzteres, dann nur mit VTIs.bei Wireguard die Verbindung zum VPS auf die statische IP aufbaue
Jein. Es könnte ja auch eine DynDNS IP sein wenn du mit DynDNS Hostnamen arbeitest geht das auch. Die andere Seite kann komplett mit dynamischen IPs arbeiten. Wenn der Server immer Responder ist und die remoten Endpunkte immer die Initiators ist deren IP völlig egal. Das ist analog wie bei OpenVPN. Beides sind SSL basierte VPN Protokolle wo sowas problemlos ist.
...
Zitat von @aqui:
Eigentlich ganz easy...
aber wie erstellt man sonst eine virtuelle Schnittstelle?
Wireguard und OpenVPN machen das ja automatisch. IPsec mit VTIs auch. Bei Cisco Routern sagst du ganz einfach int tunnel 1 in der Konfig und schon ist das Interface erstellt. Eigentlich ganz easy...
Ist ja kein Cisco Router 🙈
Also virtuelle Schnittstelle.
Dorthin Natten und die leitet in den Tunnel zu der Gegenseite auf die virtuelle, die wiederum zum Client?
Auf ipsec kam ich, da es ja für meinen Zweck auch geht und wenn damit die virtuelle Schnittstelle braucht zu erstellen geht?
Anders habe ich es noch nicht herausgefunden
Oder denke ich zu kompliziert und es ist nur ein vlan welches ich keiner physikalischen NIC zuordne?
WARUM sendest du Posts 2mal ???
Wegen der einfachen Handhabe wären SSL Protokolle aber primär vorzuziehen. Da es mit OpenVPN ja generell sauber klappt wäre das also erste Anlaufstelle. Wenn's damit klappt, klappt es sehr wahrscheinlich auch mit WG.
Ist ja kein Cisco Router
Geht bei allen anderen doch mehr oder wenger immer genau so.Dorthin Natten und die leitet in den Tunnel zu der Gegenseite auf die virtuelle, die wiederum zum Client?
Jepp, genau das ist der Plan und ja auch im obigen Link mit BINAT so beschrieben als Lösung.Wegen der einfachen Handhabe wären SSL Protokolle aber primär vorzuziehen. Da es mit OpenVPN ja generell sauber klappt wäre das also erste Anlaufstelle. Wenn's damit klappt, klappt es sehr wahrscheinlich auch mit WG.
Das mit dem doppelten war keine Absicht.
Also von vorne
Paket kommt am VPS an, wird genattet auf vlan (neues Subnet)
Suvbnet Nattet dann weiter in den Tunnel auf vlan Gegenseite (neues Subnet), dieses dann wiederum auf die ZielIP?
Alter Schwede
Also von vorne
Paket kommt am VPS an, wird genattet auf vlan (neues Subnet)
Suvbnet Nattet dann weiter in den Tunnel auf vlan Gegenseite (neues Subnet), dieses dann wiederum auf die ZielIP?
Alter Schwede
Das mit dem doppelten war keine Absicht.
Warum löscht du denn solche Fauxpas' nicht ? Verwirrt ja nur...dieses dann wiederum auf die ZielIP?
Nein, falsch !Es reicht ein einfaches 1:1 NAT am VPS. Das kann auf eine Tunnel IP erledigt werden. Dadurch bekommt das dort von extern eingehende Paket eine lokale Absender IP eines der VPS Interfaces. Mit dieser IP wird es dann vom Ziel wieder in den Tunnel zurückgeroutet und eben NICHT lokal. Dann geht das Paket vom VPS Server wieder an den Client mit der gleichen Absender IP.
Es reicht also ein stinknormales 1:1 NAT am VPS.
Ging leider nicht mehr zu löschen der Doppelpost, sorry. Nun ist er mehr oder minder unkenntlich.
So sieht die 1:1 Nat Geschichte aus.
Da steht schonmal Binat, das ist gut.
Wir sind auf der VPS Seite.
Es existiert WAN als einzige physische NIC mit der IPv4 und IPv6 vom Hoster
Es existiert aufgrund der Wireguard Erstellung die Schnittstelle dazu mir 10.0.0.1
Nun muss für die Geschichte noch eine weitere Schnittstelle her.
Erstelle ich dafür nun ein Vlan mit 10.10.10.0/24 und setze das auf die Wireguard Schnittstelle on Top?
Die automatisch erstellte Schnittstelle musste ja für den Tunnel verbraucht werden.
Und auf der privaten pfSense dann auch noch ein zuisätzliches vlan, welches nicht in dem anderen Subnet des VPS vlans liegt? also 10.20.20.0/24 beispielsweise?
Laut dem Link von Dir bedarf es das 1:1 Nat beidseitig. Wie ich das verstehe muss dieses auch nur einmalig angelegt werden und ist quasi irrelevant für weitere Portforwardings. Es muss nur einmal fliegen, aber der Weg bis dahin ist steinig.
Und dann zusätzlich auf der VPS Seite den Port 6666 um beim Startpost zu bleiben wohin natten?
Irgendwie stehe ich gerade auf dem Schlauch ;-(
Edit: Ich habe jetzt jede Seite das VLAN4000 übergeordnet dem Wireguard Tunnel erstellt.
Bei dem VPS 10.10.0.1/24
Lokal 10.20.0.1/24
Wireguard ist ja VPS 10.0.0.1 und Lokal 10.0.0.2
Ist das alles was ich benötige für 1:1 und was muss dann wohin?
So sieht die 1:1 Nat Geschichte aus.
Da steht schonmal Binat, das ist gut.
Wir sind auf der VPS Seite.
Es existiert WAN als einzige physische NIC mit der IPv4 und IPv6 vom Hoster
Es existiert aufgrund der Wireguard Erstellung die Schnittstelle dazu mir 10.0.0.1
Nun muss für die Geschichte noch eine weitere Schnittstelle her.
Erstelle ich dafür nun ein Vlan mit 10.10.10.0/24 und setze das auf die Wireguard Schnittstelle on Top?
Die automatisch erstellte Schnittstelle musste ja für den Tunnel verbraucht werden.
Und auf der privaten pfSense dann auch noch ein zuisätzliches vlan, welches nicht in dem anderen Subnet des VPS vlans liegt? also 10.20.20.0/24 beispielsweise?
Laut dem Link von Dir bedarf es das 1:1 Nat beidseitig. Wie ich das verstehe muss dieses auch nur einmalig angelegt werden und ist quasi irrelevant für weitere Portforwardings. Es muss nur einmal fliegen, aber der Weg bis dahin ist steinig.
Und dann zusätzlich auf der VPS Seite den Port 6666 um beim Startpost zu bleiben wohin natten?
Irgendwie stehe ich gerade auf dem Schlauch ;-(
Edit: Ich habe jetzt jede Seite das VLAN4000 übergeordnet dem Wireguard Tunnel erstellt.
Bei dem VPS 10.10.0.1/24
Lokal 10.20.0.1/24
Wireguard ist ja VPS 10.0.0.1 und Lokal 10.0.0.2
Ist das alles was ich benötige für 1:1 und was muss dann wohin?
Servus @fnbalu ,
es ist so wie @aqui auch schon geschrieben hat. Ich möchte es dir aber anhand des Packet-Flows nochmal erläutern damit du verstehst was da genau abläuft.
Ich gehe jetzt mal bei meiner Beschreibung von folgendem Setup aus:
Ziel: UserA möchte mit seinem Client über die IP 1.2.3.4 Port 6666 den Webserver auf 192.168.1.45 Port 80 erreichen.
Die Abfolge der Pakete ist nun folgende:
1. User A initiiert die Verbindung auf 1.2.3.4:6666
2. Das Paket kommt auf der pfSense des VPS an und muss nun per DSTNAT an den Zielhost 192.168.1.45:80 weitergeleitet werden.
3. Bei DSTNAT wird dabei die Zieladresse des Pakets auf die 192.168.1.45 und der Port auf 80 umgeschrieben, dabei bleibt die SRC-Adresse von User A gleich und wird nicht verändert.
4. Da die Policy des Wireguard-Clients in der allowedips aber nur Pakete von 10.0.0.0/24 erwartet und andere nicht erlaubt bleiben die geforwardeten Pakete von User A schon im Tunnel hängen und erreichen den Wireguard Client an der Home pfSense erst gar nicht. Somit ist die Kommunikation schon abgewürgt. Würde man stattdessen in der Policy any akzeptieren, dann würden die Pakete zwar den Server erreichen dieser würde aber wiederum die Pakete über sein Default GW und nicht den Wireguard Tunnel zurück schicken, was dann zu einem asynchronem Routing führt, und @aqui oben schon erläutert hat.
5. Um diesen Umstand zu beheben kann man nun einfach ein SRCNAT (auf der pfSense nennt sich das OUTBOUND-NAT) auf dem Wireguard Interface machen das die Quell-Adresse dieser Pakete auf die IP 10.0.0.1 des Wireguard Interfaces des VPS umschreibt. Ist das erledigt haben die Pakete des Clients im Tunnel nun die Absender-Adresse 10.0.0.1 und als Zieladresse weiterhin 192.168.1.45:80.
6. Nun gelangt das Paket beim Client erfolgreich am Ziel 192.168.1.45:80 an. Da nun die Quelladresse des Pakets auf 10.0.0.1 lautet routet die 192.168.1.45:80 seine Pakete zurück an sein DefaultGW (die Home pfSense) und die wiederum routet das Paket zurück über den Tunnel an das Wireguard VPS Interface 10.0.0.1. Dort angekommen wird durch die NAT State Tabelle die Quell-Adresse des Pakets wieder auf die WAN Adresses des VPS umgeschrieben und die Zieladresse auf die Ursprüngliche von User A.
Was du also brauchst sind zwei Regeln einmal ein DSTNAT für die eingehenden Pakete und ein OUTBOUND NAT zum Umschreiben Quell-Adresse zur Weiterleitung in den Wireguard-Tunnel, beides nur auf der pfSsense beim VPS.
Das sieht dann in der Praxis auf der pfSense beim VPS so aus
Damit kommt das ganze dann auf Anhieb zum fliegen.
Das selbe geht natürlich auch mit anderen Ports, hier mal ein Schaubild über den Aufbau und der beispielhafte Packet-Flow
Ich persönlich mache etwas ähnliches, aber ich mache das mit meinem Mikrotik RB4011 über eine IPSEC-Verbindung zu einem vServer und statt dem SRCNAT wie oben beschrieben installiere ich am Mikrotik dann eine IPSEC Policy auf 0.0.0.0/0 die aber Pakete von bestimmten Clients und Quell-Ports dann wieder automatisch über den Tunnel routet. Hier muss man dann aber darauf achten das man für die lokal erreichbaren Subnetze IPSEC Policies erstellt bei der Encryption auf "None" gestellt ist, sonst erreicht man den Server lokal nicht mehr weil er sonst Antworten generell über den Tunnel schickt.
Man kann alternativ auch mit Routing-Tags arbeiten mit denen man Traffic von bestimmten Clients oder Verbindungen explizit markiert und dann über den Wireguard Tunnel routet.
Grüße Uwe
es ist so wie @aqui auch schon geschrieben hat. Ich möchte es dir aber anhand des Packet-Flows nochmal erläutern damit du verstehst was da genau abläuft.
Ich gehe jetzt mal bei meiner Beschreibung von folgendem Setup aus:
- WAN-IP VPS = 1.2.3.4
- WG TUNNEL IP VPS = 10.0.0.1/24
- WG TUNNEL IP HOME = 10.0.0.2/24
- HOME SUBNET = 192.168.1.0/24
Ziel: UserA möchte mit seinem Client über die IP 1.2.3.4 Port 6666 den Webserver auf 192.168.1.45 Port 80 erreichen.
Die Abfolge der Pakete ist nun folgende:
1. User A initiiert die Verbindung auf 1.2.3.4:6666
2. Das Paket kommt auf der pfSense des VPS an und muss nun per DSTNAT an den Zielhost 192.168.1.45:80 weitergeleitet werden.
3. Bei DSTNAT wird dabei die Zieladresse des Pakets auf die 192.168.1.45 und der Port auf 80 umgeschrieben, dabei bleibt die SRC-Adresse von User A gleich und wird nicht verändert.
4. Da die Policy des Wireguard-Clients in der allowedips aber nur Pakete von 10.0.0.0/24 erwartet und andere nicht erlaubt bleiben die geforwardeten Pakete von User A schon im Tunnel hängen und erreichen den Wireguard Client an der Home pfSense erst gar nicht. Somit ist die Kommunikation schon abgewürgt. Würde man stattdessen in der Policy any akzeptieren, dann würden die Pakete zwar den Server erreichen dieser würde aber wiederum die Pakete über sein Default GW und nicht den Wireguard Tunnel zurück schicken, was dann zu einem asynchronem Routing führt, und @aqui oben schon erläutert hat.
5. Um diesen Umstand zu beheben kann man nun einfach ein SRCNAT (auf der pfSense nennt sich das OUTBOUND-NAT) auf dem Wireguard Interface machen das die Quell-Adresse dieser Pakete auf die IP 10.0.0.1 des Wireguard Interfaces des VPS umschreibt. Ist das erledigt haben die Pakete des Clients im Tunnel nun die Absender-Adresse 10.0.0.1 und als Zieladresse weiterhin 192.168.1.45:80.
6. Nun gelangt das Paket beim Client erfolgreich am Ziel 192.168.1.45:80 an. Da nun die Quelladresse des Pakets auf 10.0.0.1 lautet routet die 192.168.1.45:80 seine Pakete zurück an sein DefaultGW (die Home pfSense) und die wiederum routet das Paket zurück über den Tunnel an das Wireguard VPS Interface 10.0.0.1. Dort angekommen wird durch die NAT State Tabelle die Quell-Adresse des Pakets wieder auf die WAN Adresses des VPS umgeschrieben und die Zieladresse auf die Ursprüngliche von User A.
Was du also brauchst sind zwei Regeln einmal ein DSTNAT für die eingehenden Pakete und ein OUTBOUND NAT zum Umschreiben Quell-Adresse zur Weiterleitung in den Wireguard-Tunnel, beides nur auf der pfSsense beim VPS.
Das sieht dann in der Praxis auf der pfSense beim VPS so aus
DSTNAT:
OUTBOUND NAT
Damit kommt das ganze dann auf Anhieb zum fliegen.
Das selbe geht natürlich auch mit anderen Ports, hier mal ein Schaubild über den Aufbau und der beispielhafte Packet-Flow
Ich persönlich mache etwas ähnliches, aber ich mache das mit meinem Mikrotik RB4011 über eine IPSEC-Verbindung zu einem vServer und statt dem SRCNAT wie oben beschrieben installiere ich am Mikrotik dann eine IPSEC Policy auf 0.0.0.0/0 die aber Pakete von bestimmten Clients und Quell-Ports dann wieder automatisch über den Tunnel routet. Hier muss man dann aber darauf achten das man für die lokal erreichbaren Subnetze IPSEC Policies erstellt bei der Encryption auf "None" gestellt ist, sonst erreicht man den Server lokal nicht mehr weil er sonst Antworten generell über den Tunnel schickt.
Man kann alternativ auch mit Routing-Tags arbeiten mit denen man Traffic von bestimmten Clients oder Verbindungen explizit markiert und dann über den Wireguard Tunnel routet.
Grüße Uwe
3
Jawoll, das fliegt.
Ich habe mich auf einem Rechner, der noch über die alte pfSense sein Gateway erhält eingeloggt und siehe da die Webseite war direkt offen.
Hammer.
Erstmal vielen Dank @aqui und @colinardo für Eure Geduld.
Ich denke das hilft so auch anderen, denn so kann man für unter 3€ mit einer IPv4 forwarden.
In meinem Fall läuft das über Wireguard.
Da hätte ich die zusätzliche IPv4 doch nicht gebraucht, die ich extra gebucht habe für 1€ mtl und 5€ Einrichtung.
Ich habe mich auf einem Rechner, der noch über die alte pfSense sein Gateway erhält eingeloggt und siehe da die Webseite war direkt offen.
Hammer.
Erstmal vielen Dank @aqui und @colinardo für Eure Geduld.
Ich denke das hilft so auch anderen, denn so kann man für unter 3€ mit einer IPv4 forwarden.
In meinem Fall läuft das über Wireguard.
Da hätte ich die zusätzliche IPv4 doch nicht gebraucht, die ich extra gebucht habe für 1€ mtl und 5€ Einrichtung.
Zitat von @fnbalu:
Dort die höchstwahrscheinlich irrtümlich eingebene IP 192.168.50.12 um beim Beispiel zu bleiben auf 192.168.1.45 ändern.
Uups ja das war mein Fehler, ändere das noch. => done.Dort die höchstwahrscheinlich irrtümlich eingebene IP 192.168.50.12 um beim Beispiel zu bleiben auf 192.168.1.45 ändern.
Jawoll, das fliegt.
👍2
Dank an @colinardo für den ausführlichen Post zu dem Thema. 👍
Ich war mal so frei den Link in die pfSense/OPNsense VPN Tutorials aufzunehmen, da so ein Setup ja sicher öfter mal vorkommt.
Ich war mal so frei den Link in die pfSense/OPNsense VPN Tutorials aufzunehmen, da so ein Setup ja sicher öfter mal vorkommt.
ich mache das mit meinem Mikrotik RB4011 über eine IPSEC-Verbindung zu einem vServer
Das ist ja nochmal ein klasse Stoff für ein entsprechendes Tutorial !!! 😉1
Eine klitzekleine Frage hätte ich noch nachzureichen.
Es gibt ja die Firewall selbst, was man für VPN etc nutzt.
Eine Regel, die bei Dual Stack auf diese Firewall selbst beläuft, für OpenVPN oder warum auch immer um das GUI zu öffnen, wie lautet die Regel da?
Lässt man das dann auf die LAN IP der pfSense laufen?
192.168.1.1?
Es gibt ja die Firewall selbst, was man für VPN etc nutzt.
Eine Regel, die bei Dual Stack auf diese Firewall selbst beläuft, für OpenVPN oder warum auch immer um das GUI zu öffnen, wie lautet die Regel da?
Lässt man das dann auf die LAN IP der pfSense laufen?
192.168.1.1?
Uuuuhhh, wie gruselig, du willst das Setup GUI für den öffentlichen Zugriff am WAN öffnen ?? Keine wirklich gute Idee !!
Aber das geht normal im Regelwerk am WAN Port dann mit einer einfachen IPv6 Regel die Port 443 von Any auf die v6 IP des WAN Ports freigibt. Du willst ja, wenn überhaupt, hoffentlich nur HTTPS machen, oder ?!
Aber das geht normal im Regelwerk am WAN Port dann mit einer einfachen IPv6 Regel die Port 443 von Any auf die v6 IP des WAN Ports freigibt. Du willst ja, wenn überhaupt, hoffentlich nur HTTPS machen, oder ?!
Zitat von @fnbalu:
Eine Regel, die bei Dual Stack auf diese Firewall selbst beläuft, für OpenVPN oder warum auch immer um das GUI zu öffnen, wie lautet die Regel da?
Du meinst um das WebGUI der pfSense freizugeben? Das würde ich nur innerhalb des VPNs tun, also eine Regel die nur auf dem OpenVPN Abschnitt der Firewall wirkt, so dass auch nur Clients innerhalb des VPNs daruf zugreifen dürfen.Eine Regel, die bei Dual Stack auf diese Firewall selbst beläuft, für OpenVPN oder warum auch immer um das GUI zu öffnen, wie lautet die Regel da?
2
Um Himmels Willen, das ist beispielhaft.
Selbst beim VPS ist der GUI Zugriff für alle gesperrt, super für mich.
Bisher nutze ich ja OpenVPN auf der bisherigen pfSense
Dafür wird ja der Port auf die Firewall selbst freigeben über NAT. 1194 whatever.
Ich würde OpenVPN jedoch auf der lokalen Firewall lassen und nach dem obigen Muster 1194 mit outbound NAT u.s.w. forwarden
Das sind zwar 2 Tunnel, sollte aber gehen denke ich.
Zumal die Rechenleistung zu Hause für die Tunnel potenter ist.
Selbst beim VPS ist der GUI Zugriff für alle gesperrt, super für mich.
Bisher nutze ich ja OpenVPN auf der bisherigen pfSense
Dafür wird ja der Port auf die Firewall selbst freigeben über NAT. 1194 whatever.
Ich würde OpenVPN jedoch auf der lokalen Firewall lassen und nach dem obigen Muster 1194 mit outbound NAT u.s.w. forwarden
Das sind zwar 2 Tunnel, sollte aber gehen denke ich.
Zumal die Rechenleistung zu Hause für die Tunnel potenter ist.
Zitat von @fnbalu:
Dafür wird ja der Port auf die Firewall selbst freigeben über NAT. 1194 whatever.
Ich würde OpenVPN jedoch auf der lokalen Firewall lassen und nach dem obigen Muster 1194 mit outbound NAT u.s.w. forwarden
Das sind zwar 2 Tunnel, sollte aber gehen denke ich.
Zumal die Rechenleistung zu Hause für die Tunnel potenter ist.
Kann man aber denk dabei an die MTU, die wird entsprechend weit geringer ausfallen und somit auch der mögliche Durchsatz. Du erzeugst da ja ein Tunnel in einem Tunnel, würde ich wo es geht vermeiden und immer am Perimeter terminieren, das NATen kostet ja auch CPU.Dafür wird ja der Port auf die Firewall selbst freigeben über NAT. 1194 whatever.
Ich würde OpenVPN jedoch auf der lokalen Firewall lassen und nach dem obigen Muster 1194 mit outbound NAT u.s.w. forwarden
Das sind zwar 2 Tunnel, sollte aber gehen denke ich.
Zumal die Rechenleistung zu Hause für die Tunnel potenter ist.
2
Hmmmm
MTU müsste ich tatsächlich schauen, dass war durch die alte Hybrid Leistung eh maukig.
Also meinst lieber OpenVPN auch auslagern?
Dann bin ich echt total Oversized zu Hause
MTU müsste ich tatsächlich schauen, dass war durch die alte Hybrid Leistung eh maukig.
Also meinst lieber OpenVPN auch auslagern?
Dann bin ich echt total Oversized zu Hause
Ja, aber ich persönlich würde kein OpenVPN mehr nutzen,der Overhead ist mir persönlich zu groß. Wireguard gibt es ja inzwischen für jegliche Art Device. Alternativ geht natürlich immer ein reiner IPSec-Tunnel mittels Strongswan-Client, aber das muss jeder selbst entscheiden.
2
Das müsste ich tatsächlich schauen.
In Zukunft plane ich meine Freundin auch mit einer pfSense auszustatten und diese soll dann auch Site2Site zu mir machen.
Das dann aber über IPv6 direkt zu mir
Es wäre also nur für mobile Geräte interessant wie mein Handy oder sporadisch mein Laptop die ja auch mal woanders sein können, wo es kein IPv6 gibt
In Zukunft plane ich meine Freundin auch mit einer pfSense auszustatten und diese soll dann auch Site2Site zu mir machen.
Das dann aber über IPv6 direkt zu mir
Es wäre also nur für mobile Geräte interessant wie mein Handy oder sporadisch mein Laptop die ja auch mal woanders sein können, wo es kein IPv6 gibt
Das dann aber über IPv6 direkt zu mir
Wenn du feste v6 WAN IPs hast reicht dafür dann einfache Transportverschlüselung mit IPsec.
Das habe ich nicht. Das ändert sich wohl alle 24 Stunden.
Da ich mit IPv6 Probleme hatte, habe ich mittlerweile eine FritzBox 4040 davor, die als Exposed Host die pfSense hat und das IPv6 Subnet durchreicht.
Auf die IPv6 gibts aber einen DDNS Eintrag
Da ich mit IPv6 Probleme hatte, habe ich mittlerweile eine FritzBox 4040 davor, die als Exposed Host die pfSense hat und das IPv6 Subnet durchreicht.
Auf die IPv6 gibts aber einen DDNS Eintrag
Das ändert sich wohl alle 24 Stunden.
Nee, die v6 Adress- und Prefix Gültigkeit dauert in der Regel länger ca. 1-2 Monate. Du wirst aber noch ein anderes Problem haben. Du bekommst auch immer einen neuen v6 Prefix und damit ändert sich dann auch immer dein lokales v6 IP Netz was dann ein v6 VPN unmöglich macht.Wenn du die Netze mit v6 VPN koppeln willst musst du zusätzlich zum offiziellen Prefix Netz im LAN noch Unique local v6 Adressen vergeben. Das sind die privaten IP Netze bei v6 mit dem Refix fc00::/7 RFC-4193.
Bei v6 kein Problem denn dort sind mehrere Adressen pro Interface üblich.
Diese Unique lasse ich von der vorgelagerten Fritzbox vergeben.
Da denkt man sich ja ein Subnet für aus meine ich
Im Beispiel meiner Freundin, welche Telekom nutzt, könnte ich mich ja zu ihr verbinden
Da denkt man sich ja ein Subnet für aus meine ich
Im Beispiel meiner Freundin, welche Telekom nutzt, könnte ich mich ja zu ihr verbinden
Auch wenn es nicht schön ist, würde ich als Übergang gerne mit OpenVPN auch über IPv4 forwarden und dann schauen.
Erstmal muss alles laufen wie bisher um umzusteigen, was viele Steine aus den Weg räumt (Hardwaretausch aktuell rennen ja zwei pfSensen und nur wenige Clients nutzen zum Testen die neue und somit gibts ja andere Gateways)
Also mit Outbound für etwaige Webserver läuft das ja.
Problem ist diese Firewall selbst
VPN wird ja nicht genattet, da es auf der Firewall selbst liegt.
Früher hieß es da beim WAN Interface UDP, Source Any, Destination WAN Adress 1194
Firewall selbst gibt es ja in der Konstellation so ja nicht, da ja geforwardet werden müsste über den VPS
Zu Hause habe ich 192.168.1.1 für die Firewall
OpenVPN hat seit eh und je 10.20.30.0/24
Bekommt man das überhaupt über den Wireguard Tunnel hin, analog der anderen Konstellation wie bei einem Webserver etc?
Irgendwie hat am OpenVPN lokal mal kurzzeitig was gezuckt, von 10.0.0.1 was ja als Gegenseite erkannt wurde, aber mehr nicht.
Erstmal muss alles laufen wie bisher um umzusteigen, was viele Steine aus den Weg räumt (Hardwaretausch aktuell rennen ja zwei pfSensen und nur wenige Clients nutzen zum Testen die neue und somit gibts ja andere Gateways)
Also mit Outbound für etwaige Webserver läuft das ja.
Problem ist diese Firewall selbst
VPN wird ja nicht genattet, da es auf der Firewall selbst liegt.
Früher hieß es da beim WAN Interface UDP, Source Any, Destination WAN Adress 1194
Firewall selbst gibt es ja in der Konstellation so ja nicht, da ja geforwardet werden müsste über den VPS
Zu Hause habe ich 192.168.1.1 für die Firewall
OpenVPN hat seit eh und je 10.20.30.0/24
Bekommt man das überhaupt über den Wireguard Tunnel hin, analog der anderen Konstellation wie bei einem Webserver etc?
Irgendwie hat am OpenVPN lokal mal kurzzeitig was gezuckt, von 10.0.0.1 was ja als Gegenseite erkannt wurde, aber mehr nicht.
Da denkt man sich ja ein Subnet für aus meine ich
Für die Freundin dann etwas Lustiges wie fd::bad:babe:b00b:1 /64Danach dann aber schnell in Deckung gehen... 🤣
http://sophiedogg.com/funny-ipv6-words/
Bekommt man das überhaupt über den Wireguard Tunnel hin
Ja, die Konfig und das grundsätzliche Verhalten ist vollkommen identisch zu OpenVPN da beides ja SSL VPNs sind die über virtuelle Tunnel Interfaces arbeiten. WG ist etwas performanter was den Durchsatz anbetrifft. Aber dein Vorgehen ist richtig. Erstmal alles zum Fliegen bringen, testen, dann gff. umstellen.am OpenVPN lokal mal kurzzeitig was gezuckt
Da müssen wir jetzt mal frei raten was du mit "zucken" wohl meinst...?!
Ich möchte mich ja über Wireguard mittels IPv4 auf OpenVPN verbinden.
Es soll also der Port identisch geforwardet werden.
Wireguard ist das Netz 10.20.30.0 natürlich bekannt gemacht worden.
Der Forward ging also von der 1194 auf die LAN IP 192.168.1.1 der pfSense.
Das ist dann leider nicht so wie bei der pfSense direkt am Netz mit einer incoming Regel auf sich selbst.
Logs hatte ich keine angesehen, vorne im Dashboard sah ich einen Verbindungsversuch von 10.0.0.1
Es soll also der Port identisch geforwardet werden.
Wireguard ist das Netz 10.20.30.0 natürlich bekannt gemacht worden.
Der Forward ging also von der 1194 auf die LAN IP 192.168.1.1 der pfSense.
Das ist dann leider nicht so wie bei der pfSense direkt am Netz mit einer incoming Regel auf sich selbst.
Logs hatte ich keine angesehen, vorne im Dashboard sah ich einen Verbindungsversuch von 10.0.0.1
Zitat von @fnbalu:
Ich möchte mich ja über Wireguard mittels IPv4 auf OpenVPN verbinden.
Es soll also der Port identisch geforwardet werden.
Wireguard ist das Netz 10.20.30.0 natürlich bekannt gemacht worden.
Brauchst du nur wenn die OpenVPN Clients über OpenVPN auf das VPS Netz zugreifen können sollen ansonsten ist das überflüssig denn diese kommen mit diesem Netz per Default nicht in Kontakt.Ich möchte mich ja über Wireguard mittels IPv4 auf OpenVPN verbinden.
Es soll also der Port identisch geforwardet werden.
Wireguard ist das Netz 10.20.30.0 natürlich bekannt gemacht worden.
Der Forward ging also von der 1194 auf die LAN IP 192.168.1.1 der pfSense.
Du terminierst das VPN am einfachsten gleich auf dem Wireguard Interface (10.0.0.2), wo du auch die Firewall Regel für das Öffnen des Ports 1194 anlegst.Zusätzlich stelle sicher das OpenVPN auch auf dem Wireguard Interface überhaupt lauscht und nicht nur auf dem WAN-Interface.
Also entweder auf ANY stellen wenn du sowohl über das WAN Interface als auch das WG Interface connecten willst, oder eben nur noch über den WG Tunnel.
Auf VPS Seite natürlich daran Denken das dort OpenVPN deaktiviert oder auf einem anderen Ports läuft, nicht das du dort parallel einen Server auf dem VPS und intern fährst der auf dem gleichen Port läuft, das gibt dann natürlich Hickhack.
Habe das ganze hier übrigens auch erfolgreich getestet, läuft wie erwartet problemlos. Man muss nur penibel alle Schritte durchgehen, gerne vergisst man mal in den Portweiterleitungen oder den Firewall Regeln auf UDP statt TCP festzulegen, das sind so kleine Fallstricke, aber hat man sie mal alle gemeistert läuft das wie erwartet.
So, das ist jetzt inzwischen doch Off-Topic. Lass uns hier doch bitte zu einem Ende kommen, das eigentliche Thema wurde ja gelöst. Merci.
Grüße und weiterhin viel Erfolg.
Uwe
2
Läuft, Danke.
Nun google ich mal etwas wie ich das OpenVPN beschleunige. Egal wie herum man schaut, ich denke 5 Mbit sind zu mager
Nun google ich mal etwas wie ich das OpenVPN beschleunige. Egal wie herum man schaut, ich denke 5 Mbit sind zu mager
Zitat von @fnbalu:
Läuft, Danke.
Nun google ich mal etwas wie ich das OpenVPN beschleunige. Egal wie herum man schaut, ich denke 5 Mbit sind zu mager
Läuft, Danke.
Nun google ich mal etwas wie ich das OpenVPN beschleunige. Egal wie herum man schaut, ich denke 5 Mbit sind zu mager
Da wird wohl wie oben gesagt die MTU zu heftigen Fragmentierung führen, da hilft es meist die MTU in der OpenVPN Config erst mal runter zu schrauben und sich dann hoch zu arbeiten.
fragmentation 1300mssfix 1300Paket-Fragmentierung kannst du leicht mittels Ping und do not fragment bit oder einem Wireshark trace prüfen.
Wireguard selbst reduziert ja die MTU im Tunnel schon auf 1420. Sicherstellen sollte man immer das ICMP Pakete für die Ermittlung der MTU an die Gegenstellen erlaubt sind damit die PMTU-Ermittlung funktioniert.
2
...und besser einen neuen Thread dafür eröffnen wie Kollege @colinardo schon angemerkt hat.
