Public IPv4/IPv6 via VPN Tunnel

[viragomann]

Schon mal ein deutlicher Fortschritt.

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Was nicht über das Client VPN Gateway geht sind die Anfragen aus dem LAN, obwohl dieser ausgewählt ist in den Rules. Zumindest sehe ich keine Pakete auf dem Interface in die Richtung. :(
Müsste mal tcpdump auf dem VPS installieren und das da mal checken.

Dafür hast du ja die Policy Routing Regel.
Du hast oben geschrieben, die Pakete gehen zum WAN raus. Ist das immer noch der Fall?

Damit diese Regel nicht angewandt wird, müsste eine dieser Bedingungen erfüllt sein:

• die Regelparameter treffen nicht zu (Kombi aus Interface, Protocol, Source IP u. Port, Dest. IP u. Port)
• das gesetzte Interface ist down

Das lässt sich leicht überprüfen. Dafür auch die Empfehlung oben schon, den Regeln eindeutige Beschreibungen zu geben und das Logging zu aktivieren. Dann kannst du im Log nachsehen, welche Regel den Traffic erlaubt hat.

Wenn die Policy Routing Regel ihre Funktion erfüllt, ist dann noch die Masquerading Regel am VPS verantwortlich, dass die Paket richtig genattet werden. Funktioniert diese nicht, das Policy Routing jedoch schon, schlägt aber die Verbindung total fehl.

[Bob.Dig]

Gratuliere Jungs.

[mike69]

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Dafür hast du ja die Policy Routing Regel.
Du hast oben geschrieben, die Pakete gehen zum WAN raus. Ist das immer noch der Fall?

Ja.
Der Check mit tcpdump auf dem VPS erkennt kein Traffic, weder auf tun0 noch auf dem anderen env192.

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Damit diese Regel nicht angewandt wird, müsste eine dieser Bedingungen erfüllt sein:

die Regelparameter treffen nicht zu (Kombi aus Interface, Protocol, Source IP u. Port, Dest. IP u. Port)
das gesetzte Interface ist down

Interface ist up

Hier nochmal die aktuellen Screenshots der Rules.

OVPN Server:

OVPN Client:

TESTING Subnet:

GAMING Subnet:

VPN Client, Test- und Gamingsubnet sind alle allow any to any, da kann alles raus.
Die Firewallogs besagen, dass z. B. der Testhost beim Pingen das eigene Interface nutzt. :(

Witzigerweise nutzt die Playse beide Interfaces:

Langsam verstehe ich gar nichts mehr. :(

Edit:
Durch das "USER RULE (1614078764)" werde die Pakete von Gaming Richtung IONOS_VPN_WAN geschupst. 1614078764 ist die Tracking ID von der letzten Rule unter GAMING. Also ist das so richtig.

Edit2:
In den Rules steht zwar der IONOS_VPN_WAN Gateway drin, in den Einstellungen war das Feld leer. :(
Also neu auswählen, speichern, nun funzt es auch unter TESTING:

Eine schwere Geburt. :)

[mike69]

@bob-dig said in Public IPv4/IPv6 via VPN Tunnel:

Gratuliere Jungs.

Noch nicht ganz.

[viragomann]

@mike69
Hätte ja erstmal ein Packet Capture auf der pfSense am VPN-Interface gereicht, um zu sehen, ob die Pakete da raus gehen.

Mich verwirrt dass das VPN-Gateway auf TESTING "IONOS_VPN_VPNV4" heißt, während es auf GAMING "IONOS_VPN_WAN_VPNV4" heißt.
Kannst du mal abklären, woher die beiden Namen kommen? Welche Namen haben die Interfaces der VPN Instanzen?
Was findet sich in System > Routing > Gateways?

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Die Firewallogs besagen, dass z. B. der Testhost beim Pingen das eigene Interface nutzt. :(

Das Log zeigt das Interface, auf welchem die Regel definiert ist.

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Witzigerweise nutzt die Playse beide Interfaces:

Hier greifen offenbar zwei Regeln. Die mit dem Dreieck sollte eien ausgehende Floating Regel sein.

Das was in der Spalte "Rule" zu finden ist, ist die Beschreibung der Regel. "USER RULE" ist abgesehen von der ID leider die ganze Info, die das Log zeigen kann, wenn du den Regeln keine Beschreibungen spendierst. Wenn du so vehement meine Empfehlungen missachtest, kann ich leider auch nicht wirklich weiterhelfen.

Du kannst bestenfalls die ID der Regel verwenden, um weitere Details der Regel ausfindig zu machen. Kopiere diese, gehe auf Diagnostic > Command Prompt und füge sie folgendem Befehl an und führe ihn aus:

pfctl -vvsr | grep 

Einfach das in Execute Shell Command einfügen, die Regel ID hinten dran und ausführen.

[mike69]

Moin.

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Mich verwirrt dass das VPN-Gateway auf TESTING "IONOS_VPN_VPNV4" heißt, während es auf GAMING "IONOS_VPN_WAN_VPNV4" heißt.
Kannst du mal abklären, woher die beiden Namen kommen? Welche Namen haben die Interfaces der VPN Instanzen?
Was findet sich in System > Routing > Gateways?

Zur besseren Verdeutlichung habe ich die Bezeichnung des Interfaces im nach hinein auf IONOS_VPN_WAN geändert. Dabei nicht bedacht, in den Rules dieses Gateway explizit wieder auszuwählen.

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Das was in der Spalte "Rule" zu finden ist, ist die Beschreibung der Regel. "USER RULE" ist abgesehen von der ID leider die ganze Info, die das Log zeigen kann, wenn du den Regeln keine Beschreibungen spendierst. Wenn du so vehement meine Empfehlungen missachtest, kann ich leider auch nicht wirklich weiterhelfen.

Wieder vergessen, grummel...
Ist korrigiert, sieht jetzt so aus:

Hier die Details per pfctl:

pfctl -vvsr | grep  1000014215
@143(1000014215) pass out log inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"


pfctl -vvsr | grep 1613585273
@235(1613585273) pass in log quick on ix0.99 route-to (ovpnc2 10.8.0.1) inet from 10.0.99.0/24 to any flags S/SA keep state label "USER_RULE: Allow any  out over VPN"

Die Rule der PS4:

pfctl -vvsr | grep  1614078764


@197(1614078764) pass in log quick on ix0.50 route-to (ovpnc2 10.8.0.1) inet from 10.0.50.0/24 to any flags S/SA keep state label "USER_RULE: Allow any  over VPN"

Und hier sieht man die Nutzung des Tunnels:

root@test1:~# traceroute google.de

traceroute to google.de (216.58.206.227), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  19.627 ms  19.620 ms  19.951 ms
 2  10.255.255.2 (10.255.255.2)  20.022 ms  19.715 ms  19.685 ms
 3  93.90.196.13 (93.90.196.13)  73.348 ms  77.198 ms  81.149 ms
 4  ae-17.bb-b.bs.kae.de.oneandone.net (212.227.122.31)  21.604 ms  21.555 ms ae-1-0.bb-a.bap.rhr.de.oneandone.net (212.227.122.4)  20.540 ms
....

Sieht alles Tutti aus, oder?

[viragomann]

@mike69

Diese Floating Rule ist immer noch aktiv.

"let out anything IPv4 from firewall host itself"

Kannst du die mal deaktivieren? Ich in diesem Thread schon mehrmals erwähnt, dass keine Floating Regeln den Traffic erlauben dürfen.
Also noch einmal explizit für ausgehenden Traffic: Wenn du diesen unbeding regeln möchtest, verwende Block-Regeln da, wo sie Policy Routing Traffic betreffen.

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Und hier sieht man die Nutzung des Tunnels:
root@test1:~# traceroute google.de

traceroute to google.de (216.58.206.227), 30 hops max, 60 byte packets
1 10.8.0.1 (10.8.0.1) 19.627 ms 19.620 ms 19.951 ms
2 10.255.255.2 (10.255.255.2) 20.022 ms 19.715 ms 19.685 ms
3 93.90.196.13 (93.90.196.13) 73.348 ms 77.198 ms 81.149 ms
4 ae-17.bb-b.bs.kae.de.oneandone.net (212.227.122.31) 21.604 ms 21.555 ms ae-1-0.bb-a.bap.rhr.de.oneandone.net (212.227.122.4) 20.540 ms
....

Sieht alles Tutti aus, oder?

Ist es das nicht? Falls nicht, Packet Capture schon gemacht?

[mike69]

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Diese Floating Rule ist immer noch aktiv.

"let out anything IPv4 from firewall host itself"

Kannst du die mal deaktivieren? Ich in diesem Thread schon mehrmals erwähnt, dass keine Floating Regeln den Traffic erlauben dürfen.

Ja, hast du. Das ist die einzige hier auf WAN.

Und die war es.

Warum, geht mir nicht in den Schädel, deswegen blieb die Rule aktiv.

Sorry, @viragomann, für die Ignoranz, ist mir irgendwie... nicht ganz ersichtlich. Klar läuft alles über das WAN und dessen Gateway, da greifen die Floatingrules schon ganz "unten", mit als Erstes?

Sieht jetzt anders aus:

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Sieht alles Tutti aus, oder?

Ist es das nicht? Falls nicht, Packet Capture schon gemacht?

Eventuell gibt es noch Potential zum optimieren. :)
Es funktioniert alles, sogar mit der Floatingrule,

Danke nochmal für deine Geduld. Hast echt was gut.

[viragomann]

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Und die war es.
Warum, geht mir nicht in den Schädel, deswegen blieb die Rule aktiv.

Die Regel ID (Tracking ID) findest du auch, wenn du die Regel editierst, ganz unten.

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Eventuell gibt es noch Potential zum optimieren. :)

Na, dann gib Acht, dass du nichts veroptimierst.

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Danke nochmal für deine Geduld. Hast echt was gut.

Meine bevorzugte Marke ist Zwettler Original, falls die Frage aufkommt.

[mike69]

@viragomann

Adresse?

[viragomann]

@mike69

Lass gut sein, hab eh immer genug davon zuhause.

Ich habe aber immer noch meine DLNA Geschichte offen. Hattest du nicht mal erwähnt, du hättest hier Kompetenzen?

[mike69]

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Ich habe aber immer noch meine DLNA Geschichte offen. Hattest du nicht mal erwähnt, du hättest hier Kompetenzen?

Soweit, dass wir alles im gleichen Subnet laufen lassen. :)
Habe irgendwann aufgegeben, es übergreifend zu nutzen.
Du wolltest Netzwerkübergreifend das händeln? Wäre pimd eventuell ein Versuch wert? Ist in den Paketen hier enthalten.

[viragomann]

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Soweit, dass wir alles im gleichen Subnet laufen lassen. :)

Das wäre ja keine Herausforderung!

Allerdings wird mein TV niemals im Subnetz meines Servers sein.

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Wäre pimd eventuell ein Versuch wert?

Hast du also auch noch nicht versucht.

Vorgemerkt habe ich mir das Paket schon. Doch das macht mDNS und soweit ich mich an deine Worte errinnern kann, wäre das für DLNA nicht nötig.

DLNA über Router scheint ein harter Brocken zu sein. Im englischen Teil hier gab es vor ein paar Tagen auch eine Anfrage dazu, die bislang unbeantwortet ist.

[mike69]

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Allerdings wird mein TV niemals im Subnetz meines Servers sein

Hatte das damals mit VLAN auf dem Server gelöst. VLAN IF mit Zugriff auf TV Subnet.
War Sicherheitstechnisch auch Mist und der TV konnte eigendlich nichts richtig. Also eine kleine ARM Box geholt, Coreelec drauf und per Rule NFS auf den Server erlaubt. Somit war Ruhe und alles relativ "sauber" getrennt.

Dann kam MusicCast (Yamahas Antwort auf Sonos oder Denons Helios", Familie wollte mit Smartphones alles bedienen, Familienidylle ging vor, zack, alles in ein Subnet.

Nutzt Du VM? Kleines Linux Gastsystem drauf mit z.B. minidlna als DLNA Server in das TV Subnet und eine Freigabe auf den Mediaserver, smb oder nfs ist egal.

TV sieht nur den Gast und der kann nicht viel. :)

[viragomann]

@mike69
Der ganze Sinn der Sache wäre, eine Hand voll male pro Monat ein Video direkt vom Nextcloud Server schauen zu können, direkt am TV die ganze Auswahl zu haben und das File nicht erst auf einen Stick kopieren zu müssen.
Dafür lohnt sich eine Box nicht.

Mein Kodi-Projekt habe ich auch schon aufgegeben, Musik habe ich anders gelöst.
Da dachte ich mir eben am Server einen MiniDLNA zu installieren und den Zugriff auf die Videos zu geben.

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Kleines Linux Gastsystem drauf mit z.B. minidlna als DLNA Server in das TV Subnet und eine Freigabe auf den Mediaserver, smb oder nfs ist egal.

Das ist ein Tipp! Ja, ließe sich eventuell auch mit einem LXC lösen, der im TV-Netz ist.
Okay, das würde auf der pfSense wieder eine Bridge erfordern, weil TV WLAN und Server LAN.
Da frage ich mich, wenn schon Bridge, könnte ich doch gleich die DMZ (Server) mit dem TV-Netz bridgen und auf den Ineterfaces nur DLNA erlauben. Allerdings konnte ich bislang auch noch nicht in Erfahrung bringen, was das denn genau für Protokolle sind.

Aber danke mal für den Anstoß.

[mike69]

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Der ganze Sinn der Sache wäre, eine Hand voll male pro Monat ein Video direkt vom Nextcloud Server schauen zu können, direkt am TV die ganze Auswahl zu haben und das File nicht erst auf einen Stick kopieren zu müssen.
Dafür lohnt sich eine Box nicht

Die Box greift per NFS oder cifs auf de Server zu, kein Stick nötig. Coreelec ist eine minimal Linuxdistro für Amlogic Devices mit KODI als Mediaplayer. Für Intel und Co gibt es Libreelec, Coreelec ist ein Fork von Libreelec, die laufen echt geschmeidig. Und KODI frisst bis jetzt alles, brauchst nichts TV Konform umbauen. :)

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Okay, das würde auf der pfSense wieder eine Bridge erfordern, weil TV WLAN und Server LAN.

Jetzt wäre es an der Zeit, über Multi SSID Accesspoints nachzudenken. :)

Auf alle Fälle reicht eine Rule , damit der Gast auf den Server zugreifen kann. NFS nutzt soweit ich weiss UDP Port 111, mehr brauchst nicht öffnen.

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Aber danke mal für den Anstoß.

Ein Witz, gegenüber was Du ertragen musstest. :)

[viragomann]

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

brauchst nichts TV Konform umbauen. :)

Das Problem habe ich eh nicht. Daher will ich mir für die paar Videos keine Box hinstellen müssen.

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Jetzt wäre es an der Zeit, über Multi SSID Accesspoints nachzudenken. :)

Ist eh gegeben, aber das Bridging schreckt mich ab.
Ja, es existiert bereits eine zwischen LAN und einem WLAN. Ist für mich nicht schön.
Werde mir die Sache aber überlegen. Wenn es denn der einfachste Weg ist, der soweit auch sicher ist...

[mike69]

@viragomann said in Public IPv4/IPv6 via VPN Tunnel:

Ist eh gegeben, aber das Bridging schreckt mich ab.

Was meinst Du mit Bridging, Wlan und Lan zusammengefasst in ein IF?
Kenne deine Kette und Setup nicht, denke aber, dass Du mit VLan sergmentierte Netze hast.

Übrings, der Tunnel läuft stabil und beim Zocken sind keine Nachteile zu erkennen. Eventuell leicht hörerer Ping, das ist nur messbar wenn überhaupt.

[viragomann]

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Was meinst Du mit Bridging, Wlan und Lan zusammengefasst in ein IF?

Eine Bridge auf der pfSense ist eine verpönte Sache. Aber ja, ich habe der Bequemlichkeit halber ohnehin bereits eine zwischen LAN und einem WLAN-Segment.
Die Folge ist dann eben ein ungenutzer Tab mehr in den Firewall-Regeln.

Ich habe die Sache auf der To-do.

@mike69 said in Public IPv4/IPv6 via VPN Tunnel:

Übrings, der Tunnel läuft stabil und beim Zocken sind keine Nachteile zu erkennen. Eventuell leicht hörerer Ping, das ist nur messbar wenn überhaupt.

Fein. Toll, dass das alles problemlos drübergeht. Bei den Spielen war ich mir diesbezüglich zuvor nicht sicher, ob's funkt.