Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren

fnbalu
Goto Top
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.


pfsense1

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?

Content-Key: 1161214871

Url: https://administrator.de/contentid/1161214871

Ausgedruckt am: 03.07.2022 um 21:07 Uhr

Mitglied: aqui
aqui 16.08.2021 aktualisiert um 14:24:20 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 16.08.2021 um 15:48:56 Uhr
Goto Top
Ich habe das jetzt mal umgesetzt.

nat1

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?
Mitglied: aqui
aqui 16.08.2021 um 17:24:58 Uhr
Goto Top
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.
Mitglied: BirdyB
BirdyB 16.08.2021 um 17:25:03 Uhr
Goto Top
Hast du auf der VPS pfSense auf dem
WAN-Interface eine passende Firewall-Regel erstellt?
Mitglied: aqui
aqui 16.08.2021 um 17:27:10 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 16.08.2021 um 22:14:15 Uhr
Goto Top
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.
1-wan


Man muss ja auch dem wg Interface eine Zuordnung verpassen, die sieht so aus.
Ist die 32 da richtig? oder 24 wegen Netz?
2-interface


Die Wireguard Scheunentor Regel (vorerst bis es läuft)
3-wireguard


Das Tunnel Interface hat nichts. Ist das richtig?
4-ttunnel


Die Routen. Die 10.0.0.1 ist die IP der eigenen Seite. Oder bedarf es da der Gegenseiten?
5-routen


VPS-Seitig die Peers. In dem Fall das 192.168.1.0 Netz vorerst
6-peers


Und natürlich die NAT Geschichte, die sich automatisch erstellte
7-nat



Das ist jetzt alles von der VPS Seite.
Bei mir zu Hause natürlich analog dazu.
Mitglied: aqui
aqui 17.08.2021 aktualisiert um 09:33:40 Uhr
Goto Top
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 und auch das Foren Wireguard Tutorial hier. Richtig lesen und umsetzen hilft also wirklich ! face-wink
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... face-wink
Mitglied: fnbalu
fnbalu 17.08.2021 um 10:12:40 Uhr
Goto Top
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
Mitglied: aqui
aqui 17.08.2021 um 11:38:16 Uhr
Goto Top
Das Konfig GUI sollte man aus guten Gründen generell niemals im Internet freigeben egal welche Router oder Firewall. face-wink
Mitglied: fnbalu
fnbalu 17.08.2021 aktualisiert um 12:57:26 Uhr
Goto Top
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

8-staticroutes




Edit: Ich habe das jetzt so wie bei Peers verstanden:
10-ping

Jedoch geht dann kein Ping mehr
10-ping

Kann es sein, dass es gravierende Unterschiede zwischen pfSense 2.5.0 und 2.5.2 was Wireguard angeht, gibt?
9-peers
Mitglied: aqui
aqui 17.08.2021 um 14:13:03 Uhr
Goto Top
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. face-wink
Mitglied: fnbalu
fnbalu 17.08.2021 um 14:34:51 Uhr
Goto Top
Sind diese hinderlich? Das steht ja echt im krassen Widerspruch mit der Videoanleitung
Mitglied: aqui
aqui 17.08.2021 aktualisiert um 14:43:31 Uhr
Goto Top
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" face-wink
Besser also immer sich an die Original Anleitung des WG Entwicklers halten. 😉
Mitglied: fnbalu
fnbalu 17.08.2021 aktualisiert um 16:06:34 Uhr
Goto Top
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
Mitglied: aqui
aqui 17.08.2021 aktualisiert um 17:21:05 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 17.08.2021 um 18:15:51 Uhr
Goto Top
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?
Mitglied: aqui
aqui 18.08.2021 um 08:47:47 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 18.08.2021 um 11:37:40 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 23.08.2021 um 20:15:32 Uhr
Goto Top
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?
Mitglied: aqui
aqui 24.08.2021, aktualisiert am 02.09.2021 um 10:39:50 Uhr
Goto Top
da wird einem ja schwindelig.
Ja, man muss sich heftig umgewöhnen... face-wink
Ggf. schaff ich das die Tage es mal zu testen.
Mitglied: fnbalu
fnbalu 02.09.2021 um 10:31:28 Uhr
Goto Top
Ich könnte sogar meinen VPS als Testumgebung anbieten
Mitglied: BirdyB
BirdyB 02.09.2021 um 11:16:17 Uhr
Goto Top
Moin,

ich habe es gerade mit meinen zwei per OpenVPN verbundenen pfSenses getestet. Klappt einwandfrei.

VG
Mitglied: aqui
aqui 02.09.2021 um 11:35:29 Uhr
Goto Top
👍 Danke fürs Feedback !
Mitglied: fnbalu
fnbalu 02.09.2021 um 12:36:17 Uhr
Goto Top
@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
Mitglied: aqui
aqui 02.09.2021 um 14:16:36 Uhr
Goto Top
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 ! 🤔
Mitglied: fnbalu
fnbalu 02.09.2021 um 16:32:50 Uhr
Goto Top
Naja, anders und dadurch kann man richtig was durchschieben
Mitglied: aqui
aqui 02.09.2021 um 21:40:02 Uhr
Goto Top
Bahnhof ? Ägypten ? Nachts ist's kälter als draußen....
Mitglied: fnbalu
fnbalu 04.09.2021 um 14:52:21 Uhr
Goto Top
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?
Mitglied: aqui
aqui 04.09.2021 um 17:30:55 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 05.09.2021 um 17:58:41 Uhr
Goto Top
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?
Mitglied: aqui
aqui 05.09.2021 um 18:06:58 Uhr
Goto Top
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 !
Mitglied: fnbalu
fnbalu 05.09.2021 aktualisiert um 18:25:05 Uhr
Goto Top
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
Mitglied: aqui
aqui 05.09.2021 aktualisiert um 18:42:23 Uhr
Goto Top
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... face-wink
Mitglied: fnbalu
fnbalu 05.09.2021 um 18:50:29 Uhr
Goto Top
Ich nutze gerne Supermicro, schon wegen dem IPMI
Mitglied: aqui
aqui 06.09.2021 um 09:52:24 Uhr
Goto Top
Supermicro ist, wie immer, eine sehr gute Wahl !
Mitglied: fnbalu
fnbalu 15.09.2021 um 00:51:51 Uhr
Goto Top
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
Mitglied: aqui
aqui 15.09.2021 um 08:28:41 Uhr
Goto Top
Welchen "Fehler" hast du denn jetzt noch ??
Mitglied: fnbalu
fnbalu 17.09.2021 um 01:23:04 Uhr
Goto Top
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.
Mitglied: aqui
aqui 17.09.2021 um 10:21:50 Uhr
Goto Top
Könntest du mal eine Layer 3 Skizze des Setups posten ? Dann kann man das im Labor mal testen.
Mitglied: fnbalu
fnbalu 17.09.2021 um 11:49:46 Uhr
Goto Top
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
Mitglied: aqui
aqui 17.09.2021 aktualisiert um 13:11:22 Uhr
Goto Top
Das ist so etwas wie im Startpost oder?
Ja, die Zeichung reicht.... face-wink
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 ?
Sprich also wenn man die 94.16.x.y mit HTTP anspricht das es auf einem Web Server 192.168.1.100 landet ?!
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...
Mitglied: fnbalu
fnbalu 17.09.2021 um 20:26:10 Uhr
Goto Top
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.
Mitglied: aqui
aqui 18.09.2021 um 11:10:52 Uhr
Goto Top
Ich würde das über den VPS Natten lassen.
Das machst du ja so oder so immer wenn du dort mit Port Forwarding arbeitest ! face-wink
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.
Mitglied: fnbalu
fnbalu 18.09.2021 um 12:48:31 Uhr
Goto Top
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?
Mitglied: aqui
aqui 18.09.2021 um 19:37:58 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 18.09.2021 um 21:12:09 Uhr
Goto Top
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.
Mitglied: aqui
aqui 19.09.2021 um 11:08:35 Uhr
Goto Top
Sollte eigentlich, denn das ist ja auch ein SSL basiertes VPN !
Mitglied: aqui
Lösung aqui 19.09.2021, aktualisiert am 12.10.2021 um 10:48:18 Uhr
Goto Top
So, hier die OpenVPN Variante mit der es, wie zu erwarten, fehlerfrei klappt...zumindestens "fast" fehlerfrei... face-wink

back-to-topTestaufbau:

ovpn-forward

back-to-topSetup OVPN Serverseite mit Port Forwarding:

ovpn2
OpenVPN Tunnel zur pfsense-2 up an running...
ovpn3
Routing Tabelle:
ovpn4

back-to-topSniffer Trace der NAT Pakete Serverseite:

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

back-to-topWarum es nicht klappen kann...

Zeigt dann ein Wireshark Trace am Webserver:

shark
(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... face-sad

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.
Mitglied: fnbalu
fnbalu 19.09.2021 um 20:53:10 Uhr
Goto Top
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)
Mitglied: aqui
aqui 20.09.2021, aktualisiert am 21.09.2021 um 12:03:15 Uhr
Goto Top
Es kommt sogar noch schlimmer.... face-sad
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:

ovpn-wan2

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.
ovpn-wan1

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 ! face-wink
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. face-wink
Mitglied: fnbalu
fnbalu 20.09.2021 um 11:11:45 Uhr
Goto Top
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.
Mitglied: aqui
aqui 20.09.2021 um 12:37:51 Uhr
Goto Top
Ich hätte auch gerne mein T weiter gehabt.
Zu der Erkenntnis kommen 99% der Nutzer... face-wink
Aber BINAT wird dich retten... face-wink
Mitglied: fnbalu
fnbalu 20.09.2021 um 15:19:35 Uhr
Goto Top
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
Mitglied: aqui
aqui 20.09.2021 um 17:55:48 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 20.09.2021 um 22:23:42 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 20.09.2021 aktualisiert um 23:14:57 Uhr
Goto Top
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?
Mitglied: aqui
aqui 20.09.2021 aktualisiert um 23:17:39 Uhr
Goto Top
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: https://administrator.de/tutorial/cisco-mikrotik-pfsense-vpn-standort-ve ...
Das wäre in der Tat nochmal einen Versuch wert.
Mitglied: fnbalu
fnbalu 20.09.2021 aktualisiert um 23:55:38 Uhr
Goto Top
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?
Mitglied: aqui
aqui 21.09.2021 aktualisiert um 10:14:38 Uhr
Goto Top
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. face-wink
Eigentlich ganz easy... face-wink
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.
Mitglied: fnbalu
fnbalu 21.09.2021 aktualisiert um 21:21:31 Uhr
Goto Top
...
Mitglied: fnbalu
fnbalu 21.09.2021 um 11:54:01 Uhr
Goto Top
Zitat von @aqui:

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. face-wink
Eigentlich ganz easy... face-wink


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?
Mitglied: aqui
aqui 21.09.2021 aktualisiert um 12:04:25 Uhr
Goto Top
WARUM sendest du Posts 2mal ??? face-sad
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.
Mitglied: fnbalu
fnbalu 21.09.2021 um 14:56:29 Uhr
Goto Top
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
Mitglied: aqui
aqui 21.09.2021 um 20:22:33 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 21.09.2021 aktualisiert um 22:06:42 Uhr
Goto Top
Ging leider nicht mehr zu löschen der Doppelpost, sorry. Nun ist er mehr oder minder unkenntlich.


11-1-1_nat

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?
Mitglied: colinardo
Lösung colinardo 22.09.2021, aktualisiert am 23.09.2021 um 16:37:47 Uhr
Goto Top
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:

  • 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

back-to-topDSTNAT:

screenshot

back-to-topOUTBOUND NAT

screenshot

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

screenshot

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
Mitglied: fnbalu
fnbalu 22.09.2021 aktualisiert um 14:28:01 Uhr
Goto Top
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.
Mitglied: colinardo
colinardo 22.09.2021 aktualisiert um 13:34:47 Uhr
Goto Top
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.

Jawoll, das fliegt.
👍
Mitglied: aqui
aqui 22.09.2021 aktualisiert um 15:53:31 Uhr
Goto Top
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 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 !!! 😉
Mitglied: fnbalu
fnbalu 22.09.2021 um 15:30:18 Uhr
Goto Top
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?
Mitglied: aqui
aqui 22.09.2021 aktualisiert um 15:58:35 Uhr
Goto Top
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 ?! face-wink
Mitglied: colinardo
colinardo 22.09.2021 aktualisiert um 15:58:04 Uhr
Goto Top
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.

screenshot
Mitglied: fnbalu
fnbalu 22.09.2021 aktualisiert um 16:07:12 Uhr
Goto Top
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.
Mitglied: colinardo
colinardo 22.09.2021 aktualisiert um 16:16:34 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 22.09.2021 um 16:22:53 Uhr
Goto Top
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
Mitglied: colinardo
colinardo 22.09.2021 aktualisiert um 16:29:19 Uhr
Goto Top
Zitat von @fnbalu:
Also meinst lieber OpenVPN auch auslagern?
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.
Mitglied: fnbalu
fnbalu 22.09.2021 um 16:43:19 Uhr
Goto Top
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
Mitglied: aqui
aqui 22.09.2021 um 19:39:22 Uhr
Goto Top
Das dann aber über IPv6 direkt zu mir
Wenn du feste v6 WAN IPs hast reicht dafür dann einfache Transportverschlüselung mit IPsec.
Mitglied: fnbalu
fnbalu 22.09.2021 um 19:55:01 Uhr
Goto Top
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
Mitglied: aqui
aqui 22.09.2021 aktualisiert um 20:10:19 Uhr
Goto Top
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.
Mitglied: fnbalu
fnbalu 22.09.2021 aktualisiert um 22:05:06 Uhr
Goto Top
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
Mitglied: fnbalu
fnbalu 23.09.2021 um 00:51:07 Uhr
Goto Top
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.
Mitglied: aqui
aqui 23.09.2021 aktualisiert um 09:22:55 Uhr
Goto Top
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 /64
Danach 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...?!
Mitglied: fnbalu
fnbalu 23.09.2021 um 10:46:12 Uhr
Goto Top
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
Mitglied: colinardo
colinardo 23.09.2021 aktualisiert um 13:04:24 Uhr
Goto Top
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.
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.

screenshot

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
Mitglied: fnbalu
fnbalu 23.09.2021 um 15:49:23 Uhr
Goto Top
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
Mitglied: colinardo
colinardo 23.09.2021 aktualisiert um 16:02:06 Uhr
Goto Top
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

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 1300
mssfix 1300

Paket-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.
Mitglied: aqui
aqui 23.09.2021 um 22:59:28 Uhr
Goto Top
...und besser einen neuen Thread dafür eröffnen wie Kollege @colinardo schon angemerkt hat. face-wink