Portweiterleitung durch OpenVPN

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.