zeroblue2005
Goto Top

Routing und RAS VPN in einem anderen Netz nutzen

Hallo Zusammen,

ich stehe vor einem kleinen Problem, wo ich nicht genau weiß, wie ich dies lösen soll! Daher hier erstmal eine
IST-Beschreibung:

2017-01-30_081403

Wie auf dem Bild gut zu sehen, ist dies das Netzwerk aus Sicht der TCP-Verbindungen. Der obere Kasten links zeigt einen Teil des Inhaltes der laufenden VMs auf dem ESXI. Der ESXI besitzt zwei Lankarten eine für das 177.0 Netz (Grün) und eine für das 178.0 Netz (Rot). Diese werden dann über die verschiedenen VMs-NIC Lankarten und V-Switche angesteuert! Wer sich jetzt fragt, warum ich da noch einen weiteren Router ins Netz gesetzt habe, dem sei gesagt, dass es hier weder um mehr IP-Sicherheit geht noch um mehr Schutz vor Einbruch. Der IP-Cop brachte damals einfach einen guten Proxy und URL-Filter mit und daher steht der dort drin. Da er aber auch gleichzeitig eine Router/Firewall ist, konnte ich diese ja nicht einfach ausschalten.

Damit Benutzer den Terminal-Server aus dem Internet erreichen können, müssen diese eine PPTP VPN aufbauen. In den Fritz!Boxen ist der Exposed Host aktiviert. Sprich Firewall lässt alles durch. Die Port Weiterleitungen gehen erst am Dual-Wan Router los. Dort sind derzeit das GRE und TCP 1723 auf den IP-COP weitergeleitet, also auf 177.5 der Routet dann schön weiter auf den VPN-Server und der Terminal-Server ist erreichbar. Alles gut und schön!

SOLL-Zustand:
Auch wenn mich jetzt einige steinigen werden, weil ich das Thema viel zu spät angehe, möchte ich endlich die Verbindung nicht mehr als PPTP-VPN laufen lassen sondern als L2TP mit IPSEC. Also ich den PORT UDP 500 + 4500 und das ESP weitergeleitet auf den VPN-Server und versucht von einem Client aus dem 177.0 Netz herzustellen, also unabhängig vom Internet. Es haut einfach nicht hin, so als wenn die ESP nicht vorhanden ist. Eine Verbindung intern im 178.0 Netz geht ohne Probleme. Mir ist klar, dass es sich hier um ein Problem des IP-Cop handelt. Hier habe ich die Jungs im IP-Forum auch schon gequält, die sind aber auch mit Ihrem Latin am ende!

Also dachte ich mir, was soll es verpasse doch einfach die dem VPN-Server im 178.0 Netz eine zusätzliche V-Lankarte und verbinde die mit dem V-Swith, so das die Verbindung am IP-Cop vorbei läuft! Gemacht getan. Es läuft. Dann das ganze auch noch mal direkt sofort getestet aus dem Internet. Auch das ging so weit, erst mal gut!

Jetzt zum Problem:
Zwei Lankarten mit zwei unterschiedlichen Gateways kann nicht gut gehen, den ich merkte sehr schnell, dass die Verbindung nur sporadisch aufgebaut wurde. Mal ja mal nein und dies abhängig davon, ob die Lankarte einen Gateway hatte oder nicht!

Ich muss also eine Lösung haben, wo Routing und RAS VPN nicht den Standardgatway benutzt! Wie kann ich das Problem lösen?

Danke...

PS: Ich hoffe, ich konnte das verständlich rüberbringen...

Content-Key: 327938

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

Ausgedruckt am: 19.03.2024 um 02:03 Uhr

Mitglied: aqui
Lösung aqui 30.01.2017 aktualisiert um 11:48:49 Uhr
Goto Top
Mal zum ersten Problem:
Einen gravierenden IP Adressdesignfehler gibt es am Dual WAN Router !
So wie das da dargestellt ist geht das niemals !
Die beiden WAN Ports müssen zwangsweise in unterschiedlichen IP Netzen liegen.
Deine Angaben sind etwas zweideutig aber "176.1" wird vermutlich 192.168.176.1 bedeuten oder ?
Da offenbart sich dann ein fataler Fehler, denn die beiden WAN Anschlüsse müssen in 2 unterschiedlichen IP Netzen liegen, was bei dir nicht der Fall ist.
Beide Netze sind getrennet eigenständige Point to Point IP Netze.
Du müsstest dort also minimal einen /30er Prefix verwenden (Maske 255.255.255.252) dann sieht das so aus:
WAN Netz 1:
Netzwerk: 192.168.176.0 /30
Dual WAN Router Port IP: 192.168.176.1 /30
Backbonerouter 1 IP: 192.168.176.2 /30

WAN Netz 2:
Netzwerk: 192.168.176.4 /30
Dual WAN Router Port IP: 192.168.176.5 /30
Backbonerouter 1 IP: 192.168.176.6 /30


Eine andere Prefix Kombination (z.B. /25, Maske: 255.255.255.128) ist natürlich auch machbar:
WAN Netz 1:
Netzwerk: 192.168.176.0 /25
Dual WAN Router Port IP: 192.168.176.1 /30
Backbonerouter 1 IP: 192.168.176.2 /30

WAN Netz 2:
Netzwerk: 192.168.176.128 /25
Dual WAN Router Port IP: 192.168.176.129 /25
Backbonerouter 1 IP: 192.168.176.130 /25


Oder eben alles was dazwischenliegt. Das solltest du dringenst anpassen ansonsten wird das nie klappen mit dem Balancing !

Nun zu deinem Problem:
müssen diese eine PPTP VPN aufbauen.
Oha...gelesen hast du das hier:
https://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.h ...
Nur mal so zur Info und zum Nachdenken. Der Proxy Filter ist übrigens nichts Außergewöhnliches das kann jede IP Firewall wie z.B. auch die pfSense usw.
Ausschalten hätte man das auch können indem du nämlich die FW als transparente Firewall im L2 betrieben hättest. Dann wäre sie einfach im L2 Netz ohne Routing gewesen. Das hast du aber wohl vermutlich aus Unkenntniss übersehen oder aber die IP Cop FW supportet das schlicht nicht im Gegensatz zur pfSense... Aber egal...ist ne völlig andere Baustelle !
Dort sind derzeit das GRE und TCP 1723 auf den IP-COP weitergeleitet, also auf 177.5 der Routet dann schön weiter auf den VPN-Server und der Terminal-Server ist erreichbar.
Uuuhhh...welch gruseliges Design ! Ums mal vorsichtig zu sagen...
Vorher wird das einmal über den vSwitch des ESXi geleitet. Welcher Frickelbastler hat sich den sowas Übles ausgedacht...? Klar geht, aber aus Designgründen ein übles Bastel- und Frickeldesign.
Mal ganz abgesehen von der Tatsache das VPNs niemals ins interne Netz geschleift gehören sondern immer am Perimeter terminiert werden sollten.
Also dortige VPN Router oder der zentralen Firewall wie deinem IP Cop. Das der das auch kann siehst du ja an diesem_Tutorial. Sogar PPTP kann sie. Auch ein ziemlicher und grundlegender VPN Designfehler für den man dich zwar nicht gleich steinigen aber doch kritisieren müsste.
Ist jetzt aber fairerweise geraten weil du zum exakten VPN Design ja keinerlei zielführende Angaben machst face-sad
Es haut einfach nicht hin, so als wenn die ESP nicht vorhanden ist.
Da wären dann einmal die Logs des VPN Clients und besonders auch des VPN Servers sehr hilfreich hier zum Troubleshooting. Auch hier wieder nix von dir was uns helfen könnte zur Eingrenzung. face-sad
Ebenso wichtig ein Wireshark Trace der dir am VPN Server überhaupt anzeigt ob deine IPsec Pakete dort überhaupt ankommen. Auch nix von deiner Seite...
Zuletzt wäre es sehr wichtig zu wissen WO den dein VPN nun letztendlich terminiert wird. Bei dem gruseligen VPN Design muss man das Schlimmste annehmen und vermuten das es einer der VM Server ist. Im Worst Case noch ein Microsoft Server ?!
Du schreibst das du L2TP mit IPsec machst. Ist dem wirklich so ?
Wenn ja reicht dir UDP 500, 4500 und ESP dann NICHT sondern du musst zwangsweise auch noch UDP 1701 den L2TP Port forwarden, sonst klappt nix natürlich.
Die 3 ersten VPN Protokollkomponenten reichen nur wenn du native IPsec machst. Laut deinen eigenen Angaben machst du ja aber L2TP und da reicht es dann nicht.

Vermutlich alles 3 wichtige Dinge die du alle beim VPN Setup nicht beachtet oder nicht kontrolliert hast, wobei der fehlende Port UDP 1701 noch das Gravierenste hier ist.
Zwei Lankarten mit zwei unterschiedlichen Gateways kann nicht gut gehen
Das kann man so pauschal nicht sagen. Wenn du "mit Microsoft" noch dazugesagt hättest wäre es richtig gewesen. MS kann damit in der Tat nicht umgehen und welches Gateway final benutzt wird hängt dann IMMER von der Bindungsreihenfolge der Netzwerk Adapter ab.
Das was an Stelle 1 steht bestimmt auch das Gateway, das andere Gateway wird schlicht ignoriert.
Dieses Forumstutorial beschreibt die Details dazu:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Fazit:
Dein ganzes Netzwerk Konzept sowohl Routing als auch die Infrastruktur krankt ganz erheblich an gravierenden Designproblemen, wovon die IP Adressierungsprobleme am Dual WAN und intern die Schlimmsten sind.
Vom Fehler im VPN Handling mal gar nicht zu reden.
Daraus resultieren aber auch so schlimme Designfehler wie das Durchschleifen im L2 von sicherheitsrelevantem Traffic auf den vSwitches und Terminieren von der exposed Host Traffic an einer zentralen Komponente wie dem VM Server.
Da ist so ziemlich alles falsch was man falsch machen kann !
Du solltest dich also zuallererst mal hinzetzen und ein neues Infrastruktur Design umsetzen und diese Frickelkonstruktion etwas entzerren und aus Sicherheitssicht wasserdicht machen.
Dann die IP Adressierung mal auf Vordermann bringen und Fehler beseitigen. Sachen wie das VPN Handling, WAN Balancing usw. erledigen sich dann meist schon daraus mit von selber.
Danach machen wir dann hier mal weiter mit dem Eingemachten ! Um das Problem umfassend zu lösen hast du gleich mehrere Baustellen.
Und ja....du konntest es verständlich rüberbringen face-wink (Leider muss man ja fast sagen...)
Mitglied: zeroblue2005
zeroblue2005 30.01.2017 um 12:48:04 Uhr
Goto Top
OK.... dann mache ich mal meine Hausaufgaben und sehe dann weiter. Danke für die Infos...
Mitglied: zeroblue2005
zeroblue2005 30.01.2017 um 19:08:17 Uhr
Goto Top
Ich muss noch mal nachfragen. Ich verstehe nicht ganz, warum die beiden Wan Ports in unterschiedlichen Netzen liegen müssen?

Kannst du mir das ein wenig erklären, dass wäre super.

Der Modus des des Dual Wan Router ist bei mir nicht failover. Sondern Lastenausgleich.

Das Klappt auch, dass sehe ich Anhand der wechselnden öffentlichen IP Adresse im Browser.

Auch das Problem mit der VPN bei IP Sec habe ich gelöst. Es war ein Problem des Windows Client. Habe die Regestry angepasst und Port 1701TCP weitergeleitet. Jetzt klappt es stabil.

NichtS desto Trotz, werde ich mir das das was du geschrieben hast zu Herzen nehmen und überarbeiten.

Nur das mit der falschen Wan Konfiguration verstehe ich nicht...
Mitglied: zeroblue2005
zeroblue2005 26.02.2017 um 20:33:10 Uhr
Goto Top
Ich wollte dir nur kurz mitteilen, dass ich ein Teil der Hausaufgaben gemacht habe. Insbesondere das mit dem Dualwan bzw. unterschiedlichen IP Netzen.

Der Fehler war tatsächlich der Port UDP 1701 zusätzlich hat die Fritz.Box wohl trotz richtiger Konfig. Einen internen Fehler, so daß ich die Fritz.Box mit einem Recover wiederherstellen musste. Hiernach klappte alles.

Danke für die Denkanstöße
Mitglied: aqui
aqui 27.02.2017 um 10:50:18 Uhr
Goto Top
Der Fehler war tatsächlich der Port UDP 1701
Den brauchst du aber nur wenn du L2TP machst !
Bei reinem IPsec VPNs ist der vollkommen irrelevant.
Aber gut wenns nun klappt.