aber der nslookup nicht.

heißt was genau? Namensauflösung (die wäre doch lokal, was hat die dann mit dem VPN zu tun?) oder der Server auf der anderen Seite oder was ist da genau mit gemeint?

@ShaneDeak said in OpenVPN Problem nach Update:

Außerdem kann ich z.B. auf die Weboberfläche der pfSense B oder auf die von Proxmox nicht zugreifen (über die IP, welche aber eigentlich erreichbar ist).

Ohne Plan was wo wie miteinander verknotet ist, ist das schwer zu überschauen, was warum wo nicht geht. Da bräuchte ich dann wirklich mal nen Plan oder ne bessere Beschreibung zu.

Auf Windows-Freigaben kann ich auch nicht zugreifen.

Same, das mag für dich stimmig/sinnvoll klingen, ich weiß damit aber überhaupt nichts anzufangen, weil ich jetzt keine Ahnung mehr habe, was wo wie steht, wer mit wem versucht zu sprechen, worüber, wie das miteinander verdrahtet oder verbunden ist, etc.

Jetzt hast du noch irgendwie die Richtung/Server-Client umgedreht, jetzt versteh ich noch weniger.

Also gern Hilfe, aber dann bitte richtig, dann brauch ich entweder nen Plan oder zumindest eine wesentlich bessere Beschreibung was wo wie steht, was miteinander reden kann und was nicht und was wo konfiguriert ist. Ansonsten ist das leider eher stochern im Nebel.

Da wir gerade erst wieder einen Kunden hatten, der auf pfSense geswitcht ist und mit der aktuellen Plus 23.05.1 (also auf gleichem Stand wie 2.7) nen Office hinter einem RZ angehängt hat und dabei den Weg zwischen Office und RZ via Tunnel verbunden hat, kann ich sagen, dass das keinerlei Problem mit 2.7 ist - OpenVPN hat da problemlos gewuppt. In dem Fall sogar via MultiWAN über ne Backup Line falls die direkte Anbindung tot ist. Site2Site oder Site2Multisite ist also auch in den neuen Versionen kein Ding.

Meist liegt der Fehler da im Detail: es fehlt nen CSO, es fehlt ne Route, es gibt noch irgendwo nen herumschimmelndes IPsec das die Pakete wegfrisst weil die gleiche Route wie bei OVPN eingetragen ist etc. etc. Aber was es in deinem Fall genau ist - ohne bessere Draufsicht kaum zu sagen.

Cheers
\jens

Hallo Jens,
vielen Dank für deine Antwort!

In der Zwischenzeit habe ich das VPN noch mal neu angelegt und dabei die Seiten getauscht. Der VPN-Server steht also jetzt an Standort B und am Standort A läuft nur der Client. Nun funktioniert der Ping und auch TraceRoute beidseitig, aber ich habe andere seltsame Probleme.
Von B nach A funktioniert alles wunderbar. Von A nach B, funktioniert ein Ping an den FQDN zwar, aber der nslookup nicht. Außerdem kann ich z.B. auf die Weboberfläche der pfSense B oder auf die von Proxmox nicht zugreifen (über die IP, welche aber eigentlich erreichbar ist). Auf Windows-Freigaben kann ich auch nicht zugreifen.

Es wäre schön, wenn da noch jemand eine spontane Idee hat. Ansonsten werde ich wohl die pfSense A mal komplett neu installieren, um irgendwelche "mitgeschleppten" Fehler ausschließen zu können.

@ShaneDeak said in OpenVPN Problem nach Update:

Es ist aber tatsächlich so:
(Bild)

An der Stelle sagst du eindeutig, dass der erste HOP der Routenverfolgung die Fritte ist. NICHT die pfSense. Warum funktioniert dann die pfSense nicht korrekt wenn dein Client bei Ping an 10.10.10.1 statt an die Sense den Kram an die Fritte schickt? Verstehe ich nicht ganz.

Das sieht für mich eher aus, als hätte dein Client mit dem du auf Serverseite testest das falsche Gateway oder eigene Routen eingetragen, so dass 10.10.10.x an den falschen Router geht.

Okay, dann wird das Gateway im Tracerout offenbar nicht angezeigt.

Unter Windows gilt das normale Gesetzt: alles was nicht im Routing angezeigt wird, existiert nicht. Der erste Hop ist nicht plötzlich magisch die pfSense taucht aber nicht in der Ausgabe auf. Das gibts nicht. Da läuft dann was an dem Client gehörig schief oder es ist anderweitig irgendwas sehr seltsam im Netz (oder wir sind auf Layer 2 irgendwo an die Wand gelaufen und haben dort Konflikte), aber wenn als first HOP bei einem Routing nicht deine Sense die Frage beantwortet sondern jemand anderer, dann ist im Normalfall nicht die Sense das Problem.

Cheers
\jens

In dem Thread haben die ja das gleiche Problem und einer schreibt, dass selbst eine Neuinstallation nicht geholfen hat. Das kann dann ja lustig werden. Da kann ich ja gleich auf die 2.6 downgraden.

Habe ich so bislang noch nicht gesehen. Ich hatte eher ein Problem im OpenVPN Routing vermutet, was bei TLS und einem Tunnelnetz > /30 etwas komplizierter ist. Aber falls das zutreffen würde, gingen die Pakete bestenfalls ins Leere, jedoch nicht auf irgendein WAN Gateway, ohne entsprechender statischer Route oder Policy Routing.

Ja, ich würde da auch neu installieren.

Du kannst aber mit Packet Capture untersuchen, ob die Pakete am LAN der Client-Seite rauskommen, während du einen Zugriff von der Serverseite versuchst, bspw. ein Ping.

Die Pakete kommen laut Packet Capture gar nicht auf der Client-Seite an. Auf der Server-pfSense sieht es so aus:

11:30:17.939994 IP 192.168.123.150 > 10.10.10.1: ICMP echo request, id 1, seq 657, length 40
11:30:17.948766 IP 62.155.242.106 > 192.168.123.150: ICMP net 10.10.10.1 unreachable, length 36

Die 62er IP gehört irgendeinem Server der Telekom, da die pfSense den Ping über WAN2 dort hin schickt.

Es wird wohl darauf hinauslaufen, dass ich am Wochenende die pfSense noch mal komplett neu konfigurieren werde.

Nur kein einziger Rechner aus dem Server-Netz.

Vielleicht mögen diese das nicht und blockieren den Zugriff?
Würde mich jedoch wundern, dass es zuvor mit Preshared Key funktioniert haben soll (ohne Masquerading).

Du kannst aber mit Packet Capture untersuchen, ob die Pakete am LAN der Client-Seite rauskommen, während du einen Zugriff von der Serverseite versuchst, bspw. ein Ping.

Dennoch müsste aber die pfSense selbst das Client-Netz erreichen, bspw. mit Traceroute oder Ping von der LAN-IP als Quelle.

Die pfSense erreicht das Client-Netz schon. Nur kein einziger Rechner aus dem Server-Netz.

Standardgateway ist die pfSense:

Okay, dann wird das Gateway im Tracerout offenbar nicht angezeigt.
Habe gerade kein Windows, um das nachzuvollziehen.

Habe das Verbosity-Level auf 3 gesetzt und jetzt sind die entsprechenden Zeilen im Log.
Leider ändert sich aber nichts. Traceroute geht über die FritzBox am WAN2 raus.

Dann wäre ein Policy Routing wohl die letzte Erklärung für dieses Verhalten.
Dennoch müsste aber die pfSense selbst das Client-Netz erreichen, bspw. mit Traceroute oder Ping von der LAN-IP als Quelle.

Standardgateway ist die pfSense:

Routing-Tabelle am Windows-Rechner sieht so aus:

Habe das Verbosity-Level auf 3 gesetzt und jetzt sind die entsprechenden Zeilen im Log.

Leider ändert sich aber nichts. Traceroute geht über die FritzBox am WAN2 raus.

Es ist aber tatsächlich so:
1cf1a03a-215b-4f16-8d98-ec975afb3fca-image.png

Ich würde mir erwarten, die interne IP der pfSense als ersten Hop zu sehen. Ist doch das Standardgateway auf dem PC, oder?
Falls nicht, kann keine darauf eingerichtete Route bei der Verbindung helfen.
Also mal die Routing-Tabelle des Rechners überprüfen.

Habe auch noch mal überprüft, ob CSO richtig konfiguriert ist:
45aa9d64-8f18-45d6-bb15-f36b90cef4ea-image.png

Der Clientname, den du hier unkenntlich gemacht hast, ist auch im Log ersichtlich. Wenn du ihn nicht publizieren möchtest, musst du ihn auch dort entfernen.

Habe eben mit Versuchen herausgefunden, dass im Server zumindest der Verbosity-Level 3 gesetzt sein muss, damit die Verarbeitung des CSO geloggt wird. Hatte ich auch schon länger nicht mehr benötigt.

Dann sollten sich im Log solche Zeilen finden:

xxxx/1.1.1.1:38722 OPTIONS IMPORT: reading client specific options from: /var/etc/openvpn/serverx/csc/xxxxx 
MULTI: Learn: 10.10.10.0/24 -> xxxx/1.1.1.1:38722

Letztere zeigt, dass die Route zum Client-Netz innerhalb OpenVPN gesetzt wird.

Es ist aber tatsächlich so:

Habe auch noch mal überprüft, ob CSO richtig konfiguriert ist:

Muss man das irgendwie noch explizit pushen?

Hier auch noch ein Traceroute aus dem Client-Netz zum Server-Netz:

Funktioniert in die Richtung einwandfrei. Und unter der 2.6.0 hat es ja auch noch geklappt. Wenn auch mit Preshared Key.

Vielen Dank auf alle Fälle schon mal für deine Unterstützung!!!

Jedenfalls im OpenVPN Log findet sich kein Eintrag für CSO. Der muss angewandt werden, ist essentiell bei TLS, und falls, müsste sich ein Hinweis im Log finden.

Der Common Name im CSO muss jenen im Client SSLZertifikat entsprechen. Ansonsten braucht nur das Client-Netzwerk als "Entferntes Netzwerk" eingetragen zu werden.
In der Server-Konfiguration muss dieses ebenso eingetragen sein.

Wie?
Du hast einen OpenVPN Server laufen, da kannst du bestenfalls das Interface festlegen, an dem er auf eingehende Verbindungen wartet.
Du kannst zwar auch eine bestimmte Route für den Remote-Endpunkt festlegen, bringt aber nix, der Server stellt keine Verbindungen aktiv her.

Entschuldige, das stimmt natürlich: Ich habe WAN1 als Interface angegeben und nutze die feste IP der Internetverbindung die da dran hängt.

OpenVPN Konfiguration Server wie in der Doku (https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html). Dazu meine Anpassungen:
IPv4 Tunnel Network
192.168.101.0/24
IPv4 Local network(s)
192.168.123.0/24
IPv4 Remote network(s)
10.10.10.0/24

Client ebenfalls wie in der Doku. Dazu meine Anpassung:
Server host or address
x.x.x.x (Feste externe IP Server)

IPv4 Routes (Server):

IPv4 Routes (Client):

Gateways (Server):

Sep 25 16:22:27	openvpn	14926	clientW/y.y.y.y:52935 MULTI_sva: pool returned IPv4=192.168.101.2, IPv6=(Not enabled)
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 [clientWuerzburg] Peer Connection Initiated with [AF_INET]y.y.y.y:52935
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_COMP_STUBv2=1
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_COMP_STUB=1
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_LZO_STUB=1
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_PROTO=990
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_NCP=2
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_MTU=1600
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_TCPNL=1
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_PLAT=freebsd
Sep 25 16:22:27	openvpn	14926	y.y.y.y:52935 peer info: IV_VER=2.6.4
Sep 25 16:22:26	openvpn	14926	Initialization Sequence Completed
Sep 25 16:22:26	openvpn	14926	UDPv4 link remote: [AF_UNSPEC]
Sep 25 16:22:26	openvpn	14926	UDPv4 link local (bound): [AF_INET]x.x.x.x:1194
Sep 25 16:22:26	openvpn	14926	/usr/local/sbin/ovpn-linkup ovpns3 1500 0 192.168.101.1 255.255.255.0 init
Sep 25 16:22:26	openvpn	14926	/sbin/ifconfig ovpns3 192.168.101.1/24 mtu 1500 up
Sep 25 16:22:26	openvpn	14926	TUN/TAP device /dev/tun3 opened
Sep 25 16:22:26	openvpn	14926	TUN/TAP device ovpns3 exists previously, keep at program end
Sep 25 16:22:26	openvpn	14926	WARNING: experimental option --capath /var/etc/openvpn/server3/ca
Sep 25 16:22:26	openvpn	14926	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 25 16:22:26	openvpn	14605	DCO version: FreeBSD 14.0-CURRENT #1 RELENG_2_7_0-n255866-686c8d3c1f0: Wed Jun 28 04:21:19 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/obj/amd64/LwYAddCr/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/sources/FreeBSD-src-REL
Sep 25 16:22:26	openvpn	14605	library versions: OpenSSL 1.1.1t-freebsd 7 Feb 2023, LZO 2.10
Sep 25 16:22:26	openvpn	14605	OpenVPN 2.6.4 amd64-portbld-freebsd14.0 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] [DCO]

Aber vielleicht kannst du noch ein paar zusätzlich Details liefern, die das untermauern würden und helfen könnten, dem Problem näher zu kommen: OpenVPN Konfiguration beider Seiten, Routing-Tabellen, Gateways, OpenVPN Server Log eines Verbindungsaufbaus.
Öffentliche IPs und dgl. können natürlich verschleiert sein.

Das VPN habe ich aber fest für das erste Internet-Gateway (WAN1) angelegt.

Wie?
Du hast einen OpenVPN Server laufen, da kannst du bestenfalls das Interface festlegen, an dem er auf eingehende Verbindungen wartet.
Du kannst zwar auch eine bestimmte Route für den Remote-Endpunkt festlegen, bringt aber nix, der Server stellt keine Verbindungen aktiv her.

Über das Internet Gateway?
Ich nehme an, dass du eine private IP der Client-Seite aufrufst, die sollte aber nie über ein Internet-Gateway gehen.

Ja, ich verfolge die Route zu einer IP im Client-Netz (10.10.10.1). Die pfSense auf der Server-Seite leitet diese Anfrage aber nicht über die VPN-Adresse weiter, sondern an das zweite Internet-Gateway (WAN2).
Das VPN habe ich aber fest für das erste Internet-Gateway (WAN1) angelegt.

Hast du auch ein Client Specific Override eingerichtet?

Falls ja, überprüfe mal die Routing Tabellen auf beiden Seiten und am Server im OpenVPN Log, ob the CSO angewandt wurde.

Ja, habe ich angelegt und in beiden Routing Tabellen steht jeweils bei den entfernten Netzen die VPN-Adresse als Gateway drin.

Edit: Nach erneutem Test geht der Ping von einem Rechner aus dem Client-Netz ins Server-Netz durch. Andersrum leider nicht.

Vor der Umstellung auf SSL/TLS hat es noch wunderbar funktioniert. Hat jemand eine Idee, was das Problem sein könnte?

Hast du auch ein Client Specific Override eingerichtet?

Falls ja, überprüfe mal die Routing Tabellen auf beiden Seiten und am Server im OpenVPN Log, ob the CSO angewandt wurde.

@ShaneDeak said in OpenVPN Problem nach Update:

Ich habe noch etwas herausgefunden. Wir benutzen zwei Internet Gateways.
Wenn ich an einem Rechner im Server-Netz Traceroute zu einer Adresse auf der Client-Seite mache, geht Route über das falsche Gateway!

Über das Internet Gateway?
Ich nehme an, dass du eine private IP der Client-Seite aufrufst, die sollte aber nie über ein Internet-Gateway gehen.