OpenVPN Site2Site Verbindungsproblem

mansior

Hallo zusammen,

ich habe ein Problem mit einem eigentlich ganz simplen Vorgehen ;)

Das Netz sieht wiefolgt aus:

       192.168.100.0/24 haupt client (hier sind auch andere VLANs vorhanden) 
            :
            :
      .-----+-----------.  192.168.100.1
      |  haupt pfsense  |  (opvn server)
      .-----+-----------.  192.168.72.1
            |
            | ovpn Transfernetz 192.168.72.0/24 übers Internet
            |
      .-----+-----------.  192.168.72.2
      |  remote pfSense |  (ovpn client)
      .-----+-----------.  192.168.112.1
            :
            : 
      192.168.112.0/24 remote client

Die S2S Config habe ich nach einem der vielen Anleitungen erstellt. Kryptografisch wird alles korrekt aufgebaut und es sieht erst mal gut aus. Jetzt mal eine kleine Auflistung was klappt und was nicht. Die Konfig werde ich im Anschluss anhängen.

Verbindungen die funktionieren:
remote pfSense zu haupt pfSense geht in beide Richtungen
remote pfSense zu haupt client geht

Verbindungen die NICHT funktionieren:
remote client kann nichts außer eigene pfSense und dessen IPs erreichen
haupt pfSense zu remote client geht nicht
haupt client zu remote pfSense geht nicht

Jetzt die Details und meine Lösungsversuche:
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?

openvpn server config:

/var/etc/openvpn/server3: cat config.ovpn
dev ovpns3
verb 3
dev-type tun
dev-node /dev/tun3
writepid /var/run/openvpn_server3.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA512
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 79.249.Y.X
engine rdrand
tls-server
server 192.168.72.0 255.255.255.0
client-config-dir /var/etc/openvpn/server3/csc
ifconfig 192.168.72.1 192.168.72.2
lport 1172
management /var/etc/openvpn/server3/sock unix
push "route 192.168.100.0 255.255.255.0"
route 192.168.112.0 255.255.255.0
capath /var/etc/openvpn/server3/ca
cert /var/etc/openvpn/server3/cert
key /var/etc/openvpn/server3/key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server3/tls-auth 0
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
data-ciphers-fallback AES-256-CBC
allow-compression no
topology subnet

openvpn client config:

ovpn
dev ovpnc1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA512
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.X.Y
engine rdrand
tls-client
lport 0
management /var/etc/openvpn/client1/sock unix
remote XXXX.synology.me 1172 udp4
ifconfig 192.168.72.2 255.255.255.0
pull
capath /var/etc/openvpn/client1/ca
cert /var/etc/openvpn/client1/cert
key /var/etc/openvpn/client1/key
tls-auth /var/etc/openvpn/client1/tls-auth 1
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
data-ciphers-fallback AES-256-CBC
allow-compression no
resolv-retry infinite
topology subnet

routing der haupt pfSense:

netstat -r
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            p3eXXX.dip0.t-i    UGS      pppoe0
dns.google         link#14            UHS      pppoe0
10.10.10.1         link#8             UH          lo0
p3eXXX.dip0.t-i    link#14            UH       pppoe0
p4fXXX.dip0.t-i    p3eXXX.dip0.t-i    UGHS     pppoe0
p4fXXX.dip0.t-i    link#8             UHS         lo0
localhost          link#8             UH          lo0
192.168.1.0/24     link#2             U          igb1
pfSense            link#8             UHS         lo0
192.168.20.0/24    link#13            U       igb1.20
192.168.20.1       link#8             UHS         lo0
192.168.54.0/24    link#15            U        ovpns1
192.168.54.1       link#8             UHS         lo0
192.168.60.0/24    link#16            U        ovpns2
192.168.60.1       link#8             UHS         lo0
192.168.72.0/24    link#17            U        ovpns3
192.168.72.1       link#8             UHS         lo0
192.168.100.0/24   link#11            U      igb1.100
192.168.100.1      link#8             UHS         lo0
192.168.112.0/24   192.168.72.2       UGS      ovpns3

routing der remote pfSense:

netstat -r
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.X.Y        UGS    iwm0_wla
localhost          link#3             UH          lo0
192.168.42.0/24    link#7             U      iwm0_wla
192.168.42.122     link#3             UHS         lo0
192.168.42.150     link#7             UHS    iwm0_wla
192.168.72.0/24    link#8             U        ovpnc1
192.168.72.2       link#3             UHS         lo0
192.168.100.0/24   192.168.72.1       UGS      ovpnc1
192.168.112.0/24   link#6             U           ue0
pfsense-max        link#3             UHS         lo0

Auf beiden pfSense gibt eine any/any allow FW Regel auf OpenVPN...
beide pfSense sind 2.7.2...

Jemand eine Idee?
VG
Mansior

micneu

@mansior was für regeln hast du für die OpenVPN angelegt? Bitte von beiden Seiten

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