Portweiterleitung durch OpenVPN

[denndsd]

Hallo Zusammen,

ich benötige einmal Hilfe bei einem routing Problem.
folgender Aufbau:

Zuhause -- > Lokales Netz : 10.211.19.0/24 -- > FB -- > Unitymedia ISP

Frankfurt -- > Pfsense als VM auf VMware -- > ISP --> Internet

Ich habe einige Clients , welche von öffentlichen WLAN ihren Traffic durch den Tunnel schieben. MAcht ja sinn.
In diesem Fall ja auch mit NAT.
Da ich nun von zuhause einen festen Tunnel etablieren will, um auf die Ressourcen hinter dem Tunnel Netz zuzugreifen, habe ich mittels Openvpn und Raspberry PI eine Config erstellt und als Client auf der PFsense eingebunden.
virtual IP : 10.128.132.245

Das LAN Netz hinter der PFsense ist die 10.0.0.0/24
Soo. jetzt kommen wir zum spannenden Teil.
In den Client Overrides habe ich für den Client eine feste IP zugewiesen ( 10.128.132.245 ) und das Client Network eingetragen. (10.211.19.0/24)

Soweit so gut.
Jetzt will ich den Tunnel ohne NAT betreiben, weil geht ja auf die PErformance.
Also habe ich IP Forwarding im PI aktiviert und Firewall Regeln auf dem PI eingetragen.

sudo iptables -A FORWARD -i tun+ -o ens3 -m state --state RELATED,ESTABLISHED -j ACCEPT
 sudo iptables -A FORWARD -i ens3 -o tun0+ -m state --state RELATED,ESTABLISHED -j ACCEPT

Tunnel steht soweit. Nur es geht kein Traffic durch.
Auf der PFsense habe ich dann mal die routes angeschaut.
Dort fehlt die Client route (10.211.19.0/24)
In den Logs ist auch ein default drop ersichtlich. Ja gut, ohne Route kein Traffic. Ist klar. x)
Aktiviere ich NAT vom PI her, klappt alles ohne Probleme !
Ich bin dann hin und habe ein Gateway angelegt.
In diesem Fall Schnittstelle Opt1 mit der IP 10.128.132.245

Das klappt auch.
Nur wenn ich die Route anlegen will meckert er.

Das hab ich so noch nicht kapiert warum.
10.128.132.245 ist der Raspi bei mir, welcher in das Netz 10.211.19.0/24 routet.

Er müsste die Route doch eigentlich selber anlegen oder ?

HAt jemand eine Idee was da krumm ist ?

Besten Dank

Christian

[viragomann]

Hallo,

ja, die Route müsste durch OpenVPN bei Verbindungsherstellung gesetzt werden, wenn das Netz hinter dem Client im CSO richtig in "IPv4 Remote Network/s" eingetragen ist. Vielleicht das nochmal überprüfen.
Dann sollte es reichen, wenn der OpenVPN Server Instanz ein Interface zugewiesen ist. Mit statischen Routen sollte man da nichts machen.

Wenn die VPN Einstellung korrekt, aber die Route nicht da ist, überprüfe das OpenVPN Log. Da sollte der Versuch, die Route zu setzen eingetragen werden. Eventuell gibt es dabei Probleme.

Grüße

[denndsd]

Guten Abend,

Danke für die Rückmeldung.
Ich habe das ganze noch mal geprüft.
Eingetragen ist das ganze unter Remote Network.

Sauber in CIDR Schreibweise.
Dennoch nichts.
Muss ich eventuell an den Firewall Reglen noch spielen ?
Dort steht aktuell Interface OPT1 ( also das pOpenvpn) quelle 10.128.132.0/24 ( das Openvpn Netz) to any
Ich habe dann eine Regel hinzugefügt quelle 10.211.19.0/24 to any

Macht ja Sinn oder ?

[viragomann]

Mir fehlt in dem CSO das IPv4 Tunnel Network. Sinn eines CSO ist doch, dem Client eine spezifische IP zuzuweisen.

Ja, die Regel für die Quelle 10.211.19.0/24 ist nötig, nachdem nun ohne NAT die Pakete mit einer IP aus diesem Netz an der pfSense ankommen.

[denndsd]

Du meinst die statische IP im Tunnel Netz ?
Die habe ich unten in advanced mit ifconfig-push eingetraten.
Das hatte nicht so ganz funktioniert damit.

Ich habe gesehen unter Status --> Openvpn in der Routing Table hat er es jetzt eingetragen. Allerdings landen alle Pakete bei der Firewall.
Im firewall Log sehe ich aber auch kein default drop.

[viragomann]

Diese virtualisierte pfSense ist aber schon das Standardgateway in ihrem Netzwerk, oder?

Der Client bekommt nun auch die vorgegeben IP?

Wenn alles Logging aktiviert ist, in der Filterregel, wie auch das der Default-Regeln, sollten die Pakete doch zu sehen sein, durchgelassen oder geblockt.

[denndsd]

Genau,
villeicht kurz zu meiner Struktur.

Ich habe einen VMware ESXi mit einem v_Switch für die VMs.
Die PFsense ist als einzige an die Außenwelt verbunden und macht nach intern und extern das routing.
Ich habe die feste Tunnel IP anhand des Tunnel Network mal eingetragen und unter advanced alles rausgenommen.
Die Adresse wird sauber verteilt und von meinem lokalen PI komme ich auch soweit überall hin.
Allerdings nicht wenn ich von meinem lokalen Netz (10.211.19.0/24) komme.
Das läuft weiter ins leere.
Ich habe das Logging sowohl für die default Regel als auch für meine mal sniffen lassen.
Leider ohne erfolg.
Da ist nichts aufgeführt.

[viragomann]

Dann mach mal ein Packet Capture auf der pfSense am VPN Interface, um zu sehen, ob die Pakete überhaupt da richtig ankommen und wenn, ob es Antworten gibt.
Wenn ja, wäre selbiges am internen Interface interessant.

[denndsd]

Stimmt. Darauf bin ich noch nocht gekommen.

Okay, also hier einmal der Catpure auf dem internal interface

Wie wir sehen Pinge ich die 10.211.19.46 -- > entspricht die interne Adresse des Pis bei mir zuhause.

21:37:48.599846 IP 10.0.0.44 > 10.211.19.46: ICMP echo request, id 1, seq 11417, length 40
21:37:52.192404 IP 10.0.0.44.1195 > 130.158.6.115.5004: UDP, length 1
21:37:52.457645 IP 130.158.6.115.5004 > 10.0.0.44.1195: UDP, length 28
21:37:53.585173 IP 10.0.0.44 > 10.211.19.46: ICMP echo request, id 1, seq 11418, length 40
21:37:53.694412 IP 10.0.0.44.1195 > 130.158.6.115.5004: UDP, length 1
21:37:53.954575 IP 130.158.6.115.5004 > 10.0.0.44.1195: UDP, length 28
21:37:56.237346 IP 10.0.0.44.42087 > 130.158.6.113.5004: UDP, length 1
21:37:56.499290 IP 130.158.6.113.5004 > 10.0.0.44.42087: UDP, length 28
21:37:58.602327 IP 10.0.0.44 > 10.211.19.46: ICMP echo request, id 1, seq 11419, length 40

Mache ich das ganze mit dem VPN Interface kommt nix an.

also scheint das ganze irgendwo auf der FW unter zu gehen.

[viragomann]

Dann werden die Pakete entweder von der Firewall blockiert oder nicht in den VPN-Tunnel geroutet.
Ich befürchte letzteres. Aber um sicherzugehen würde ich nochmal die Firewall-Regeln überprüfen. Eventuell eine Floating Regel?
Aktiviere das Logging der Regel am internen Interface, die diesen Ping erlaubt, damit erkennbar ist, ob sie greift.

Bezüglich des Routings müsste die Route zum Netz hinter dem Pi auch in Diagnostic > Routes zu finden sein, mit der VPN-IP des Clients.

Ich bin allgemein kein großer Freund von solchen Multi-Purpose VPN Servern und würde für diese Site2Site einen eigenen VPN Server mit einem /30er Tunnelnetz konfigurieren, dann ist alles eindeutig und funktioniert auch anständig.

[denndsd]

Soo,

okay.
Ich habe das Logging auf den Regel einmal aktiviert.
Im Log sehe ich ein pass für diese User Regel.
Heißt durch geht es.
Da die Route aber auch nicht unter Diagnostic -- > Routes steht gehe ich mal davon aus das die FW die Route nicht sauber einträgt.
Was kann ich da in diesem Fall tun ?
Ich würde die Route ja manuell anlegen wollen.
Aber dazu brauche ich ja ein Gateway, was er in diesem Fall ja nicht akzeptiert.

[JeGr]

@denndsd said in Portweiterleitung durch OpenVPN:

Ich würde die Route ja manuell anlegen wollen.

Nein. Wenn bei OpenVPN die Route nicht in der Routing Tabelle auftaucht ist die Konfiguration nicht korrekt. Irgendwelche Routen dann manuell zu setzen bringt dann gar nichts außer Chaos und Unordnung wenn man Fehler sucht. Also dann erstmal die Konfiguration durchgehen, warum die Route nicht auftaucht. Wenn die fehlt, ist sie irgendwo vergessen worden mit einzutragen.

[viragomann]

@denndsd said in Portweiterleitung durch OpenVPN:

Was kann ich da in diesem Fall tun ?

Meine Empfehlung habe ich ja bereits gegeben: Trenne die Site-to-Site vom Access-Server. Richte also einen eigenen S2S-OpenVPN-Server für diese Verbindung ein, dann lässt sich alles schön sauber konfigurieren und du musst dich nicht mit CSO rumschlagen.

Grüße

[JeGr]

@viragomann said in Portweiterleitung durch OpenVPN:

Meine Empfehlung habe ich ja bereits gegeben: Trenne die Site-to-Site vom Access-Server. Richte also einen eigenen S2S-OpenVPN-Server für diese Verbindung ein, dann lässt sich alles schön sauber konfigurieren und du musst dich nicht mit CSO rumschlagen.

Was auch der empfohlene Fall aus multiplen Gründen ist :)

[pete35]

Routen im Openvpn ( remote Networks) werden manchmal nicht in die Routing Tabelle übernommen. Route löschen, neu starten, Route neu eintragen, neu speichern. Eventuell mal ein Space hinter der Route eingeben, neu speichern, openvpn neu starten. Irgendwann geht das dann. Ich hab das regelmäßig. Meine Vermutung ist, dass da aus der GUI etwas nicht richtig übertragen wird. Hab das auch schon mit dem Entwickler durchgekaut, die meinen alles in Ordnung. Tritt aber trotzdem immer wieder auf.

[JeGr]

@pete35 said in Portweiterleitung durch OpenVPN:

Hab das auch schon mit dem Entwickler durchgekaut, die meinen alles in Ordnung. Tritt aber trotzdem immer wieder auf.

Mag bei dir zutreffen, ich habe das in mehreren Installationen selbst und bei Kunden nicht als Problem. Was in der Konfig steht wird auch übernommen und wenn es dort fehlt, gibts auch keine (Rück)Route ;)

Problematisch sehe ich eher, dass hier Dial In und Tunnel gemixt wird, es hat seinen Grund waurm das 2 verschiedene Szenarien für OVPN sind. Daher sollte man es trennen und nicht vermischen und mit irgendwelchen Overrides versuchen hinzudeichseln. Dann läuft die Verbindung auch sauber :)

[viragomann]

Kenne das Problem auch nicht. Wenn die Route nicht gesetzt werden kann, obwohl in der Konfiguration angegeben, sollte im Log ein Hinweis zur Ursache zu finden sein.

Aber wie erwähnt, wenn anders möglich, richte ich auch keine Multi-Purpose Server ein.

[denndsd]

Hallo Zusammen,

vielen Dank für die vielen Antworten.
Ich werde das ganze am Wochenende mal trennen.
Das macht Sinn ja. :)
Aktuell komme ich nur nicht dazu, weshalb das ganze hier etwas eingeschlafen ist.
Bei einem anderen Peer klappts scheinbar.
Sehe merkwürdig.
Aber ja, trennen macht sinn.

Danke erstmal.