OpenVPN Serverkonfiguration Instance (new)

[RES217AIII]

1. Benutz mal tcpdump und schau dir die Pakete auf Port 1199 an.

2. Eine weitere Möglichkeit ist, 127.0.0.1 als Bind Address für den Server einzutragen und eine eingehende NAT Port Forward Regel anzulegen. Eine bewährte Methode, eine stabile Adresse für einen Dienst zu bekommen.

Source: any
Destination: WAN address
Source port: any
Destination port: 1199
Protocol UDP
Redirection target: 127.0.0.1:1199
Associated firewall rule: pass

Leider komme ich nicht weiter!
Nach meinen oberflächlichen Verständnis des Problems vermute ich das Problem in meiner Konfiguration der Instance (new) unter dem Punkt "Bind adress".

zu 1. Nach tcpdump (vorausgesetzt meine Syntax ist korrekt) kommt nur eine Rückmeldung von der "falschen" Schnittstelle, der LAN Schnittstelle, und nicht von der WAN Schnittelle (vlan01, TAG 7, auf igb1)

zu 2. Mehrfach in verschiedensten Varianten versucht. Dabei unter anderem auch Server legacy abgeschaltet, gelöscht, um Überschneidungen auszuschliessen, Firewall Regeln nur noch auf ein "Alles- darf- durch" eingestampft etc.

Hat jemand eine funktionierende Konfiguration mit dynDNS mit der neuen Instanz?

Ich bin sehr dankbar, wenn diejenige oder derjenige, mir die notwendigen Einstellungen mitteilen könnte, aber auch als Beleg, dass es mit dynDNS funktioniert.

Wenn meine Posts oder Logs missverständlich sind, möge man mir das verzeihen. Ich freue mich auf Tips wie ich das besser und verständlicher machen kann.

[Patrick M. Hausen]

zu 1. Nach tcpdump (vorausgesetzt meine Syntax ist korrekt) kommt nur eine Rückmeldung von der "falschen" Schnittstelle, der LAN Schnittstelle, und nicht von der WAN Schnittelle (vlan01, TAG 7, auf igb1)

Warum werden die Antworten ausgehend nicht geNATet?

Edit: testest du etwa von deinem LAN aus? Das geht so nicht. Du musst dich zum Test auch von außen verbinden, sonst ist doch klar, dass die OPNsense die Antworten auf direktem Weg wieder ins LAN schickt.

Gruß
Patrick

[RES217AIII]

Edit: testest du etwa von deinem LAN aus? Das geht so nicht. Du musst dich zum Test auch von außen verbinden, sonst ist doch klar, dass die OPNsense die Antworten auf direktem Weg wieder ins LAN schickt.

Gruß
Patrick

Den Test habe ich per ssh auf der OPNsense durchgeführt.
Was heisst in diesem Fall von aussen verbinden?

[Patrick M. Hausen]

Mit einem OpenVPN Client über einen völlig anderen Internet-Anschluss, z.B. Mobilfunk, die Verbindung herstellen. Wenn der Client in deinem LAN ist, ist klar, dass Grütze rauskommt.

[RES217AIII]

Werde morgen von der Arbeit aus einen Test starten.
Nochmals vielen Dank für die Hilfe

Gruß
Bernd

[AES777GCM]

Es ist schlicht noch ein BUG beim schreiben der "Client Export" Datei: Wenn [new Instance] im Advanced Modus aufgerufen wird kann man ja u.a. die "Cipher" festlegen [AES GCM 128; AES GCM 256; CHACHAPOLY-1305] und auch die Fallback dazu.
!!Diese werden schlicht nicht als Parameter in die Client Export Datei geschreiben!!
!!Genauso wenig wird der "Fallback" und auch nicht die Kompressionsauswahl beim schreiben der Client Export Datei berücksichtigt!!

@Franco: Bitte nehmt euch dieser Thematik an. Erst nach händischem "data-ciphers CHACHA20-POLY1305" ergänzen in die config Datei funktioniert der (Testtunnel mit eben CHACHA...) zu einer "New Instance" tadellos.

[RES217AIII]

Folgender Stand:

Als aller Erstes:  Ich bekomme eine VPN Verbindung aufgebaut mit den Instance new!
Der Test von "aussen" war somit erfolgreich.

Die Ursache für meine Probleme kann ich nicht ins Derail analysieren.
Der Erfolg stellte sich ein, als ich igb1, auf dem mein VLAN für PPPOE läuft, deaktiviert habe.
Die Schnittstelle igb1 war als DHCP konfiguriert und erhielt ihre IP von dem Glasfasermodem der Telekom, damit ich zu Konfigurationszwecken darauf zugreifen konnte - etwas was ich ohnehin nicht nutzte.
Nach Deaktivierung kam sofort eine Verbindung zustande.

An alle die diese Konversation verfolgen:
Mit den neuen Instanzen ist problemlos und wie in der Dokumentation beschrieben eine Verbindung über dynDNS möglich!

Voraussetzung ist natürlich ein funktionierender ddclient, der mit OPNsense als backend mittlerweile zuverlässig läuft. Sicherlich zu Beginn der Umstellung auf 23.7 mein erstes Problem, weshalb kein OpenVPN Dienst funktionierte.

Wie so oft lag das Problem nicht an OPNsense, sondern an mir. Daher auf diesem Weg nochmals vielen Dank für die sehr gute Arbeit des OPNsense- Teams.
Danke aber auch an alle in dieser Konversation, die mir geholfen haben.

[RES217AIII]

  Danke