Ich habe seit Jahren eine Opnsense im Einsatz. Der jetzige Versionsstand ist: 25.1.10.
Darauf sind OpenVPN-Server (legacy - Port 1194 + 1195) konfiguriert für den Zugang in das interne Netzwerk (10.1.1.0/24). Das funktioniert.
Nun bestand die Aufgabe, einen zweiten Standort anzubinden. Weil die legacy Server/Client bald auslaufen, sollte das mittels Instancess gelöst werden.
In der Zweigstelle kommt auch eine Opnsense mit gleichem Versionsstand und Hardware zum Einsatz. Bis hierhin bin ich gekommen.
Mir gehen die Ideen aus und ich benötige Hilfe von Euch.
Folgendes Setup liegt vor:
Server-Seite:
- Hostname: fw01
- Server-LAN: 10.1.1.0/24
- WAN: static 192.168.0.2/24
- Portforwarding auf fw01
- public-IP: meineip.ddns.net
- Instancess OpenVPN
- Role: Server
- Protokoll: UDP
- Typ: TUN
- Port: 1196
- Bind adress: WAN-IP
- Server (IPv4): 172.16.70.0/24
- Netzstruktur: subnet
- Nutzung von Zertifikaten und TLS-Key
- lokales Netzwerk: 10.1.1.0/24
- Entferntes Netzwerk: 10.1.2.0/24
- Client-spezifische Konfiguration OpenVPN
- IPv4 Tunnel-Netzwerk: 172.16.70.2/32 //damit die fw02 immer die gleiche IP bekommt
- lokales Netzwerk: 10.1.1.0/24
- Entferntes Netzwerk: 10.1.2.0/24
- Firewall
- LAN: Richtung In und OUT: IPv4, Quelle, Port, Ziel, Port, Gateway - Erlauben und alles *
- OpenVPN: Richtung In und OUT: IPv4, Quelle, Port, Ziel, Port, Gateway - Erlauben und alles *
- Bei allen Rule ist das Monitoring aktiv (Protokolliere Pakete die von dieser Regel behandelt werden).
- NAT: kein
- Route, durch OpenVPN automatisch gesetzt
- Ziel 10.1.2.0/24 GW 172.16.70.2 Schnittstelle ovpns4
Client-Seite:
- Hostname: fw02
- Client-LAN: 10.1.2.0/24
- WAN: DHCP vom Router
- Instancess OpenVPN
- Role: Client
- Protokoll: UDP
- Port: 1196
- Typ: TUN
- Remote: meineip.ddns.net:1196
- Nutzung von Zertifikaten und TLS-Key
- lokales Netzwerk: 10.1.2.0/24
- Entferntes Netzwerk: 10.1.1.0/24
- Firewall
- LAN: Richtung In und OUT: IPv4, Quelle, Port, Ziel, Port, Gateway - Erlauben und alles *
- OpenVPN: Richtung In und OUT: IPv4, Quelle, Port, Ziel, Port, Gateway - Erlauben und alles *
- Bei allen Rule ist das Monitoring aktiv (Protokolliere Pakete die von dieser Regel behandelt werden).
- NAT
- Ausgehend: Schnittstelle OpenVPN, Quelle 10.1.2.0/24, *, *,* , Schnittstellenadresse, *, NEIN
- Route, durch OpenVPN automatisch gesetzt
- Ziel 10.1.1.0/24 GW 172.16.70.1 Schnittstelle ovpnc1
Ist-Zustand:
- Verbindung wird aufgebaut und ist erfolgreich
- Routen werden angelegt
- Server-Seite (fw01)
- Von der Firewall fw01, Quell-IP: 172.16.70.1 ist die Gegenstelle 172.16.70.2 erreichbar
- Alles andere nicht (10.1.2.0/24).
- Aus dem 10.1.1.0/24 sind 172.16.70.1 + 2 erreichbar, jedoch nicht 10.1.2.0/24
- tcpdump -i ovpns4 zeigt, dass die Anforderungen auf der Schnittstelle ovpns4 ankommen
- Die Firewall zeigt keine verworfene Pakete an
- Client-Seite (fw02)
- Alles erreichbar auf der Gegenstelle, wenn NAT ausgehend aktiv ist.
- tcpdump -i ovpnc1 zeigt, dass keine Pakete aus dem 10.1.1.0/24 auf der Schnittstelle ocpnc1 ankommen, nur die mit der Quell-IP 172.16.70.1.
- Wenn NAT ausgehend nicht aktiv, dann erreichbar (172.16.70.1, 10.1.1.0/24) von der fw02 aus, aus 10.1.2.0/24 ist 172.16.70.1 + 2 erreichbar, jedoch nicht 10.1.1.0/24.
- Die Firewall zeigt keine verworfene Pakete an.
Soll-Zustand:
- 10.1.1.0/24 und 10.1.2.0/24 sollen aufeinander zugreifen können.
Danke JeGr für die Vorlage.
Hauptstelle FW1
WAN / Internet
:
: PPPoe-Provider
:
.-----+-----.
| Gateway | Router mit meineip.ddns.net als public-ip und Portforwarding 1196 -- 1196 auf 192.168.0.2
'-----+-----'
|
WAN | IP 192.168.0.2
|
.-----+------.
| OPNsense | VPN-IP 172.16.70.1
'-----+------'
|
LAN | IP 10.1.1.1/24
|
.-----+------.
| LAN-Switch |
'-----+------'
|
...-----+------... (Clients/Servers)
Zweigstelle FW2
WAN / Internet
:
: PPPoe-Provider
:
.-----+-----.
| Gateway | Router
'-----+-----'
|
WAN | IP 192.168.1.2
|
.-----+------.
| OPNsense | VPN-IP 172.16.70.2
'-----+------'
|
LAN | IP 10.1.2.1/24
|
.-----+------.
| LAN-Switch |
'-----+------'
|
...-----+------... (Clients/Servers)
Danke schön.
Quote from: hartmut.schulz on July 07, 2025, 07:31:26 PM- Client-spezifische Konfiguration OpenVPN
- IPv4 Tunnel-Netzwerk: 172.16.70.2/32
Da sollte meines Wissens dieselbe Subnetzmaske wie in der Serverkonfiguration verwendet werden.
Ob das nun die Ursache des Problems ist, bin ich nicht sicher. Auf jeden Fall deutet das Fehlerbild darauf hin, dass der CSO nicht funktioniert.
Die Idee dahinter war, dass der Client die 172.16.70.2 bekommt. Auch eine Abänderung zu 172.16.70.2/24 ändert leider nichts, eben getestet.
Quote from: hartmut.schulz on July 07, 2025, 08:29:53 PMDie Idee dahinter war, dass der Client die 172.16.70.2 bekommt. Auch eine Abänderung zu 172.16.70.2/24 ändert leider nichts
Diese IP sollte er auch damit bekommen und ist meines Wissens die richtige Konfiguration.
Ich vermeide es allerdings, gleich die erstbeste IP im CSO zu setzen, wenngleich es damit auch funktionieren sollte.
Aber eventuell wird der CSO gar nicht angewandt. Das sollte im Server Log ausfindig zu machen sein.
Falls nicht, kontrolliere, ob der Name im CSO wirklich zum CN im Zertifikat bzw. zum Clientnamen passt, je nachdem, worauf geprüft wird.
Es wird der gleiche Name verwendet, im CSO (Client-spezifische Konfiguration), Zertifikate (Bezeichnung/CN) und auch auf der Client-Seite.
Im Server-log seh ich keine diesbezüglichen Hinweise. Ich hab die CSO deaktiviert. Das Resultat ist das Gleiche.
Quote from: hartmut.schulz on July 07, 2025, 09:12:20 PMIm Server-log seh ich keine diesbezüglichen Hinweise.
Dann solltest du da etwas vermissen.
OpenVPN loggt diesbezüglich nur, wenn es ein CSO zutrifft und angewendet wird. Dass ein CSO nicht zutrifft, ist der Regelfall und wird nicht geloggt. Was auch?
Du musst aber schon den Debug-Modus einstellen, damit das Anwenden des Client-Files im Log angezeigt wird.
Ok,
ich hab jetzt den log auf Serverseite auf 9 (debug) gestellt.
Ich kann immer noch nichts ungewöhnliches erkennen. Naja, es ist ja auch ziemlich lang. :) Wenn Du mir bitte sagen würdest, nach was ich konkret suchen soll, kann ich es posten.
Wie vorher schon geschrieben, habe ich die Client-spezifische Konfiguration deaktiviert, weil es sich gezeigt hatte, das es keinen Unterschied macht im Endergebnis macht, und je weniger aktiv ist, ... :)
Und auch danke für Deine Zeit, die Du hier investierst...
Probiere mal - Bind adress: WAN-IP durch - Bind adress: zu ersetzen. Also das der Server für alle Interfaces arbeitet.
Moin,
hab Bind adress nun frei gelassen.
Keine Änderung.
Ich bin eine Woche unterwegs. Kann also nicht testen.
Okay, habe eben auf meinem Server das Log nach einem Eintrag bez. CSO durchsucht. Viel ist es wirklich nicht, was OPNsense da loggt.
Es findet sich lediglich der Eintrag
Notice openvpn client config created @ /tmp/openvpn_cc_d28e46333bf32c2530776a3e3227a36.tmp
Aber dennoch ist dies ein eindeutiger Hinweis, dass der Client erkannt und der CSO angewendet wurde.
Jedoch musst du die Client-spezifische Konfiguration schon wieder aktivieren, um einen Eintrag finden zu können.
Es wird sich, wie erwähnt, kein verdächtiger Eintrag finden, wenn der CSO nicht zutrifft. Ist da nichts, passt etwas mit der Konfiguration nicht.
Hi,
das ist, was ich finden konnte nach der Aktivierung der Client-Spezifischen Konfiguration
2025-07-17T11:56:18 Error openvpn_server4 MULTI: problem deleting temporary file: /tmp/openvpn_cc_2317fd6b03fac2be118a949dddd4d221.tmp
2025-07-17T11:56:18 Notice openvpn_server4 TEST FILE '/tmp/openvpn_cc_2317fd6b03fac2be118a949dddd4d221.tmp'
Das wird mir jedoch auch ausgegeben, wenn die CS-Konfiguration nicht aktiviert ist. Da taucht nur zusätzlich meine public-IP auf, von der ich mich auf die FW verbinde...
openvpn_server4 HOME2HQ/11.11.11.11:38034 MULTI: oder halt TEST FILE
Bei beiden Szenarien wird das alle 2' ausgegeben...
So wie sich das für mich darlegt, ist die Client-Spezifische Konfiguration umsonst. Sie ändert in dieser Konfiguration nichts am Ergebnis... Leider.