9
VPN Route wird umgangen
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
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.
Edit: Der Onlineserver hat nur nur Ipv4 DNS einträge wir verwenden generell noch ausschließlich ipv4.
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
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 306Edit: Der Onlineserver hat nur nur Ipv4 DNS einträge wir verwenden generell noch ausschließlich ipv4.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 569460
Url: https://administrator.de/contentid/569460
Ausgedruckt am: 24.11.2024 um 13:11 Uhr
9 Kommentare
Neuester Kommentar
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.
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.
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.
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.
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 !
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.
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.
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 ;)
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.
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 ;)
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:
Keinedaher 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. 
Da sollte "udp4" dann stehen !Nicht das du hier einen Denkfehler begehst ?!
Ich denke/hoffe nicht, ist schon Subnet nur halt ein wenig kleiner.
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.
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 3Warum 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 ??
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
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
