Messages

Moin,
hat 'ne Weile gedauert, jetzt habe ich die Lösung gefunden.
Es waren zwei Ursachen, einmal das Client-Zertifikat. Ich hatte vorher einiges ausprobiert und da war irgendwo noch ein Rest von einen Versuch, der das Zertifikat verwendete. Es gab da eine Duplikatswarnung in den Client-VPN-Log.
Und der andere Grund war, das CSO nicht gegriffen hat. Keine iroute und so. Deshalb ging es immer zum Teil, wenn CSO deaktiveirt wurde. Hab's deaktiviert und eine neue CSO aufgesetzt, alle NAT deaktiviert und siehe da: Es funktionierte.
Was ich festgestellt hatte: Scheinbar werden nicht alle Änderungen immer gleich übernommen und aktiviert. Auch die Services/Dienste auf der Konsole neu starten war nicht immer hilfreich.
Am sicherten und leider auch zeitraubender, war ein reboot. Achso, ich habe da zwei Opnsense mit der Version 25.1.10 verwendet.
Vielen Dank an alle, die mir hier geholfen haben.

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.

Moin,
hab  Bind adress nun frei gelassen.
Keine Änderung.
Ich bin eine Woche unterwegs. Kann also nicht testen.

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...

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.

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.

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.

Super, das war es. Danke schön. :)

Hi,
ich setze Opnsense 25.1.10-amd64 ein.
Ich habe einen User nur für die VPN-Einwahlangelegt. Leider finde ich keine Möglichkeit im "Benutzer bearbeiten" Dialog um diesen ein Zertifikat zuzuweisen. Bei den älteren Versionen gab es da ein Punkt dafür. OTP-SEED funktioniert
Eine Zertifizierungsstelle ist vorhanden. Ich kann dort Zertifikate für Einsatzmöglichkeiten erstellen.
Übersehe ich hier etwas? Wie weise ich den User ein Zertifikat zu?
Danke für Eure Hilfe.