Kein OpenVPN via pfsense seit 2.6.0 möglich

micneu

@ruddimaster ich habe ja auch die 2.6 am laufen und habe keine probleme mit openvpn. läuft wie es soll

wkn

Also ich habe den Upgrade von 2.5.2 auf 2.6.0 diese Mal mit einer Neuinstallation verknüpft, unter Verwendung der Config Recovery Option. OpenVPN lief vorher einwandfrei und tut das Gleiche nun auch.

JeGr

Da sich mit 2.6 an OpenVPN nichts Signifikantes geändert hat (ist immer noch openvpn-2.5.x, hat immer noch annähernd gleiche Config), kann ich das nicht so recht einordnen und ohne Logs gibts leider auch nichts Sinnvolles was man außer raten tun könnte.
Dafür haben die Logs ja auch ne Verbosity Einstellung etc. also vllt. mal auf 3 hoch wenn sie das nicht schon sind und genau reinschauen.

Ansonsten wäre hilfreich etwas mehr zu sagen als "kann ich nicht mehr aufbauen". Wenn die "Logs eigentlich gut aussehen" - woher kommt dann der Halbsatz davor? Entweder er baut sich auf - fein - oder nicht - dann gibts Logs. Beides geht irgendwie nicht.

Cheers

Ruddimaster

Vielen Dank für die Rückmelden.

Bei einer anderen pfSense in einer anderen Umgebung funktioniert der VPN auch nach einem Update von einem Rechner aus.

Der OpenVPN von der pfSense hat nicht s damit zu tun.

WAN / Internet
:
.-----+-----.
| pfsense | (Internet via NAT)
'-----+-----'
|

        |
  .-----+------.
  | Client     |       (mit OpenVPN)
  '-----+------'

Ich werde am nächsten Wochenende noch mal aktualisieren und das Loglevel erhöhen. Im laufenden Betrieb ist das ungünstig.

Gruss Dirk

orcape

@ruddimaster
Hi,
ich habe auf einer pfSense, die ich kürzlich auf 2.6.0 geupdatet habe, (APU-Board) mehrere OpenVPN-Server laufen und ja, ich habe seit dem Probleme, die ich in mehreren Einstellungsänderungen zu fixen versuche.
Alle hatten eines gemeinsam, die "net30-Topologie", die mir ein Routing der Tunnel untereinander eigentlich problemlos ermöglichte. Zum einen habe ich bei einem Tunnel sporadische Probleme, diesen laufen zu bewegen, zum anderen komme ich mit der nun befürworteten Subnetz-Topologie nicht mehr auf meine remoten Subnetz-Kameras.
Vielleicht sollte ich dies einmal so ändern, das ich nur einen OpenVPN-Server habe, der mir, im Subnetz alle Clients versorgt.
Bis Dato führten halt Änderungen an einem Tunnel oder Netzwerk, nicht zwangsläufig zum Totalausfall des Constructs.
Als Clients habe ich 2 x OpenWRT-Router, 2 x Debian-Laptops und ein Android-Handy.
Sinn des Routings, alles läuft über einen DSL-Hausanschluss als Server-Basis, per DynDNS erreichbar auf dem APU-Board und alles andere über LTE oder andere DSL-Anschlüsse eingeloggt.
Einer der OpenWRT-Router an einem DSL-Anschluss ermöglicht Rechnerupdates in diesem remoten Netz. Der andere OpenWRT-Router ist mit LTE-Stick ausgestattet und macht an dem Standort die Internetversorgung sowie eine Kamera-Überwachung möglich.
Sowohl von den beiden Linux-Laptops, wie dem Android Handy, sind dann Updates wie auch Kameraüberwachung möglich.
Na ja, nichts ist so beständig wie die Veränderung.

Gruß orcape

viragomann

@ruddimaster
Hallo,

ja, anscheinend interpretieren alle hier dein Problem falsch und vermuten den OpenVPN Server auf der pfSense selbst.

Grund, dass der Aufbau der VPN von einem Clietn innerhalb deines Netzwerks nach dem Update nicht mehr funktioniert, kann ja eigentlich nur sein, dass es die Firewall nicht erlaubt oder dass das Outbound NAT nicht funktioniert.

Die Logs sehen eigentlich gut aus.

Was heißt das? Welche Logs, die des Clients, die der Firewall?

Um die Firewall-Regeln zu troubleshooten, aktiviere das Logging in allen in Frage kommenden Regeln und die der Default Deny Regel und überprüfe das Firewall Log.
Wenn das in Ordnung ist, könntest du Packet Capture einsetzen, um die Pakete am internen und externen Interface zu überprüfen.

orcape

@viragomann
ich habe das auch gerade noch einmal gelesen. Stimmt natürlich, was Du da sagst.
Zumindest sollte ja auch der VPN-Port eine Portweiterleitung haben. Also die Logs der Firewall anschauen.
Gruß orcape

mike69

Moin.

Wenn ein Client im LAN eine VPN Verbindung aufbaut, benötigt es keine Portweiterleitung.

Ansonsten wie von @viragomann beschrieben, die Rules loggen lassen. und nachschauen.
Eventuell einen Logschnipsel vom Clienten im LAN (oder wo auch immer) hier posten.

Ruddimaster

Vielen Dank für die vielen Rückmeldungen. Ich werde am Wochenende loggen was geht...

Ruddimaster

Hallo,

Fehler gefunden. Nachdem ich gelogt habe, was ging und diese geprüft habe, konnte ich keinen Fehler feststelle. Höchstens Timeout am Client und
Mar 26 18:31:40 openvpn 34260 1.2.3.4:51606 SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 26 18:31:40 openvpn 34260 1.2.3.4:51606 TLS Error: TLS handshake failed
Mar 26 18:31:40 openvpn 34260 1.2.3.4:51606 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 26 18:31:31 openvpn 34260 1.2.3.4:22613 SIGUSR1[soft,tls-error] received, client-instance restarting

an der genüberliegenden pfsense. Per Komissar-Zufall wollte ich per threema einen Anrufen führen, der auch ins leere lief und das war der Hinweis.
https://forum.netgate.com/topic/169879/udp-icmp-is-not-working-after-upgrade-to-2-6-0

Sorry wenn ich hier Verwirrung gestiftet habe...

-Solved-