unbekannternr1
May 04, 2020, updated at 09:13:59 (UTC)
view2211
view9
0
Goto Top

VPN Route wird umgangen

GermanQuestionRouters, RoutingNetworks
Hallo,
mir nach dem testen von Jitsi etwas aufgefallen was es nicht geben sollte. Wir haben einen internen Jitsi Server aufgesetzt funktioniert alles Top. Nun wollten wir ggf. auch mit externen Partnern kommunizieren. Dazu haben wir einen eigenen Jitsi Server im Internet aufgesetzt. Aber es geht mit jedem Public Server.
Wir haben Laptops die per VPN angebunden sind. Die default Route wird per VPN auf die Arbeit umgeleitet siehe unten dazu. Zusätzlich haben die Laptops einen Proxyserver eingetragen der auf der Arbeit steht und verwendet werden sollte. Wenn ich jetzt auf so einem Laptop einen Public Jitsi server öffne wird für die Web Connection auch der Proxy Server verwendet, allerdings habe ich festgestellt das die Verbindung auch ohne freigabe in der Firewall funktioniert. Auf dem Server im Web konnte ich das feststellen das die Clients mit Ihrer IP des lokalen DSL Anschlusses ankommen.

Der Ablauf ist so das erst einige Pakete in der Firewall auf der Arbeit richtung Public server Port 10000 geblockt werden danach baut sich die Verbindung offensichtlich über die zweite Route auf. Die internen Clients scheitern wie gewollt erstmal an der Firewall.

Fragen dazu sind:
Warum geht das?
Kann ich das verhalten verhindern?
Besteht ein erhötes Sicherheitsrisiko? Denn auf diese weise könne ja die Sicherheitsregularien der Arbeit umgangen werden face-sad


Firewall am Hauptstandort: PFsense mit OpenVPN Server force all traffic through VPN gesetzt

Clients
OS: Windows 10 Ent.
VPN Client: Openvpn aktuell
Browser: Chrome oder Firefox (verhalten sich gleich)
Benutzer keine Adminrechte.
Aktive Routen: (Client)
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0    192.168.178.1   192.168.178.56     50
          0.0.0.0        128.0.0.0     10.10.22.65     10.10.22.75      3
     10.10.22.64  255.255.255.192   Auf Verbindung      10.10.22.75    259
     10.10.22.75  255.255.255.255   Auf Verbindung      10.10.22.75    259
    10.10.22.127  255.255.255.255   Auf Verbindung      10.10.22.75    259
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
        128.0.0.0        128.0.0.0     10.10.22.65     10.10.22.75      3
    192.168.178.0    255.255.255.0   Auf Verbindung    192.168.178.56    306
   192.168.178.56  255.255.255.255   Auf Verbindung    192.168.178.56    306
  192.168.178.255  255.255.255.255   Auf Verbindung    192.168.178.56    306
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung      10.10.22.75    259
        224.0.0.0        240.0.0.0   Auf Verbindung    192.168.178.56    306
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung      10.10.22.75    259
  255.255.255.255  255.255.255.255   Auf Verbindung    192.168.178.56    306

Edit: Der Onlineserver hat nur nur Ipv4 DNS einträge wir verwenden generell noch ausschließlich ipv4.
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 569460

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

Printed on: April 16, 2024 at 23:04 o'clock

9 Comments
Latest comment
Goto Top
Member: tikayevent
tikayevent May 04, 2020 updated at 08:50:39 (UTC)
Goto Top
Deine Routingtabelle ist nicht in Ordnung.

Du sagst, die Default-Route liegt auf dem VPN-Tunnel. Sehe ich aber nicht so. Eine Default-Route ist immer 0.0.0.0/0.0.0.0, bei dir ist es aber zweigeteilt, also meiner Meinung nach eine Fehlkonfiguration.

Du zeigst jetzt auch nur den IPv4-Teil. Viele beachten IPv6 nicht und vermutlich geht es über den Weg dann direkt ins Internet.
Member: UnbekannterNR1
UnbekannterNR1 May 04, 2020 at 09:18:07 (UTC)
Goto Top
Das macht der Openvpn Server automatisch in der Pfsense, ich hatte das so verstanden das er das macht damit die neue Route kleinere Netzbereiche hat als die alte und damit vorrang bekommt. Sonst würden sich ja zwei gleichwertige Routen gegenüber stehen.


Und wir verwenden noch ausschließlich noch IPv4 daher habe ich mich darauf begrenzt. Hab das oben nochmal egänzt. Danke für den Hinweis.
Member: aqui
aqui May 04, 2020 updated at 09:27:53 (UTC)
Goto Top
danach baut sich die Verbindung offensichtlich über die zweite Route auf.
Mit einem gescheiten Traceroute (tracert) was die einzelnen Routing Hops anzeigt hätte man nicht raten müssen sondern sähe es eindeutig !
Eine Default-Route ist immer 0.0.0.0/0.0.0.0, bei dir ist es aber zweigeteilt, also meiner Meinung nach eine Fehlkonfiguration.
Eigentlich passt das mit der Angabe des TO. Er schreibt ja selber das er im OpenVPN ein Gateway redirect macht über die Konfig. Daher wird bei aktivem OpenVPN Client (eben NUR wenn er aktiv ist) das Default Gateway von der oben verwendeten FritzBox fest auf den VPN Tunnel gelegt. (Internes OVPN Netz vermutlich 10.10.22.0 /24 ?!)
Bedeutet dann das mit aktivem OVPN Client dann sämtlicher Traffic immer üner den VPN Tunnel geroutet wird. Egal was...
Die Konfig bzw. der Output der Route Tabelle oben offenbart aber auch einen vermutlichen Kardinalsfehler den der TO bei der OpenVPN Einrichtung gemacht hat. Er verwendet sehr wahrscheinlich das veraltete /30er Subnet Konstrukt in der Server Konfig. Das ist ziemlich kontraproduktiv und sollte man keinesfalls mehr machen.
Siehe dazu auch das hiesige OpenVPN Tutorial:
Merkzettel: VPN Installation mit OpenVPN
Man sollte immer das modernere Subnet Konzept verwenden mit dem Kommandos
topology subnet
push "topology subnet"
auf der OVPN Server Seite, was die native Maske des internen OpenVPN Netzes verwendet.
Viele beachten IPv6 nicht
Richtig ! Das hat sogar noch Routing Priorität VOR IPv4. Leider macht der TO ja dazu keinerlei Angaben so das man nur raten kann oder die Kristallkugel bemühen !
Member: tikayevent
tikayevent May 04, 2020 at 12:24:26 (UTC)
Goto Top
Hat der Server nur IPv4-DNS-Einträge oder ist dieser nur per IPv4 erreichbar? Ich kenn Jitsi jetzt nicht, aber nicht, dass dieser irgendwie dem Client übermittelt, dass der Client sich über IPv6 verbinden soll.
Bei SIP wäre dieses nämlich mehr als möglich, weil hier der Datenstrom ja bevorzugt direkt fließt. Wenn da irgendwie die IPv6-Adresse bekannt wird, dann kann auch dieser Weg genutzt werden.

Ich kenn OVPN jetzt nicht, ich weiß aber nicht, wie hartnäckig es bei der Routingtabelle ist. Zeigt die Routingtabelle den Stand nach dem Aufbau der Verbindung oder wenn dein Problem aufgetreten ist? Nicht dass Teile der Tabelle, wodurch auch immer, verändert wurden.
Member: UnbekannterNR1
UnbekannterNR1 May 04, 2020 at 12:48:30 (UTC)
Goto Top
Danke schonmal für die Ideen,

Wir müssen ein wenig IPs sparen als teil einer Gesamtstruktur, daher ist für diese OpenVPN Instanz nur ein /26 Netz über geblieben was für die ca. 20 Clients ja auch reicht. Also genau genommen 10.10.22.64/26.
Client mit der IP .75 und Gateway auf 65 würde auch nicht in ein /30ger gehen ;)


unbenannt

IPv6 ist an der stelle halt mit absicht "kaputt" Konfiguriert weil wir es noch nicht implementiert haben. Und bei dem Webserver handelt es sich um einen Hypervisor (Proxmox) mit einer PFSense die alls managed. Und in dieser kann ich definitiv sehen das die Verbindung per IPv4 hergestellt wird.

Die Routing tabelle ist oben ist mit aufgebauter VPN. Der VPN wird von einem Dienst verwaltet und läuft immer. Sobald Internet vorhanden ist wird auch eine VPN aufgebaut.

Und zur vollständigkeit nocht die IPv6 Routing Tabelle.

   route print -6
===========================================================================
Schnittstellenliste
  9...00 ff 36 9e b6 a8 ......TAP-Windows Adapter V9
 15...d0 67 e5 3c f9 c5 ......Broadcom NetXtreme 57xx Gigabit Controller
  4...62 d8 19 7e 93 1e ......Microsoft Wi-Fi Direct Virtual Adapter
 11...62 d8 19 7e 9b 1e ......Microsoft Wi-Fi Direct Virtual Adapter #2
  2...60 d8 19 7e 93 1e ......DW1530 Wireless-N WLAN Half-Mini Card
 16...60 d8 19 fb 3b e9 ......Bluetooth Device (Personal Area Network)
  1...........................Software Loopback Interface 1
===========================================================================

IPv6-Routentabelle
===========================================================================
Aktive Routen:
 If Metrik Netzwerkziel             Gateway
  9    259 ::/3                     fe80::8
  1    331 ::1/128                  Auf Verbindung
  9    259 2000::/4                 fe80::8
  9    259 3000::/4                 fe80::8
  9    259 fc00::/7                 fe80::8
  9    259 fe80::/64                Auf Verbindung
  2    306 fe80::/64                Auf Verbindung
  9    259 fe80::/64                fe80::8
  9    259 fe80::1009/128           Auf Verbindung
  9    259 fe80::4d37:683a:13d8:ca28/128
                                    Auf Verbindung
  2    306 fe80::c5da:6afa:900e:c5d5/128
                                    Auf Verbindung
  1    331 ff00::/8                 Auf Verbindung
  9    259 ff00::/8                 Auf Verbindung
  2    306 ff00::/8                 Auf Verbindung
===========================================================================
Ständige Routen:
  Keine
Member: aqui
aqui May 04, 2020 updated at 14:06:29 (UTC)
Goto Top
daher ist für diese OpenVPN Instanz nur ein /26 Netz über geblieben was für die ca. 20 Clients ja auch reicht.
Jein !
Wenn du die OpenVPN klassische /30er Verteilung (Default = topology net30 ) nimmst reicht es nicht, denn dann wir das Netzwerk pro Client in ein /30 geteilt. Da ist dann bei 15 Clients Schluss.
Das ist der Fall wenn man nicht die neuere topology subnet im Server vorgibt und an die Clients pusht.
Nicht das du hier einen Denkfehler begehst ?!
Client mit der IP .75 und Gateway auf 65 würde auch nicht in ein /30ger gehen
So eine Verteilung gäbe es im klassischen topology net30 Verfahren ja auch niemals. Da ist jedes Subnetz ein Point2Point und belasstet den Server eben stark.
Wie gesagt net30 ist immer Default wenn man es nicht explizit in der Konfig ändert.
Und in dieser kann ich definitiv sehen das die Verbindung per IPv4 hergestellt wird.
Könntest du auch erzwingen wenn du den Shell Zugriff aktivierst und dir unter /etc/openvpn mal die werkelnde Server Konfig ansiehst. face-wink Da sollte "udp4" dann stehen !
Member: UnbekannterNR1
UnbekannterNR1 May 05, 2020 at 08:22:58 (UTC)
Goto Top
Nicht das du hier einen Denkfehler begehst ?!
Ich denke/hoffe nicht, ist schon Subnet nur halt ein wenig kleiner.
anmerkung 2020-05-05 095839

Und im Online Server kann ich sehen das die Verbindung definitiv IPv4 ist.
Jitsi VM auf der 111.17 Public Server IP 88.xx.xx.170, Clients 2x Arbeit und die Fritzbox PublicIP.
anmerkung 2020-05-05 100921

Das Problem muss ja irgendwo im Clientbereich liegen. Warum baut er die Verbindung über beide Routen auf? Normal müsste er sich doch auf die VPN route beschränken da diese kleiner ist. Und Metrik ist auch noch kleiner.
0.0.0.0          0.0.0.0    192.168.178.1   192.168.178.56     50
0.0.0.0        128.0.0.0     10.10.22.65     10.10.22.75      3
Member: aqui
aqui May 05, 2020 updated at 11:40:08 (UTC)
Goto Top
Warum baut er die Verbindung über beide Routen auf?
Das ist technisch eigentlich unmöglich. Es sollte immer nur über das 10.10.22.75 Gateway gehen, denn das hat die beste Metrik und ist für den TCP/IP Stack damit zwingend. Nur bei gleicher Metrik kommen es zu einem Session Balancing. Aber eben nur Session.
Möglich aber auch das Microsoft MPTCP dir da einen Streich spielt https://de.wikipedia.org/wiki/Multipath_TCP
Es kann definitiv rein nur vom Client kommen !
Hast du mal einen Traceroute vom Client gemacht auf die Ziel IP ??
Was kommt dabei raus ??
Member: Deepsys
Deepsys May 05, 2020 at 12:45:09 (UTC)
Goto Top
Hi,

sowas beobachte ich auch bei unseren Clients, allerdings nicht mit OpenVPN sondern mit einer Watchguard und IKEv2.
Eigentlich sollte alles in den Tunnel, aber es gibt die beiden 0.0.0.0 Routing Einträge im Windows 10 Client.
Und wenn deine IP über beide Wege erreichbar ist, dann geht es anscheinend mal direkt raus, mal durch den Tunnel.

Konkret testen wir gerade SoftClients für die TK-Anlage, klappte bei dem einem Kollegen per VPN absolut nicht.
Der andere sagt, macht er schon die ganze Woche mit VPN und klappt???

Lösung; der erste Kollegen öffnet die TK-Software mit dem Softphone nach dem VPN-Aufbau und bleibt an unserer Firewall hinter dem VPN kleben.

Der andere Kollegen startet das softphone mit Windows, also vor dem VPN, und baut dann erst das VPN auf. Die Verbindung geht extern und bleibt es auch. Also obwohl der Tunnel steht, bleibt das alte Routing aktiv. Auch wenn er die App neu startet geht es, als ob die alte Verbindung gemerkt wurde.

Das gleiche haben wir mit TeamViewer festgestellt: Verbindung mit TeamViewer vor dem VPN, dann wird VPN aufgebaut und meistens stirbt dann die TeamViewer Sitzung da diese in der Firewall nicht erlaubt ist (hinter dem VPN).
Manchmal bleibt die Teamviewer Sitzung aber auf, da der "Stream" eben nicht durch den Tunnel geht.

So richtig klar ist mir das Verhalten nicht, aber es existiert.

Evtl. ist es wirklich das MPTCP was aqui eben ansprach.

Bei unserem Fall sehe ich kein Risiko, da die SoftPhones auch extern über Handy funktionieren soll.

Viele Grüße
Deepsys
GermanQuestionRouters, RoutingNetworks
Hotly discussed
DaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment