2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen

[waeck]

@viragomann said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Den Upstream Traffic des Alias sollte das mal über die VPN routen. Allerdings hast du den Hinweis "sämtlichen Upstream Traffic erfasst, aber nicht lokale Ziele" nicht beachtet. Möglicherweise braucht der TV aber auch keine lokalen Ziele zu erreichen. Standardmäßig bekommt er aber seinen DNS vom Router zugewiesen und das wäre die Router-IP, falls nicht anders konfiguriert.

Ok? Sorry, ich bin nicht (noch nicht??) soooo versiert in dieser pfSense Geschichte.
Wo genau muss ich dieses Ziel für DNS eintragen??
Z.B. 192.168.35.1/32 für den DNS (vom Router)?

Aber egal, du hast ja bereits einen RFC1918 Alias. So editiere die Regel und setze den RFC1918 als Ziel und mache einen Haken bei "invert match" (weiß nicht, wie das in der deutschen GUI genannt wird). Das hält die Regel davon ab, auf RFC1918 Ziele, also lokale zuzutreffen.

Ok. dies habe ich so angepasst.

Du hast auch eine ausgehende NAT Regel gesetzt. Das hatte ich gar nicht bedacht.
Ist aber auch nicht unbedingt nötig. Nötig ist aber eine entsprechende Regel auf der anderen Seite der VPN, Standort A am WAN. Je nachdem, ob du die NAT-Regel auf B belässt, musst du da die entsprechende Quelle in der Regel verwenden.
Also mit der NAT-Regel auf B muss die Quelle die Wireguard-IP von B sein. Wenn du die Regel von B entfernst (was ich tun würde), muss die Quelle das B-LAN Netz sein oder eben nur die IPs aus dem VPN-Alias, heißt also, denselben Alias anlegen und diesen als Quelle setzen.

OK. NAT ist ausgeschaltet.

Die Regel auf A muss also WAN sein.
Erst mal die Alias angelegt:

Hier die FireWall Regel:

Funktionierten tut es aber noch nicht... Ich denke da fehlt noch was?

Danke für deine Hilfe und Geduld.

gruss waeck

[viragomann]

@waeck said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Wo genau muss ich dieses Ziel für DNS eintragen??

Um das brauchst du dich nicht zu kümmern. Wenn System > DHCPv4 Server > LAN aktiviert ist, passiert der Rest automatisch.
Die Anmerkung war für den Fall gedacht, dass du da einen bestimmten DNS eingetragen hättest.
Ansonsten wird die pfSense LAN IP auf den Clients als DNS Server gesetzt.

Und mit dem "Nicht-RFC1918" in der Regel, trifft sie nun auf diese nicht mehr zu.

Die Regel auf A muss also WAN sein.

Ausgehende NAT-Regel war gemeint. Firewall > NAT > Ausgehend.
Hier erst mal den Hybrid-Modus aktivieren, falls Auto aktiv ist. Das sichern und eine Regel hinzufügen:
Schnittstelle: WAN
Quelle: Netzwerk > Alias eintragen
Ziel: alles
Translation: Schnittstellen-IP

Am WAN brauchst die keine Firewall-Regel, abgesehen von jener für die VPN.

[waeck]

@viragomann said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Ausgehende NAT-Regel war gemeint. Firewall > NAT > Ausgehend.
Hier erst mal den Hybrid-Modus aktivieren, falls Auto aktiv ist. Das sichern und eine Regel hinzufügen:
Schnittstelle: WAN
Quelle: Netzwerk > Alias eintragen
Ziel: alles
Translation: Schnittstellen-IP
Am WAN brauchst die keine Firewall-Regel, abgesehen von jener für die VPN.

OK. Firewall A habe ich die Regel wieder gelöscht.

pfSense habe ich das NAT auf Hybrid-Modus gesetzt
Und die Regel angepasst:

So habe ich die Nat Regel angepasst.

Somit habe nun die FireWall Regel auf LAN
Die NAT Hybrid_modus und die Nat Regel gesetzt.
Dies ist alles auf der Seite B.

Auf der Seite A habe ich nichts gemacht.
Ist dies so korrekt?

Funktioniert noch nicht... ich mache irgendwo einen mega Denkfehler... Mist.

[viragomann]

@waeck
Nein, ich habe doch geschrieben, die NAT-Regel muss auf A gesetzt gesetzt werden.

Auf B muss die ausgehende NAT-Regel am WGTR Interface entfernt werden.

[waeck]

@viragomann said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Auf B muss die ausgehende NAT-Regel am WGTR Interface entfernt werden.

Ups... Sorry. Ich stehe mir selber im Weg.

OK Standort B = Kein Nat (Normal über Automatische Erzeugung )

Standort A = Nat:

Standort A:
Somit habe nun die FireWall Regel auf LAN
Die NAT Automatische Erzeugung.

Dies ist alles auf der Seite B.
Keine FireWal Regel
Nat ist auf Hydride inkl. Regel.

Ist die IO?

Im Moment kann ich nicht surfen.

Stimmt meine RFC1918 (Alias) Regel? (Im Standort B:)

[viragomann]

Ja, ist soweit ok.

Auf A am WG Interface muss der Traffic nach "alles" erlaubt sein.

@waeck said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Im Moment kann ich nicht surfen.

Von wo?
A? B? Von B auf Rechnern / IPs, die im Alias liegen.

Stimmt meine RFC1918 (Alias) Regel? (Im Standort B:)

Ja.

Für die Ausgehenden braucht es manchmal einen Reboot, damit sie greifen.

[waeck]

@viragomann said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Ja, ist soweit ok.
Auf A am WG Interface muss der Traffic nach "alles" erlaubt sein.

Ja WG Interface hat alles erlaubt.
Seite A:

Im Moment kann ich nicht surfen.

Von wo?
A? B? Von B auf Rechnern / IPs, die im Alias liegen.

Als auf Seite A funktioniert alles "normal".

Auf Seite B:
Der hinterlegte Client hat kein Internet.
Die andern Clients haben Internet und kommen aus VPN.

Neustart habe ich bei beiden pfSense'n gemacht.

[viragomann]

@waeck
Ok, sollte damit laufen.
Es ist wohl an der Zeit, ein Troubleshooting zu starten.

Bist mit Diagnostic > Packet Capture vertraut?

Das soll auf A gemacht werden.
Schnittstelle auf das WG Interface setzen, Protokoll am besten auf ICMP (bspw. Ping), beim Host-Filter "8.8.8.8" eintragen und das Capture starten.
Dann von dem betroffenen Gerät in B einen Ping auf 8.8.8.8 schicken.
Dann das Capture stoppen. Die Pakete sollten angezeigt werden.

Wenn ok, dann die Schnittstelle aufs WAN stellen und damit dasselbe nochmal durchführen.

[waeck]

@viragomann said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Bist mit Diagnostic > Packet Capture vertraut?

:-) Natürlich nicht.
Ich beschäftige mich sein 1-2 Wochen mit pfSense... Mein Wissen über FireWalls hält sich also in Grenzen.

Die Erste abfrage auf der Seite B mit WG Schnittstellen ergibt:

21:21:41.714503 IP 192.168.35.10 > 8.8.8.8: ICMP echo request, id 18340, seq 0, length 64
21:21:42.720815 IP 192.168.35.10 > 8.8.8.8: ICMP echo request, id 18340, seq 1, length 64
21:21:43.727152 IP 192.168.35.10 > 8.8.8.8: ICMP echo request, id 18340, seq 2, length 64

Wenn ich auf Wan umstelle, bleibt das Protokoll leer... :(

Somit stimmt was an der FireWall Regel nicht oder?

[viragomann]

@waeck
Seite A war gefragt. Nur A.

[waeck]

@viragomann
Paketmitschnitt auf Seit A eingeschaltet auf Schnittstelle: WG
Von Seite B aus Ping abgesetzt.
Kein Resultat.

Paketmitschnitt auf Seit A eingeschaltet auf Schnittstelle: WAN
Von Seite B aus Ping abgesetzt.
21:17:23.242715 IP x.x.x.6 > 8.8.8.8: ICMP echo request, id 28646, seq 0, length 64
21:17:23.244987 IP 8.8.8.8 >x.x.x.6: ICMP echo reply, id 28646, seq 0, length 64

(x.x.x.6 = meine öffentliche IP. Ich denke die sollte ich hier nicht posten oder?)

Somit würde ich schätzen, dass der Ping über VPN kommt aber dort nicht weiter geht?

[viragomann]

@waeck
Wenn was über die VPN nach A kommt, sollten die Pakete auch auf der WG Schnittstelle zu finden sein.

Das, was du am WAN siehst, kann natürlich auch anders woher kommen. Es könnte bspw. das Gateway Monitoring von A sein.
Siehe Status > Gateways.
Wenn, dann hättest du das aber selbst gesetzt und solltest es wissen.

Das Monitoring könntest du zum Test in System > Routing > Gateways in den Einstellungen des WAN Gateways während des Tests auch abschalten. Oder du pingst eine andere öffentliche IP, von welcher du weißt, dass sie antwortet. Musst dann aber auch die Host-Filter im Packet Capture entsprechend ändern, um was sehen zu können.

In Status > Gateways siehst du auch das WG Gateway. Das muss jenes sein, das du in der Firewall Regel angegeben hast.
Apropos Firewall Regel, die sollte inzwischen auch schon was anderes unter "States" anzeigen als "0/0 B". Ist das so?
Falls nicht, kam sie gar nicht zur Anwendung.

[JeGr]

@waeck Kurze Zwischenfrage weil Komplexität so hoch:

Soll das Ganze generell für den Ferienstandort gebaut werden oder gehts da eigentlich nur um die AppleTV Büchse wegen Fernsehen?
Wenn TV: Kann der AppleTV nicht auch Apps installieren? Und wenn ja, gibts da ggf. Tailscale oder OpenVPN?

Ich frage nur deshalb: Wenn das ganze nur wegen den TV Boxen wie nem AppleTV ist und man damit dann eben über Land A/Standord A senden will wegen der IP, dann wäre für sowas sicherlich Tailscale oder OpenVPN Client an der Box am Einfachsten weil man dann nicht noch großartig ein Site2Site VPN mit irgendwelchen Regeln bauen muss, was mir augenscheinlich vielleicht ein wenig zu komplex ist? Zudem könnte man dann relativ schnell und simpel auch am Standort B zwischen lokaler IP und Land A IP wechseln indem man einfach im Player kurz die App an/ausmacht.

Und Tailscale könnte das ggf. einfacher, weil sich da die pfSense an Land A als Router/Endpoint anmelden und für alle Clients als Exit Node anbieten kann. Dann kann man das mit einem Switch an/aus schnell mal via A oder B laufen lassen.
Oder eben Alternativ: OVPN Einwahlserver nach ganz normalem Schema bauen mit Möglichkeit allen Traffic via VPN zu wuppern und dann einfach VPN Client+Config auf den AppleTV und go :)

Nur als Alternative mal eingeworfen, weil man dafür dann auch für Änderungen nicht immer an den Firewalls auf beiden Seiten rumbasteln muss :)

Cheers

[waeck]

@viragomann said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Wenn was über die VPN nach A kommt, sollten die Pakete auch auf der WG Schnittstelle zu finden sein.

Das, was du am WAN siehst, kann natürlich auch anders woher kommen. Es könnte bspw. das Gateway Monitoring von A sein.
Siehe Status > Gateways.
Wenn, dann hättest du das aber selbst gesetzt und solltest es wissen.

Hier sieht man folgendes: (Seite A)

Das Monitoring könntest du zum Test in System > Routing > Gateways in den Einstellungen des WAN Gateways während des Tests auch abschalten. Oder du pingst eine andere öffentliche IP, von welcher du weißt, dass sie antwortet. Musst dann aber auch die Host-Filter im Packet Capture entsprechend ändern, um was sehen zu können.

Ok. ich Pinge www.hostpress.de an.
78.46.126.99

Bei WG und bei WAN bleibt alles leer.

Somit kommen die Daten von B nicht zu A oder?

In Status > Gateways siehst du auch das WG Gateway. Das muss jenes sein, das du in der Firewall Regel angegeben hast.

Auch hie sehe ich kein grossen Traffic. Auch eher ein Zeichen dafür, dass nichts über VPN kommt oder?

Apropos Firewall Regel, die sollte inzwischen auch schon was anderes unter "States" anzeigen als "0/0 B". Ist das so?
Falls nicht, kam sie gar nicht zur Anwendung.

Hm...
Auf der Seite B sind par wenige Daten vorhanden.
Diese können aber auch daher kommen, da ich vom Geräte über VPN zur andern pfsense gegangen bin.

Muss ich beim VPN noch etwas mehr eintragen? z.B. 0.0.0.0/0 oder passe es so?

Danke für deine Hilfe.

[waeck]

@jegr
Hi jegr

Leider können die Apple TVs kein VPN.
Auch andere TV Boxen haben damit so ihre mühe.
Was gehen würde ist sogenannte „Smart DNS“.
Hier bräuchte ich aber einen externen Anbieter, den ich dafür bezahlen muss.
Meine Hardware habe ich e und meine 1GB Leitung im Standort A habe ich auch so oder so.

Somit bleibt mir wenig übrig.

Die VPN Geschichte ist aber auch nicht nur für TV interessant.
So kann ich auch „bewusst“ einzelne Geräte im Alias hinzufügen, die eben über VPN ins Interne gehen.
So kann ich die Örtlichen Zensuren von diversen Internet-Seiten umgehen.
Leider ist die „Pressefreiheit“ nicht in jedem Land die Freiheit, die sein sollte.

Somit wäre ich also sehr flexibel. Wenn ich es dann JEMALS hinbekomme. :-)

Die Komplexität bin ich mir schon irgendwie bewusst.
Ich möchte es aber gerne einrichten und danach möchte ich auch verstehen, warum es so funktioniert, wie es funktioniert. Ich möchte im kleinen Bereich damit umgehen können.

Solange ich hier Hilfe bekomme, was ich extrem schätze, werde ich es weiter verfolgen… :-)

Bei Tailscale bin ich meines Wissens auf „exrterne“ angewiesen. Das möchte ich nicht.
Ausserdem habe ich bei Wireguard den Vorteil, dass „nur“ Standort A den Port offen haben muss und Standort B eben nicht. Die dortigen Internet Anbieter lassen ein NAT kaum bis gar nicht zu.

Danke für einen Input.

Gruss waeck

[viragomann]

@waeck said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Ok. ich Pinge www.hostpress.de an.
78.46.126.99
Bei WG und bei WAN bleibt alles leer.
Somit kommen die Daten von B nicht zu A oder?

Wenn du diese IP auch als Host beim Packet Capture eingetragen hast bzw. das Feld leer ist und du im Ergebnis diese IP nicht findest, kommt offenbar nichts rüber.

Hier sieht man folgendes: (Seite A)

In Status > Gateways siehst du auch das WG Gateway. Das muss jenes sein, das du in der Firewall Regel angegeben hast.

Der Gateway Status von B wäre von Interesse gewesen. Die gefragte Firewall Regel (Policy Routing) ist ja auch jene von B. Auf A kann das Gateway natürlich anders heißen.

Auf der Seite B sind par wenige Daten vorhanden.
Diese können aber auch daher kommen, da ich vom Geräte über VPN zur andern pfsense gegangen bin.

Die Regel erfasst nur Verbindungen von B nach A und ausschließlich Ziele, die nicht im RFC1918 Alias enthalten sind!
Weiß nicht, ob du von B nach A zugegriffen hast, aber jedenfalls solltest du auf A keine IPs außerhalb von RFC 1918 im lokal Netzwerk verwenden.
Also nehme ich an, die Regel ist von Verbindungsversuchen zu öffentlichen IPs getriggert worden.
Die Daten am Zähler könnten aber auch aus der Zeit stammen, bevor du den Alias hinzugefügt hast. Da hätte die Regel auch für lokale IPs in A gegolten.
Kannst du noch beobachten, ob sich da nun noch was tut.

Aber ja, muss @JeGr Recht geben, mit OpenVPN ist das problemlos umsetzbar, schon einige male gemacht. Mit Tailscale habe ich noch keine Erfahrung.
Mit WG habe ich Policy Routing nicht konfiguriert, soweit ich mich erinnern kann. Den Netgate Docs folgend, wäre ich aber davon ausgegangen, dass es mit den Gateways ebenso machbar ist.

[waeck]

@viragomann

Erstmals vielen Dank für dein Hilfe.

Im Moment habe ich aber zwei Problem.
1 Problem:
1 x pfSense hat die Version 2.7.0-DEVELOPMENT
Diese schein noch Fehler zu haben oder Problem mit der Verbindung zu 2.6 zu haben.

Hie muss ich also warten, bis ich die 2.7 Final Version bekommen.
Leider erkennt die 2.6er Version meine 2.5 GB Netzwerkkarten im Mini PC nicht.

2 Problem:
Leider musste ich verstellen, dass ich vom A gar nicht nicht B über VPN kommen.
Von B nach A komme ich. Aber irgendwie ist die noch etwas wackelig...

Somit vertage ich meine Idee, werde.
Sobald die neuen Versionen Final sind, mache ich einen neuen Eintrag hier im Forum.

Aber so möchte ich eure wertvolle Zeit nicht one finalen Software verschwenden, da die Fehlerquellen ja sehr vielseitig sein können.

Bis dan...

Viele Grüss, waeck

[viragomann]

@waeck
Hallo,

warum nimmst du für die Zeit nicht OpenVPN?

Ich weiß nicht, ob es auf der 2.7 noch pre-shared Ley gibt. Das wäre eben so einfach wie WG, aber eine CA und Zertifikate auf der pfSense zu erstellen, ist ja auch keine große Herausforderung.
Und damit lässt es sich wunderbar routen.

Grüße

[waeck]

@viragomann

Hm... Dein Post hat mich diese Nacht etwas beschäftig. Ja warum eigentlich nicht.

Als erstes habe ich auf beiden Seiten 2.7.0-DEVELOPMENT installiert, da es wohl einfacher sein dürfte, wenn beides dieselbe Version haben.

Ich dachte dass bei OpenVPN S2S beide (Server und Client) eine Portfreigabe haben müssen. Dies ist nicht so... Nur der Server muss "offen" sein. Super! Somit kann ich dies problemlos brauchen / umsetzen.

Ok. ich habe mal kurz OpenVPN mit einem Peer to Peer Shared Key erstellt, weil es einfach ist und alles kurz eingerichtet.

Danach habe ich die "Anleitung" oben umgesetzt und beim ersten Versuch hat es sofort funktioniert.

Stellte ich meinen Mac (zum Testen) auf die gewünschte IP läuft aller Traffic über A.
Perfekt.

Vielen Dank also für den Tip und dein Hilfe!

Nur eins verstehe ich nicht ganz.

Warum habe ich keine Bewegung auf dem Firewall Regelt, die in A Wan ist:

Nach meinem Verständnis funktioniert die Geschichte wie folgt:
Seite B Regelt von LAN aus: Wenn eine IP kommt (Clients_ueber_VPN), die nicht ins Netzwerk RFC1918 will, gehe zum Gateway OpenVPN raus.

Das Gateway Open VPN schiebt es über den Tunnel auf die Seite A.
Seite A Regelt von WAN aus: Wenn etwas von der IP (Clients_ueber_VPN) kommt, lass es rein. (Aber da kommt keine Bewegung? Was ich eben nicht verstehe.)

Und zu Schluss sagt NAT:
Wenn etwas vom Wan kommt, mit der IP (Clients_ueber_VPN), dann gib es über die Seite A Wan raus inkl IP von A Wan.

Stimmt dies mehr oder weniger?

[waeck]

@waeck said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen:

Warum habe ich keine Bewegung auf dem Firewall Regelt, die in A Wan ist:

Ah... die Regel hat keine Bewegung, weil ich sie nicht brauche.
:-)

Ok. Dann funktioniert jetzt alles wie gewollt. DANKE an alle.

Gruss waeck