2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen
-
@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 64Wenn ich auf Wan umstelle, bleibt das Protokoll leer... :(
Somit stimmt was an der FireWall Regel nicht oder?
-
@waeck
Seite A war gefragt. Nur A. -
@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?
-
@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. -
@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
-
@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.99Bei 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.
-
@jegr
Hi jegrLeider 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
-
@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. -
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
-
@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
-
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 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