OpenVPN Umstellung auf Topology-Subnetz macht Probleme

Hi Leute,
nachdem ich vor kurzem eine pfSense 2.6.0-RELEASE auf einem APU-Board aktualisiert habe, bekam ich Probleme mit der Stabilität mehrerer OpenVPN-Instanzen.
Da das Construct, welches schon ein paar Monate problemlos gelaufen war, wohl vom "Zahn der Zeit" etwas angenagt ist, habe ich mich ein wenig eingelesen und festgestellt, das so einige Einstellungs-Änderungen sinnvoll wären.
Abgesehen von mehreren problemlosen Einstellungs-Änderungen, die OpenVPN 2.5 mitbringt, liegt hier das Problem bei der Topology-Subnetz Aktivierung.
Es laufen 2 Server im Peer-to-Peer Modus, die Remote, jeweils eine "veredelte" Fritte mit OpenWRT als Client haben.
Die Änderungen bei diesen Servern haben sich eigentlich nur auf eine Aktualisierung des Verschlüsselungsalgorythmus, der Kompressionsabschaltung sowie des Push-Eintrages in der CCD beschränkt.
Also eine Änderung von...

ifconfig 10.16.9.1 10.15.8.2;

in...

ifconfig-push 10.16.9.2 255.255.255.0 10.16.9.1;

Auf einer der OpenWRT-Clients läuft noch OpenVPN 2.4.7, so das eine einfache Übertragung der pfSense-Client-Export Einstellungen in die berüchtigte Hose ging. Ist mittlerweile wieder gefixt. Also Vorsicht geboten, wenn man den Client einfach so exportiert.
Der Versuch, 2 weitere Instanzen von -net30 auf Topology-Subnetz zu migrieren, bereitet mir dagegen weiter Probleme.
Sie arbeiten beide im Remote Access Modus, in Verbindung mit Linux-Clients und genau hier liegt mein Problem.
Während diese im net30-Modus problemlos routen, bauen sich die Tunnel bei Topology-Subnetz zwar auf, ich bekomme aber keine Verbindung zu anderen Instanzen trotz der eingetragenen Routen zustande.

Hier die ifconfig und Routing -Tabelle des einen Clients mit Topologie-Subnetz Einstellung. Wird der Eintrag in der CCD geändert, indem man den Gateway weg lässt, wird der tun0-Eintrag von der Ip 10.16.9.1 auf das Netz 10.16.9.0 gesetzt. Am nicht funktionierenden Routing, ändert sich nichts.

ifconfig subnetz

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.16.9.1  netmask 255.255.255.0  destination 10.16.9.1
        inet6 fe80::1428:b506:e0a1:e405  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  
        
        
 route
        
        root@paul:~#route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         paul            255.255.255.255 UGH   0      0        0 tun0
default         fritz.box       0.0.0.0         UG    600    0        0 wlp2s0
10.10.4.0       paul            255.255.255.0   UG    0      0        0 tun0
10.10.8.0       paul            255.255.255.0   UG    0      0        0 tun0
10.16.9.0       0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.100.10.0     paul            255.255.255.0   UG    0      0        0 tun0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 wlp2s0
172.16.7.0      paul            255.255.255.0   UG    0      0        0 tun0
192.168.219.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0

Hier der Client mit funktionierendem Routing und net30-Topologie....

net 30 !!!!!


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::e501:21ba:8e87:7c1c  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 606060  bytes 674341833 (643.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 325805  bytes 17082946 (16.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
        
route

root@schrotti:~#route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.15.8.1       255.255.255.255 UGH   50     0        0 tun0
default         10.15.8.1       0.0.0.0         UG    50     0        0 tun0
default         fritz.box       0.0.0.0         UG    600    0        0 wlo1
10.10.4.0       10.15.8.1       255.255.255.0   UG    50     0        0 tun0
10.10.8.0       10.15.8.1       255.255.255.0   UG    50     0        0 tun0
10.15.8.0       10.15.8.1       255.255.255.0   UG    50     0        0 tun0
10.15.8.1       0.0.0.0         255.255.255.255 UH    50     0        0 tun0
10.100.10.0     10.15.8.1       255.255.255.0   UG    50     0        0 tun0
p57af4fb0.dip0. fritz.box       255.255.255.255 UGH   600    0        0 wlo1
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 wlo1
172.16.7.0      10.15.8.1       255.255.255.0   UG    50     0        0 tun0
192.168.219.0   0.0.0.0         255.255.255.0   U     600    0        0 wlo1
fritz.box       0.0.0.0         255.255.255.255 UH    600    0        0 wlo1

Die pfSense schreibt in der ifconfig für alle Tunnel den Server auf x.x.x.1, Client auf x.x.x.2. Die Einstellungen sollten auf Seiten der Firewall also stimmen.

Ich könnte das zwar auf net30 belassen, das Problem ist aber wohl nur aufgeschoben.

Gruß orcape

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

Content-ID: 2465622585

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

Ausgedruckt am: 24.11.2024 um 12:11 Uhr

1 Kommentar

Hi,
ich habe das Problem nach einer kleinen "Anschubhilfe" von @aqui, mit einer Umstrukturierung der OpenVPN-Config nun fixen können.
Es scheint wirklich so zu sein, das eine Topologie-Subnetz im Access-Point Modus, mit einem Client, d.h. einer Zertifikatstiefe "Server-Client", beim Routing zwischen den Tunneln, nicht wirklich klar kommt.
Peer-to-Peer mit einem Router als Client ist das hingegen kein Thema.
Leider ist dazu in den Manuals von OpenVPN nichts zu finden und auch im Netz gibt es wenig bis keine Hinweise.
Zumindest erscheint die Tunnel-Infrastruktur nun etwas "aufgeräumter".