06.10.2019, aktualisiert um 20:45:57 Uhr

3156

Neu eingerichteter, funktionierender OpenVPN-Tunnel verhält sich wie ein Multiclienttunnel

Hi ,
Frage an die VPN-Profis, und ja, ich glaube meine Hausaufgaben gemacht zu haben, nur ist mir gerade mein Latein ausgegangen...

Ich habe auf einer APU mit pfSense, einige OpenVPN-Server am laufen.
Davon einer mit Remote Access für einen Laptop.
Nun ist ein Linux-Client hinzugekommen, dem ich einen weiteren Server mit Remote-Access "spendiert" habe.
Er funktioniert auch, genau wie sein Vorgänger tadellos, nur sind mir einige Ungereimtheiten aufgefallen, die ich mir nicht erklären kann.
Beide Remote-Access Tunnel haben bis auf die Zertifikate und die Schlüssel exakt die gleichen Einstellungen.
Beide Clients laufen mit Debian10, der einzige Unterschied, einer mit KDE der andere mit Cinnamon, was eigentlich nichts bedeuten dürfte.
Der neue Tunnel, läuft im Gegensatz zum vorherigen im Multiclientmodus, zumindest zeigt das ifconfig beim Interface tun0 des Clients so an....
Neuer Tunnel "pauline"...

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.16.9.6 netmask 255.255.255.255 destination 10.16.9.5
inet6 fe80::dc48:baa6:a4a5:8143 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100

Der alte Tunnel "ikarus"...

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.15.8.2 netmask 255.255.255.255 destination 10.15.8.1
inet6 fe80::b9:382d:d4a3:1b48 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100

Genau das zeigt mir auch die pfSense auf dem Dashboard an...

nur zeigt mir ifconfig auf der pfSense etwas anderes...

ikarus...

ovpns3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1308
options=80000<LINKSTATE>
inet6 fe80::20d:b9ff:fe42:679c%ovpns3 prefixlen 64 scopeid 0xb
inet 10.15.8.1 --> 10.15.8.2 netmask 0xffffffff
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: tun openvpn
Opened by PID 41778

pauline...

ovpns5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1308
options=80000<LINKSTATE>
inet6 fe80::20d:b9ff:fe42:679c%ovpns5 prefixlen 64 scopeid 0xd
inet 10.16.9.1 --> 10.16.9.2 netmask 0xffffffff
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: tun openvpn
Opened by PID 58514

Die Routingtabelle der pfSense für die Tunnel ist identisch mit der Ausgabe von ifconfig. Es dürfte also kein Multiclienttunnel für das Netz 10.16.9.0/24 laufen, nur wird er in den Logs der pfSense leider angezeigt.

Oct 6 18:59:20 openvpn 58514 client-pauline/46.88.191.146:58919 MULTI_sva: pool returned IPv4=10.16.9.6, IPv6=(Not enabled)

Vielleicht habe ich ja etwas übersehen, die openvpn.conf der Clients, die Servereinstellungen und die CCD sind bis auf die Namen, die Zertifikate und Keys jedenfalls identisch.
Wieso macht der neue Tunnel also Multiclient?

Gruß orcape

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 502087

Url: https://administrator.de/contentid/502087

Ausgedruckt am: 24.11.2024 um 11:11 Uhr

12 Kommentare

Neuester Kommentar

Ein paar Fragen dazu da die Beschreibung nicht ganz eindeutig ist ?!

"Linux-Client hinzugekommen, dem ich einen weiteren Server mit Remote-Access "spendiert" habe." Was bedeutet diese leicht verschwurbelte und verwirrende Aussage denn technisch genau ?: ==> Du hast einen Linux Rechner bei dem ein OpenVPN Server für VPN Client Dialin rennt ??
Was genau meinst du mit dem ominösen Begriff Multiclientmodus ?? Generell bedient jeder OVPN Server ja multiple Clients und den Ausdruck gibt es so im OVPN oder generell im VPN Umfeld nicht. Insofern ist auch das verwirrend. Oder meinst du damit den Servermode das der im "Subnet Mode" konfiguriert ist statt im /30er Subnet P2P Mode für die Clients ?? Was gemeint ist ist unklar...

Auch warum man unterschiedliche OVPN Instanzen fährt ist unverständlich aber hier zur eigentlich Fragestellung natürlich nebensächlich.

Hilfreich wie immer wären die entsprechenden Server und Client Konf Dateien...

Hi aqui,
zum 1. Punkt...
Ich habe auf der pf einen zusätzliche OVPN-Server eingerichtet, um einen 2. Linux Client (Laptop) an mein internes Netz anzubinden. Er kann über die pf auf einen weiteren Tunnel zugreifen, der eine Kameraüberwachung ermöglicht.
Natürlich könnte ich das über einen Tunnel realisieren, aber es hat auch Vorteile dies nicht zu tun und der pfSense ist es wohl egal.

zum 2. Punkt...
Mit Multiclientmodus meine ich, das der Tunnel mehrere IP's aufbaut, wie in den ifconfig-Ausgaben von "pauline" zu sehen.
Während ich einen "peer -to - peer" ("Subnet Mode") Modus wähle, um 2 Niederlassungen die auch Subnetze haben, zu verbinden, wähle ich für die Anbindung von Einzelclients den Servermodus "Remote Access".
In beiden Fällen habe ich ein /24 er Tunnelnetz, der für den Server die IP xxx.xxx.x.1 und für den Client die IP xxx.xxx.x.2 aufbaut.
Warum auch immer, sieht das Tunnelnetz für "pauline" mit xxx.xxx.x.1 / 2 für den Server und xxx.xxx.x.5 / 6 für den Client, eben anders aus. Im Dashboard der pfSense wird das genau so angezeigt, während die Routing-Tabelle der pf mit xxx.xxx.x.1 für den Server und xxx.xxx.x.2 für den Client etwas anderes sagt.

Beide Tunnel sind über den NW-Manager der Clients aktivierbar. Der Unterschied bei der Konfiguration zwischen Tunnel "ikarus" und "pauline", "ikarus" (Debian10/KDE), speichert seine client.conf im Pfad /etc/openvpn/client.conf ab und der NW-Manager verweist nur darauf hin. Während bei "pauline" die Einstellungen des NW-Managers (Debian10/Cinnamon) die Client.conf im GUI geschrieben werden und unter /etc/NetworkManager/client abgespeichert wird, während Zertifikate und Key's unter /etc/openvpn liegen und der NW-MAnager nur darauf verweist.

Client-conf. "ikarus"

client
dev tun
proto udp
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
persist-tun
persist-key
link-mtu 1430
cipher AES-256-CBC
auth SHA1
tls-client
tls-auth /etc/openvpn/ta.key 1
resolv-retry infinite
remote orcape.......... 1196
verify-x509-name "ikarus" name  
ns-cert-type server
comp-lzo adaptive

conf. "pauline"

[vpn]
auth=SHA1
ca=/etc/openvpn/client/ca.crt
cert=/etc/openvpn/client/client.crt
cert-pass-flags=0
cipher=AES-256-CBC
comp-lzo=yes
connection-type=tls
key=/etc/openvpn/client/client.key
port=1198
remote=orcape........de
ta=/etc/openvpn/client/ta.key
ta-dir=1
service-type=org.freedesktop.NetworkManager.openvpn

Server "ikarus"

dev ovpns3
verb 1
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
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.219.2
tls-server
server 10.15.8.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server3
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'ikarus' 1"  
lport 1196
management /var/etc/openvpn/server3.sock unix
max-clients 15
push "dhcp-option DNS 192.168.155.1"  
push "dhcp-option DNS 192.168.219.1"  
push "redirect-gateway def1"  
ca /var/etc/openvpn/server3.ca
cert /var/etc/openvpn/server3.cert
key /var/etc/openvpn/server3.key
dh /etc/dh-parameters.2048
crl-verify /var/etc/openvpn/server3.crl-verify
tls-auth /var/etc/openvpn/server3.tls-auth 0
ncp-ciphers AES-128-GCM
comp-lzo adaptive
topology net30
link-mtu 1430

Server pauline

dev ovpns5
verb 1
dev-type tun
dev-node /dev/tun5
writepid /var/run/openvpn_server5.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.219.2
tls-server
server 10.16.9.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server5
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server-pauline' 1"  
lport 1198
management /var/etc/openvpn/server5.sock unix
max-clients 15
push "dhcp-option DNS 192.168.155.1"  
push "dhcp-option DNS 192.168.219.1"  
push "redirect-gateway def1"  
ca /var/etc/openvpn/server5.ca
cert /var/etc/openvpn/server5.cert
key /var/etc/openvpn/server5.key
dh /etc/dh-parameters.2048
crl-verify /var/etc/openvpn/server5.crl-verify
tls-auth /var/etc/openvpn/server5.tls-auth 0
ncp-ciphers AES-128-GCM
comp-lzo adaptive
topology net30
link-mtu 1430

Gruß orcape

und der pfSense ist es wohl egal.

Performance technisch nicht ganz aber bei einem einzigen Client kann man es wohl in der Tat vergessen. Die CPU Anzeige im Dashboard ist da ja ein gutes Messinstrument...

Mit Multiclientmodus meine ich, das der Tunnel mehrere IP's aufbaut,

Sprich du hast den Server Mode in einem /30 P2P Design laufen, richtig ?

Das nutzt man heute in aktuellen Setups nicht mehr so sondern im Mode "Subnet" ! Ist eher also kontraproduktiv wenn du das so am Server einstellst.
Unter Linux ist das das Kommando topology subnet und push "topology subnet" in der Server Konf Datei. Letzteres um es dynamisch an die Clients zu "pushen".
Das fehlt bei dir in deiner Konfig und dadurch nutzt du den /30er P2P Default der dann immer zu 32Bit Hostrouten mit einer verwirrenden Anzeige führt.
Ggf. ist das dein Problem. Wenn man das ändert verschwindet das auch.
Genauso comp-lzo sollte man nicht mehr verwenden. Sinnvoller ist das moderne compress lz4-v2 !

Hi aqui,
bin noch am suchen.
Nachdem ich die configs, sowohl Server wie auch Client nach Deinen Vorgaben betreffs "topology subnet", "push "topology subnet"" , sowie "comp-lzo" auf "compress lz4-v2" geändert habe und von /30er P2P auf Subnetz umgestellt habe, wird kein Tunnel mehr aufgebaut.
Im Dashboard der pfSense ändert sich die angezeigte Client-IP 10.15.4.2 auf IP 10.15.4.0, klar angezeigt, was die Routing-Tabelle auch eindeutig belegt.
Das Umstellen von Subnetz auf 30 p.to p. in der Server,-Topology ergibt dann wieder einen funktionierenden Tunnel mit Client-IP 10.15.4.2 und Server-IP 10.15.4.1, dann mit "topology subnet" und "compress lz4-v2" in den Configs.
Gruß orcape

wird kein Tunnel mehr aufgebaut.

Der Verursacher dürfte die Compression sein. Das Kommando ist mit der Syntax Änderung etwas verwirrend. Es wegzulassen bedeutet nämlich nach der alten Notation nicht das es abgeschaltet ist sondern das es standby im adaptive Mode lauert.
Das Böse ist wenn die Compresion zw. Client und Server nicht gleich ist, dann kommt der Tunnel nicht hoch ! Stelle den Log Level auf 3 (verbose) dann siehst du das Drama auch.
Heisser Tip ist also die Compression zum Testen mit comp-lzo no auf beiden Seiten erstmal hart abzuschalten. Dann sollte der Tunnel fehlerlos hochkommen.
Die LZO Kompression bringt eh nicht viel da sie viel Performance frisst und Tunnel Overhead erzeugt. lz4-v2 ist da erheblich effizienter und schonender. Sollte man aber erst aktivieren wenn wirklich alles fehlerfrei rennt.
Übrigens kann man mit "push compress lz4-v2" das auch dynamisch auf die Clients distribuieren.

Bedenke aber das es nur in der aktuellen OVPN Version supportet ist nicht in älteren. Setzt du also noch alte Versionen oder Clients ein ist das nicht kompatibel !

Moin Aqui,
Danke erst einmal für die Tipp 's.
Das von Dir gepostete Bild der "Client settings", entspricht nicht mehr den Einstellungsmöglichkeiten der pfSense in Version 2.4.4. Ich habe noch eine 2.3.5 auf einem ALIX am laufen, da ist das aber genau so. Der Tipp mit dem Log-Level, war schon mal ein erster Schritt.
Ich werde mich mal weiter versuchen und gebe Feeback, sobald ich konkrete Ergebnisse habe.
Bis dahin, schönen Tag noch....
Gruß orcape

der pfSense in Version 2.4.4. Ich habe noch eine 2.3.5 auf einem ALIX am laufen

Das ist richtig.
Der o.a. Screenshot stammt ebenfalls von einem ALIX2D13 mit 2.3.5p2. Bei der aktuellen 2.4.4p3 ist das geringfügig anders.
Wenn man auf Nummer sicher geht sieht man so oder so immer über den Shell Zugriff in die /etc/openvpn Dati und den entsprechenden Konfig File dort. Da steht dann wirklich was der OVPN Prozess macht. Binsenweisheit die du als alter VPN Foren Profi ja auch kennst...

...in die /etc/openvpn Dati und den entsprechenden Konfig File dort.

Richtig aqui, und damit man es uns nicht zu einfach macht, legt man doch die Openvpn bei jedem OS in einen anderen Pfad.
Bei FreeBSD dann eben in /var/etc/openvpn..... denn, wer sucht, der findet.

Stimmt du hast recht...hatte mir aus Faulheit das PuTTY Hochfahren gespart. Shame on me...

Hi,
nun habe ich die Sache hingebogen und es funktioniert so wie ich wollte, Server IP 10.16.9.1, Client IP 10.16.9.2.
Läuft "fast" alles, so wie Du mir vorgeschlagen hast, aqui. Einträge in die Server und Clientseite zwecks "compress lz4-v2" und "topology subnet" sind erfolgt. Einzige Ausnahme, "Subnet Mode" ist in der Topology der pf-Eingabemaske nicht machbar. Der Tunnel fährt zwar hoch, zeigt aber, sowohl im Dashboard wie in der Routing Tabelle als Server-IP die 10.16.9.0 an, selbstverständlich ist da keine Verbindung zustande zu bringen. Ich habe die Veränderungen auch noch auf einem zweite Tunnel getestet, mit gleichem Ergebnis. Keine Verbindung, wenn ich die Einstellung "/30er P2P" heraus nehme und "Subnet Mode" verwende. Sollte es an den Einstellungen der Zertifikatstiefe liegen, die bei mir natürlich auf "1 Server, 1 Client" gesetzt sind. Möglich das dies der Server nicht mitmacht.?
Auf alle Fälle sind die verwendeten OpenVPN-Versionen alle > 2.4., daran kann es also nicht liegen.
Aber egal, wäre halt trotzdem interessant zu wissen.
Wenn ich mal viel Zeit habe, neue Zertifikate erstelle um einen neuen Server einzurichten, werde ich das mit der Zertifikatstiefe und "Subnet Mode" mal testen.
Gruß orcape

Einzige Ausnahme, "Subnet Mode" ist in der Topology der pf-Eingabemaske nicht machbar.

Mmmhhh, was meinst du damit genau ??? pf = pfSense ???
Da geht es aber sehr wohl !! Siehe GUI Screenshot oben !
Ist ein bischen unklar was du mit dem Satz sagen willst...

Die Zertifikate haben mit dem Tunnel Mode nichts zu tun, das kann so bleiben.
Was dann sinnvoll ist sofern man mehr als einen Standort hat bei der Site to Site Kopplung ist das man über die Client spezifischen Extensions fest eine Tunnel IP aus dem Subnet Pool zuweist.
Hier ist das beschrieben:
Problem mit site 2 site VPN
Damit hat man dann eine feste Struktur. Ist aber nur bei Site to Site sinnvoll, NICHT bei einem Client Dialin, da ist sowas egal, weil es dort kein Routing in dem Sinne gibt.

Mmmhhh, was meinst du damit genau ??? pf = pfSense ???

Ja Sorry, der Faulheit geschuldet, pfSense natürlich.
Ist "Topology "Subnet"" im GUI des Servers eingestellt....

...setzt der Server die IP auf 10.16.9.0 und nix geht mehr.
Ich hatte vermutet, das es eventuell die eingegebene "Certificate Depth" verursachen könnte...