OpenVPN Site2Site Verbindungsproblem

mansior

@micneu
auf haupt pfsense:
Bei WAN: UDP 1172 an WAN von Any alles erlaubt
Bei OpenVPN erstmal alles offen...

auf remote pfsense:
Bei OpenVPN erstmal alles offen...

viragomann

@mansior
Ohne Client Specific Override wird das nix mit dem Routing zwischen den beiden entfernten Netzen.

Was haben die Maschinen für CUPs?
Diese Frage wirft sich aufgrund der Hardware-Crypto-Einstellungen auf.

micneu

@mansior mir ist nur aufgefallen das dein local in der server config nicht richtig angegeben ist

local 79.249.Y.X

mansior

@viragomann

Ohne Client Specific Override wird das nix mit dem Routing zwischen den beiden entfernten Netzen.

Netzwerk, IP und Routing gehören jetzt nicht zu meinem Stärken, aber das verstehe ich nicht.

Nach meinem Verständniss, wenn nicht von einer FW geblockt, müsste ein Paket z.B. folgenden Weg gehen. Dieses wurde von 192.168.112.101 an 192.168.100.50 geschickt:

Paket verlässt 192.168.112.101 und geht ans GW (192.168.112.1), weil keine Route oder "Layer2 Netz" für 192.168.100.50 vorhanden ist.
Das GW weiß das 192.168.100.0/24 über die 192.168.72.1 erreichbar ist und leitet das Paket weiter. Die 192.168.72.1 ist wiederum über "Layer2" erreichbar.
192.168.72.1 kennt das Netz 192.168.100.0/24 direkt und leitet das Paket über "Layer2" weiter.
Die Antwort geht genau den gleichen Weg, zusammengefasst:
Client Haupt (192.168.100.50) =>
GW Haupt(192.168.100.1/192.168.72.1) OVPN =>
OVPN (192.168.72.2/192.168.112.1) GW remote =>
Client remote (192.168.112.101)

Ist das nicht klassisches Routing? (natürlich nur wenn keine FW dazwischen geht)

Was haben die Maschinen für CUPs?
Diese Frage wirft sich aufgrund der Hardware-Crypto-Einstellungen auf.

Ich hab mit den Einstellungen viel rumgespielt. Aber das Ergebniss war immer erwartbar, aber das Problem konnte nicht gelöst werden.

Bzgl der CPUs:
Haupt:

Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
Current: 2812 MHz, Max: 2700 MHz
4 CPUs: 1 package(s) x 2 core(s) x 2 hardware threads
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No

Remote:

Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz
4 CPUs: 1 package(s) x 2 core(s) x 2 hardware threads
AES-NI CPU Crypto: Yes (inactive)
QAT Crypto: No

mansior

@micneu

local 79.249.Y.X

Das ist meine handische Anonymisierung ;) Dort steht das die IP an die der OpenVPN Server gebunden wird, also an die externe IP... zumindest laut man page

Die Haupt pfSense ist das direkte GW ins Internet, die remote pfSense ist "nur" ein Client in 192.168.42.0/24 und spannt dahinter ein eigenes Netz (192.168.112.0/24) auf.

Auch wenn es meiner Meinung nach keinen Unterschied macht, eigentlich sieht die Architektur wiefolgt aus:

haupt client
     |
haupt pfsense ------------------------.
     |                                |
Internet                              |
     |                                | OVPN
5G Smartphone (Wifi Hotspot)          |
     |                                |
remote pfSense (WAN über Wifi)--------.      
     |                                
remote client

viragomann

@mansior
Das Routingproblem ist hier serverseitig innerhalb von OpenVPN.

Eine Datenkommunikation braucht zwei Richtungen, einen Request- und einen Response-Weg.
Das Request-Paket wird seinen korrekten Weg finden und im LAN des Servers und am Zielgerät ankommen. Der Respond von diesem geht an den Server, da wieder in OpenVPN, aber dann weiß es nicht mehr weiter, weil ein OpenVPN Server mehrere Clients angebunden haben kann. Das Problem besteht auch, wenn es nur einer ist.

Das kannst du mit Packet Capture nachprüfen.
Den Request vom Client LAN wirst du auf dem LAN des Servers sehen, den Respond auch und auch am OpenVPN Interface des Servers, aber nicht mehr am OpenVPN Interface des Clients.

Wenn du nur einen Client hast und DCO nicht verwendest, kannst du das Problem auch umgehen, in dem du dem Tunnel Netzwerk eine /30 Netzwerkmaske gibt.
Dann kann es im Subnetz nur einen Client geben, und das Routing ist damit eindeutig.

Remote:

Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz
4 CPUs: 1 package(s) x 2 core(s) x 2 hardware threads
AES-NI CPU Crypto: Yes (inactive)
QAT Crypto: No

Diese CPU unterstützt AES-NI, was weitaus leistungsfähiger als RDRAND ist. "AES-NI CPU Crypto: Yes (inactive)" bedeuted, dass es aber nicht aktiviert ist. Das geht in System > Advanced > Miscellaneous > Cryptographic Hardware.

In OpenVPN sollte die Hardware Crypto Engine dann auf "none" gestellt werden. AES-NI wird automatisch verwendet, wenn verfügbar.

mansior

@viragomann

Das Routingproblem ist hier serverseitig innerhalb von OpenVPN.

Eine Datenkommunikation braucht zwei Richtungen, einen Request- und einen Response-Weg.
Das Request-Paket wird seinen korrekten Weg finden und im LAN des Servers und am Zielgerät ankommen. Der Respond von diesem geht an den Server, da wieder in OpenVPN, aber dann weiß es nicht mehr weiter, weil ein OpenVPN Server mehrere Clients angebunden haben kann. Das Problem besteht auch, wenn es nur einer ist.

Ich hab Request und Response Weg oben beschrieben. Wo kann dort nicht entschieden werden wohin ein Paket soll?

Das kannst du mit Packet Capture nachprüfen.
Den Request vom Client LAN wirst du auf dem LAN des Servers sehen, den Respond auch und auch am OpenVPN Interface des Servers, aber nicht mehr am OpenVPN Interface des Clients.

Das habe/hatte ich versucht. Ping soll von 192.168.112.101 an 192.168.100.50 gehen.
Das Ergebnis ist, dass ich die Pakete auf remote pfSense(OVPN Interface) sehe, aber auf der haupt pfSense (OVPN Interface) eben nicht:
@mansior said in OpenVPN Site2Site Verbindungsproblem:

Ping von remote client an haupt client abgesetzt und auf beiden pfSense am Ovpn Interface pcaps mitgeschnitten. Auf der remote pfSense sehe ich das Paket, auf der haupt pfSense aber NICHT. Was kann hier noch eingreifen?
Ist es möglich, dass eine der beiden Firewalls das Paket abräumt (in den Logs sehe ich das nicht) nachdem oder bevor das Paket im promiscuous Mode aufgezeichnet wurde?

viragomann

@mansior said in OpenVPN Site2Site Verbindungsproblem:

Ich hab Request und Response Weg oben beschrieben. Wo kann dort nicht entschieden werden wohin ein Paket soll?

Habe ich ja oben beschrieben.

Das kannst du mit Packet Capture nachprüfen.
...
Das habe/hatte ich versucht. Ping soll von 192.168.112.101 an 192.168.100.50 gehen.
Das Ergebnis ist, dass ich die Pakete auf remote pfSense(OVPN Interface) sehe, aber auf der haupt pfSense (OVPN Interface) eben nicht:

Ping von remote client an haupt client abgesetzt und auf beiden pfSense am Ovpn Interface pcaps mitgeschnitten. Auf der remote pfSense sehe ich das Paket, auf der haupt pfSense aber NICHT. Was kann hier noch eingreifen?
Ist es möglich, dass eine der beiden Firewalls das Paket abräumt (in den Logs sehe ich das nicht) nachdem oder bevor das Paket im promiscuous Mode aufgezeichnet wurde?

Mit pcap müsstest du die Pakete auf beiden Seiten sehen. Das greift vor den Firewall Regeln auf die Interfaces zu.
Wenn da am Server nichts ist, hat es wohl was in OpenVPN.

Ich weiß jetzt nicht, ob aktuell das Tunnel-Netz am Client anzugeben ist. Das war mal so, mal anders zu machen. Du kannst ja versuchen, es einfach zu entfernen. Es wird ohnehin vom Server verteilt.

mansior

@viragomann
wenn ich die Anleitungen richtig verstehe, dass hat OpenVPN nochmal sowas wie eine eigene Routing Tabelle... ich hatte Client Specific Override ausprobiert und dort eigentlich das gleiche wie beim Server eingetragen... Das hat leider nicht geholfen...

Ich muss gestehen, dass mir das, wahrscheinlich wegen mir, zu lange dauerte und ich deswegen jetzt auf Wireguard geschwenkt bin...das läuft nu wie ich es wollte.

Trotzdem vielen Dank für die Mühe!!!

JeGr

@mansior said in OpenVPN Site2Site Verbindungsproblem:

@viragomann
wenn ich die Anleitungen richtig verstehe, dass hat OpenVPN nochmal sowas wie eine eigene Routing Tabelle... ich hatte Client Specific Override ausprobiert und dort eigentlich das gleiche wie beim Server eingetragen... Das hat leider nicht geholfen...

Ich muss gestehen, dass mir das, wahrscheinlich wegen mir, zu lange dauerte und ich deswegen jetzt auf Wireguard geschwenkt bin...das läuft nu wie ich es wollte.

Trotzdem vielen Dank für die Mühe!!!

Wireguard hat wieder seine ganz eigenen Baustellen.

Was OpenVPN braucht ist einfach:

Site2Site mit Zertifikat
beide Seiten haben ihre lokalen und remote Netze befüllt.
CN der Client Seite bekommt auf dem Server eine CSO in der nochmals die Remote Seite ausgefüllt sein muss!

Wenn das gegeben ist, klappt es auch mit der Verbindung. OVPN hat da keine besondere zusätzliche Routingtabelle, es ist schlicht die Routinglogik die nicht eindeutig ist:

Du konfigurierst den Server auf Seite A, Client auf Seite B
Seite B kann sich NUR zu Seite A connecten - da gibt es keine Frage
Seite A Server kann aber MEHRERE Clients haben. Niemand verbietet das und das Setup ist auch nicht unüblich, wenngleich ich es nicht empfehle. Aber im Gegensatz zum alten Shared Key Tunnel gibt es hier eben NICHT eine eindeutige Klarheit, wohin Pakete geroutet werden sollen, denn es kann X Clients geben die verbunden sind.

Daher gilt hier:

Remote Netz im Server selbst: Hier müssen ALLE Netze hinein, die sich ggf. mit Clients verbinden. Wenn das mehrere S2S Clients sind, müssen das ALLE Remote Netze sein. Und daran sieht man schon, dass es nun schwer wird zu wissen, wo die Netze hin sollen.
CSO mit Match auf Zertifikats-CN des Clients für den richtigen Tunnel: Hier im Remote Netz muss dann NUR das Netz stehen, dass auch wirklich auf der Client Seite zu finden ist.

Dann kann der OVPN Serverprozess auch verstehen, WAS er alles annehmen soll und an WEN er dann WAS weitergeben soll.

Darum braucht man es auch bei nur einem Client eben 2x definiert

Cheers