16
router mit friewall und vpn
Hallo,
ich habe gerade mal wieder die unglaubliche Anzahl von Router mit Firewall und VPN gesehen.
jetzt weiß ich nicht welchen ich mir holen soll. Er soll für ein kleines Firmennetzwerk sein mit einem Seitch 16 Ports (welchen ich auch noch kaufen muss, er sollte Gibabit haben). Kann ich einen Router nehmen mit internert Firewall oder liiber eine Firewall dahinschalten? Der Router sollte auch eine statische Abindung an das Internet bieten, da eine statische IP ja wieder unsummen kostet.
Was würde ihr mir Empfhelen. Das netzwerk wird rein aus Apple bestehen. Dachte so an 400 bis 500 Euro Investbetrag.
Danke
Gruß
Bongartz
ich habe gerade mal wieder die unglaubliche Anzahl von Router mit Firewall und VPN gesehen.
jetzt weiß ich nicht welchen ich mir holen soll. Er soll für ein kleines Firmennetzwerk sein mit einem Seitch 16 Ports (welchen ich auch noch kaufen muss, er sollte Gibabit haben). Kann ich einen Router nehmen mit internert Firewall oder liiber eine Firewall dahinschalten? Der Router sollte auch eine statische Abindung an das Internet bieten, da eine statische IP ja wieder unsummen kostet.
Was würde ihr mir Empfhelen. Das netzwerk wird rein aus Apple bestehen. Dachte so an 400 bis 500 Euro Investbetrag.
Danke
Gruß
Bongartz
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: 56157
Url: https://administrator.de/forum/router-mit-friewall-und-vpn-56157.html
Ausgedruckt am: 23.12.2024 um 09:12 Uhr
16 Kommentare
Neuester Kommentar
Die Frage ist ob du auch von extern einen VPN Zugang auf das Netz realisieren musst in das Netzwerk ???
In dem Falle ist es immer besser einen Router mit integrierter VPN Funktion zu erwerben (wie z.B. einen Draytek o.a.) Das erspart dir das leidige Konfigurieren von Port Forwarding etc. Außerdem befreit es dich vom permanenten Laufenlassen eines VPN Servers oder solch einer Funktion im lokalen LAN, da der Router diese Funktion zur Verfügung stellt.
Ist das Thema VPN keins für dich und du musst für die 16 Ports nur einen einfachen Internetzugang realisieren ist es egal was du nimmst. Jeder einfache DSL Router von Linksys, NetGear und wie sie alle heissen erledigt das was du willst... Alle diese Systeme (auch die o.g. VPN fähigen Systeme) haben eine integrierte Firewall die für so ein Netzwerk vollkommen ausreicht.
Ebenso ist es beim Switch. Bei lediglich 16 Ports wirds dir sicher nicht auf Managebarkeit ankommen, so das du dort jeden Noname GiG Switch verwenden kannst.
In dem Falle ist es immer besser einen Router mit integrierter VPN Funktion zu erwerben (wie z.B. einen Draytek o.a.) Das erspart dir das leidige Konfigurieren von Port Forwarding etc. Außerdem befreit es dich vom permanenten Laufenlassen eines VPN Servers oder solch einer Funktion im lokalen LAN, da der Router diese Funktion zur Verfügung stellt.
Ist das Thema VPN keins für dich und du musst für die 16 Ports nur einen einfachen Internetzugang realisieren ist es egal was du nimmst. Jeder einfache DSL Router von Linksys, NetGear und wie sie alle heissen erledigt das was du willst... Alle diese Systeme (auch die o.g. VPN fähigen Systeme) haben eine integrierte Firewall die für so ein Netzwerk vollkommen ausreicht.
Ebenso ist es beim Switch. Bei lediglich 16 Ports wirds dir sicher nicht auf Managebarkeit ankommen, so das du dort jeden Noname GiG Switch verwenden kannst.
danke dür die schnelle antowert.
also ein vpn zugang ist schon sehr wichtig für mich. und ich würde diesen gerne nur über den router und nicht extra über einen server laufen lassen.
also ein vpn zugang ist schon sehr wichtig für mich. und ich würde diesen gerne nur über den router und nicht extra über einen server laufen lassen.
OK, dann gilt das oben gesagte und du solltest auf die vorhandenen VPN Server Fähigkeiten bei den Routern unbedingt achten !!! Ausser Draytek gibts da auch noch andere Hersteller....
hab gesehen das dlink bei jedem model das anbiete aber wenn ihr gute erfahrung damit gemacht habt dann hol ich mir leider einen von euch empfohlenden
oder was haltet ihr davon soll ja ein mac netzwerk werden. kommt natürlich noch ein gigabit switsh dahinter
http://www.apple.com/de/airportextreme/specs.html
oder was haltet ihr davon soll ja ein mac netzwerk werden. kommt natürlich noch ein gigabit switsh dahinter
http://www.apple.com/de/airportextreme/specs.html
Vorsicht bei D-Link Features ! Billigheimer aus dem Blöd Markt meinen damit meist immer VPN Passthrough Funktionen oder sowas !! Das bedeutet lediglich das die VPN Verbindungen forwarden können aber nie das sie selber aktiv VPN Server sind. Eine Funktion die du ja zwingend benötigst bei dem was du vorhast !
Das muss dort dediziert vermerkt sein. Im Firmenumfeld ist so ein Consumer Produkt sowieso die falsche Wahl !
Der Airport Extreme ist schon ein gutes Produkt, supportet aber auch wieder wie du unten in den Spezifikationen ja selber unschwer lesen kannst nur VPN Passthrough, kann also folglich auch nur VPN Protokolle forwarden aber nicht selber handeln !!!
Damit scheidet das System auch aus für deine Anforderungen !
Hier:
http://www.vigorkom.de/Produkt_Vigor2800VGi_Datenblatt.htm
Kannst du z.B. mal sehen was da genau stehen muss zu den VPN Features unter VPN !!!
Das muss dort dediziert vermerkt sein. Im Firmenumfeld ist so ein Consumer Produkt sowieso die falsche Wahl !
Der Airport Extreme ist schon ein gutes Produkt, supportet aber auch wieder wie du unten in den Spezifikationen ja selber unschwer lesen kannst nur VPN Passthrough, kann also folglich auch nur VPN Protokolle forwarden aber nicht selber handeln !!!
Damit scheidet das System auch aus für deine Anforderungen !
Hier:
http://www.vigorkom.de/Produkt_Vigor2800VGi_Datenblatt.htm
Kannst du z.B. mal sehen was da genau stehen muss zu den VPN Features unter VPN !!!
Hi,
ich nutze selbst den Vigor 2950 (serverseitig)und muss sagen ein Superteil! Preis-Leistung ist wohl nicht zu toppen, habe mehrere Hersteller auf der Cebit "abgeklappert" und mich für Draytek entschieden, jetzt läuft das Netzwerk mit VPN und alles ist noch bezahlbar.
ich nutze selbst den Vigor 2950 (serverseitig)und muss sagen ein Superteil! Preis-Leistung ist wohl nicht zu toppen, habe mehrere Hersteller auf der Cebit "abgeklappert" und mich für Draytek entschieden, jetzt läuft das Netzwerk mit VPN und alles ist noch bezahlbar.
Hallo allerseits,
verwende eine Draytek Vigor 5500Pro und bei einem anderen Netzwerk den Vigor 2950.
Beide Netze haben nichts miteinander zu tun, sie sollen jeweils nur von außen via VPN erreichbar sein, d.h. keine VPN unter einander. In beiden Netzen hängt der jeweilige Router vor einem Windows Server 2003 SBS, je mit 2 NICs (eine für WAN- andere für LAN-Seite).
Die Server Naten jeweils.
Möchte die Router internen VPN Möglichkeiten allerdings nicht nutzen und habe diese abgeschaltet.
Dann gibt es allerdings ein Problem.
Im Basis Filter wünsche ich mir bei jdem der Router per default auf "block" einzustellen.
In der Nat bringen open-Ports, Port-Forwarding bzw. DMZ gar nichts, da die Firewall die Verbindungen laut Draytek trotzdem kontrolliert. Für was hat man dann noch eine DMZ?
Wenn das nichts bringt, so dachte ich mir, mache ich halt unter anderem die Ports 1723 (TCP) und IP-Protokol 47 (GRE) nach innen und außen auf (pptp). Do geht das leider aber auch nicht.
Erst wenn sämtliche TCP-Ports (1-65535) nach außen geöffnet werden geht es. Nicht sonderlich toll, oder.
Draytek sagt:
- Basisfilter auf "block" macht keinen Sinn, da Filter eh nur von innen nach außen wirkt.
von außen nach innen wirkt die NAT und daher kann der Filter auf "pass" gestellt werden.
- Firewall kontrolliert sämtliche Verbindung auch bei DMZ, open-Ports, Port-Forwarding.
- Microsoft würde sich eventuell nicht an die RFC halten. Wir hatten versucht den TCP-Port
einzugrenzen, der von innen geöffnet werden muß, doch liegt scheinbar immer anders.
Daher haten wir Erfolg, als wir alle TCP nach außen geöffnet hatten.
Im Moment, bis zu Lösung des Problems, haben wir einen alten Vigor 2200i im Einsatz. Der macht nämlich alles. Laut Draytek arbeitete da noch die Firewall anders.
Weis da jemand mehr?
Wie verhält es sich mit dem SBS und RFC?
Hat Draytek mit seinen Behauptungen recht, oder ist das nur eine Ausrede bis das Problem gelöst ist?
Gruß
Dimugi
verwende eine Draytek Vigor 5500Pro und bei einem anderen Netzwerk den Vigor 2950.
Beide Netze haben nichts miteinander zu tun, sie sollen jeweils nur von außen via VPN erreichbar sein, d.h. keine VPN unter einander. In beiden Netzen hängt der jeweilige Router vor einem Windows Server 2003 SBS, je mit 2 NICs (eine für WAN- andere für LAN-Seite).
Die Server Naten jeweils.
Möchte die Router internen VPN Möglichkeiten allerdings nicht nutzen und habe diese abgeschaltet.
Dann gibt es allerdings ein Problem.
Im Basis Filter wünsche ich mir bei jdem der Router per default auf "block" einzustellen.
In der Nat bringen open-Ports, Port-Forwarding bzw. DMZ gar nichts, da die Firewall die Verbindungen laut Draytek trotzdem kontrolliert. Für was hat man dann noch eine DMZ?
Wenn das nichts bringt, so dachte ich mir, mache ich halt unter anderem die Ports 1723 (TCP) und IP-Protokol 47 (GRE) nach innen und außen auf (pptp). Do geht das leider aber auch nicht.
Erst wenn sämtliche TCP-Ports (1-65535) nach außen geöffnet werden geht es. Nicht sonderlich toll, oder.
Draytek sagt:
- Basisfilter auf "block" macht keinen Sinn, da Filter eh nur von innen nach außen wirkt.
von außen nach innen wirkt die NAT und daher kann der Filter auf "pass" gestellt werden.
- Firewall kontrolliert sämtliche Verbindung auch bei DMZ, open-Ports, Port-Forwarding.
- Microsoft würde sich eventuell nicht an die RFC halten. Wir hatten versucht den TCP-Port
einzugrenzen, der von innen geöffnet werden muß, doch liegt scheinbar immer anders.
Daher haten wir Erfolg, als wir alle TCP nach außen geöffnet hatten.
Im Moment, bis zu Lösung des Problems, haben wir einen alten Vigor 2200i im Einsatz. Der macht nämlich alles. Laut Draytek arbeitete da noch die Firewall anders.
Weis da jemand mehr?
Wie verhält es sich mit dem SBS und RFC?
Hat Draytek mit seinen Behauptungen recht, oder ist das nur eine Ausrede bis das Problem gelöst ist?
Gruß
Dimugi
Das könnte sein das die FW Funktionalität unterschiedlich implementiert ist. Sofern der PPTP Port in der VPN Funktion des Routers nicht händisch zu deaktivieren ist wie es im alten Modell passiert lässt er entsprechende Frames nicht durch für diese Protokoll, denn er nimmt dann immer sich als PPTP Server an.
Allerdings muss du dich ehrlich mal nach dem Sinn und Unsinn einer solchen WAN Anbindung fragen lassen ??!!
Das der Server selber noch NAT macht ist nach normalen Masstäben vollkommen unsinnig wenn auch der Router das tut. Kein normaler Mensch tut sich das an VPN Protokolle 2 mal revers über eine NAT Firewall zu bringen. Den teifen Sinn von sowas müsstest du nochmal erklären.... Ebenso die Forderung PPTP forzuwarden auf einen Server obwohl so etwas mit einem VPN föhigen Router erheblich besser und effizienter zu lösen ist.
Das Kern Problem liegt also mehr in diesem verquarsten Design bzw. Anforderung deinerseits.
Allerdings muss du dich ehrlich mal nach dem Sinn und Unsinn einer solchen WAN Anbindung fragen lassen ??!!
Das der Server selber noch NAT macht ist nach normalen Masstäben vollkommen unsinnig wenn auch der Router das tut. Kein normaler Mensch tut sich das an VPN Protokolle 2 mal revers über eine NAT Firewall zu bringen. Den teifen Sinn von sowas müsstest du nochmal erklären.... Ebenso die Forderung PPTP forzuwarden auf einen Server obwohl so etwas mit einem VPN föhigen Router erheblich besser und effizienter zu lösen ist.
Das Kern Problem liegt also mehr in diesem verquarsten Design bzw. Anforderung deinerseits.
Sorry,
liegt einfach daran das sich am Server das NAT nicht einfach los werden läßt ohne das der sich beschwert.
Als Router zum vm LAN zum Router soll dieser auf jedenfall dienen, sonst könnte ich ja gleich das ganze interne LAN an den Router hängen. Klar, wenn ich das LAN direkt am DrayTek Router habe könnte ich die internen VPN des Draytek nutzen. Wenn der SBS selbst Router ist ist das erst mal schwerer mit der VPN.
In größeren Netzen kommt aber mein Aufbau ähnlich schon vor, da hängt eben nicht alles direkt am Router und eventuell sind dort auch weitere geräte vorhanden die NAT nicht einfach so wegschalten lassen, oder?
Wie gewöhn ich dem Router das NAT ab sodas ich diesen weiterhin mit zwei NICs als Router gebrauchen kann?
Gruß
Dimugi
liegt einfach daran das sich am Server das NAT nicht einfach los werden läßt ohne das der sich beschwert.
Als Router zum vm LAN zum Router soll dieser auf jedenfall dienen, sonst könnte ich ja gleich das ganze interne LAN an den Router hängen. Klar, wenn ich das LAN direkt am DrayTek Router habe könnte ich die internen VPN des Draytek nutzen. Wenn der SBS selbst Router ist ist das erst mal schwerer mit der VPN.
In größeren Netzen kommt aber mein Aufbau ähnlich schon vor, da hängt eben nicht alles direkt am Router und eventuell sind dort auch weitere geräte vorhanden die NAT nicht einfach so wegschalten lassen, oder?
Wie gewöhn ich dem Router das NAT ab sodas ich diesen weiterhin mit zwei NICs als Router gebrauchen kann?
Gruß
Dimugi
...ohne das der sich beschwert..
Dann hast du (sorry, ist leider so) wohl was falsch gemacht bei der Einrichtung des Servers. In der Tat ist das ein gängiges Verfahren wie du hier:
ja unschwer sehen kannst ! Allerdings richtig aufgesetzt in einer gerouteten Umgebung und nicht nur in einen dummen flachen Layer 2 Design wie du es gemacht hast mit NAT am einen Serverende.
Dort.. liegt das Problem nicht am Router selber.
Das VPN sollte immer auf dem Router terminiert werden in so einem Design und niemals auf dem Server...was sollte das auch für einen Sinn haben. Denn genau so trennst du ja auch interne Clients von externen VPN Usern, genau solche Trennung willst du ja auch mit deinem design erreichen...oder ? Mit deinem VPN im Server konterkarierst du die gesamte Intention eines solchen Netzwerkdesigns...
Dann hast du (sorry, ist leider so) wohl was falsch gemacht bei der Einrichtung des Servers. In der Tat ist das ein gängiges Verfahren wie du hier:
ja unschwer sehen kannst ! Allerdings richtig aufgesetzt in einer gerouteten Umgebung und nicht nur in einen dummen flachen Layer 2 Design wie du es gemacht hast mit NAT am einen Serverende.
Dort.. liegt das Problem nicht am Router selber.
Das VPN sollte immer auf dem Router terminiert werden in so einem Design und niemals auf dem Server...was sollte das auch für einen Sinn haben. Denn genau so trennst du ja auch interne Clients von externen VPN Usern, genau solche Trennung willst du ja auch mit deinem design erreichen...oder ? Mit deinem VPN im Server konterkarierst du die gesamte Intention eines solchen Netzwerkdesigns...
Ich habe jetzt NAT auf dem Server entfernt.
Routen geht jetzt gar nicht mehr, d.h. mein Netzwerk liegt nun erst mal lahm.
Hab natürlich ein Image vom Server.
Habe Routing und RAS erst mal deaktiviert und neu eingerichtet.
Scheinbar versteh ich da verschiedene Dinge nicht, mit Linux ist das doch ne Ecke einfacher, denn was der Assistent des RAS so macht kann ich schlecht nach verfolgen.
Die Beschreibung aus dem Link enthält nach meiner Ansicht ein paar kleine Fehler und muß daher erst mal neu gedanklich sotiert werden. Das macht allerdings das umsetzen nicht einfacher.
Leider gibt es zum SBS als reinen Router zu wenig Info und wenn dann immer mit NAT, da
der Server immer als Internet-Gateway vermutet wird.
Was es bräuchte, wäre eine Detail-Beschreibung der Einrichtung als Router zwischen zwei Netzen. Diese sollte auch den Assistenten mit einbeziehen oder alle Kontrollpunkte eines Windows Servers beschreiben.
Tut mir leid, ich bin halt kein Mausschubser, mit Dialogen tu ich mich ein wenig schwer.
Microsoft macht es einem da ja auch nicht gerade einfach. Zu Standard Szenarien findet man ja jede Menge Literrtur, aber eben nichts was in die Tiefe geht.
Gibt es da irgendwo genaure Info's oder kann mir jemand sagen wie ich den Assistenten die richtigen Info's gebe und die Konfiguration hinter her kontrolieren kann?
Gruß
Dimugi
Routen geht jetzt gar nicht mehr, d.h. mein Netzwerk liegt nun erst mal lahm.
Hab natürlich ein Image vom Server.
Habe Routing und RAS erst mal deaktiviert und neu eingerichtet.
Scheinbar versteh ich da verschiedene Dinge nicht, mit Linux ist das doch ne Ecke einfacher, denn was der Assistent des RAS so macht kann ich schlecht nach verfolgen.
Die Beschreibung aus dem Link enthält nach meiner Ansicht ein paar kleine Fehler und muß daher erst mal neu gedanklich sotiert werden. Das macht allerdings das umsetzen nicht einfacher.
Leider gibt es zum SBS als reinen Router zu wenig Info und wenn dann immer mit NAT, da
der Server immer als Internet-Gateway vermutet wird.
Was es bräuchte, wäre eine Detail-Beschreibung der Einrichtung als Router zwischen zwei Netzen. Diese sollte auch den Assistenten mit einbeziehen oder alle Kontrollpunkte eines Windows Servers beschreiben.
Tut mir leid, ich bin halt kein Mausschubser, mit Dialogen tu ich mich ein wenig schwer.
Microsoft macht es einem da ja auch nicht gerade einfach. Zu Standard Szenarien findet man ja jede Menge Literrtur, aber eben nichts was in die Tiefe geht.
Gibt es da irgendwo genaure Info's oder kann mir jemand sagen wie ich den Assistenten die richtigen Info's gebe und die Konfiguration hinter her kontrolieren kann?
Gruß
Dimugi
Wo da die Fehler im Tutorial sind würde mich schon sehr interessieren. Vielleicht kannst du das mal per PM posten, dann kann ich das ggf. anpassen und korrigieren.
Normalerweise ist so ein Szenario denkbar einfach und zig mal schon installiert.
Wichtig ist das RAS/Routing aktiviert ist auf dem Server mehr muss man nicht machen, denn das entspricht analog dem was für 2000 und XP mit dem Registry Setting beschrieben ist (IP-Forwarding).
Ob der Server dann sauber routet kannst du kinderleicht sofort ausprobieren:
Nimmt dir je einen Client PC in beiden Segmenten setze deren IP Adresse entsprechend der Netzadresse im Segment und setze das default Gateway dieser PCs auf die IP Adresse des Servers im jeweiligen Segment.
Nun pingst du vom Client mal den Server und wenn das geht den PC im anderen Segment und vice versa das Gleiche, analog mit dem anderen PC.
Das sollte auf Anhieb problemlos klappen und zeigt dir sofort das der Server dann sicher routet !
Für das finale Setup dieses Designs machst du dann folgendes:
In dem Segment was KEINEN Router hat belässt du die Client IP Settings so ! Im Router Segment setzt du sie auf die Router IP und konfigurierst dem Router eine statische Route in das routerlose Client Segment.
Wie gesagt die Einzelschritte für diese Einrichtung sind sehr detailiert im Tutorial beschrieben so das auch Laien das problemlso verstehen sollten wenn sie denn wissen was eine IP Adresse ist.
Normalerweise ist so ein Szenario denkbar einfach und zig mal schon installiert.
Wichtig ist das RAS/Routing aktiviert ist auf dem Server mehr muss man nicht machen, denn das entspricht analog dem was für 2000 und XP mit dem Registry Setting beschrieben ist (IP-Forwarding).
Ob der Server dann sauber routet kannst du kinderleicht sofort ausprobieren:
Nimmt dir je einen Client PC in beiden Segmenten setze deren IP Adresse entsprechend der Netzadresse im Segment und setze das default Gateway dieser PCs auf die IP Adresse des Servers im jeweiligen Segment.
Nun pingst du vom Client mal den Server und wenn das geht den PC im anderen Segment und vice versa das Gleiche, analog mit dem anderen PC.
Das sollte auf Anhieb problemlos klappen und zeigt dir sofort das der Server dann sicher routet !
Für das finale Setup dieses Designs machst du dann folgendes:
In dem Segment was KEINEN Router hat belässt du die Client IP Settings so ! Im Router Segment setzt du sie auf die Router IP und konfigurierst dem Router eine statische Route in das routerlose Client Segment.
Wie gesagt die Einzelschritte für diese Einrichtung sind sehr detailiert im Tutorial beschrieben so das auch Laien das problemlso verstehen sollten wenn sie denn wissen was eine IP Adresse ist.
OK, nachdem ich eine Statische Route im Router gesetzt habe geht es.
Route= Ziel-IP z.Bsp. 192.168.1.0 (Client Netz an NIC1), Subnet 255.255.255.0, Gateway 192.168.2.1 (Seite an der der Router hängt.
Auf den Client's war alles ok, es ging ja auch mit NAT.
Sollte nur die fehlende statische allein daran Schuld gewesen sein, denn haupsächlich konnte ja noch nicht mal geservt werden (Verbindung nach draußen). Die statische Route wirkt doch erst mal nach innen, oder?
Fehler in der Angesprochenen Beschreibung liefere ich noch nach, da ich diese zusammestellen möchte.
Gruß Dimugi
Route= Ziel-IP z.Bsp. 192.168.1.0 (Client Netz an NIC1), Subnet 255.255.255.0, Gateway 192.168.2.1 (Seite an der der Router hängt.
Auf den Client's war alles ok, es ging ja auch mit NAT.
Sollte nur die fehlende statische allein daran Schuld gewesen sein, denn haupsächlich konnte ja noch nicht mal geservt werden (Verbindung nach draußen). Die statische Route wirkt doch erst mal nach innen, oder?
Fehler in der Angesprochenen Beschreibung liefere ich noch nach, da ich diese zusammestellen möchte.
Gruß Dimugi
Das war es wohl auch nicht.
Muß wohl von was weiterem abhängen. Ich hab auf dem Server nochmal alles neu eingestellt um das ganze nochmal zum Lernen durchzuspielen und plötzlich ging es trotz gleicher Einstllungen auf dem Clients und am Router nicht. Also doch nicht so einfach mal RAS/Routing aktivieren und alles geht.
Ich muß der Sache nochmal tiefer auf den Grund gehen.
Gruß Dimugi
Muß wohl von was weiterem abhängen. Ich hab auf dem Server nochmal alles neu eingestellt um das ganze nochmal zum Lernen durchzuspielen und plötzlich ging es trotz gleicher Einstllungen auf dem Clients und am Router nicht. Also doch nicht so einfach mal RAS/Routing aktivieren und alles geht.
Ich muß der Sache nochmal tiefer auf den Grund gehen.
Gruß Dimugi
Das NAT auf dem Server hatte übrigens den Sinn das ja mehrer Client's den Server als Router benutzen. Woher soll den der Server bei der Rückantwort noch den Adressierenden Rechner kennen? Geht das etwa auch ohne NAT?
Der Server hat an der zweiten NIC den Router zum Internet, vom Internetrouter wissen die Client's nichts.
Das Webbrowsen und pingen geht teilweise. Wenn es mal nicht geht, dann bringt das deaktivieren und anschließende aktivieren der NIC am Internetrouter die Verbindung wieder, das war voher nicht so.
Der gewünschten VPN durch den Draytek Router hat auch nichts gebracht, da es vielleicht doch ein Bug im Router ist.
Was ich hier am Forum so liebe, ist die öfter auftauchende Frage über den Sinn einer Sache als Antwort auf eine Frage. Die Nachfrage an sich geht ja in Ordnung, jedoch wäre eine Antwort auf die Ursprüngliche Frage auch ganz nett. Gut hier war zumindest ein andere Dokumentation als Antwort gegeben worden, in so fern war das noch recht freundlich im Gegensatz zu manchen anderen Anfragen hier im Forum.
Frage also: Würde das mit NAT auf dem Server auch gehen?
Clients (an NIC1 des Server)-> Server (Router 1)-> Internetrouter (hängt an NIC2 des Servers)-> Internet
Der Vigor 5500Pro enthält einen Virenscanner, eine UTM Firewall, Spamfilter u. mehr bereits im Router, daher möchte ich Ihn gerne vor dem Server haben.
Gruß
Dimugi
Der Server hat an der zweiten NIC den Router zum Internet, vom Internetrouter wissen die Client's nichts.
Das Webbrowsen und pingen geht teilweise. Wenn es mal nicht geht, dann bringt das deaktivieren und anschließende aktivieren der NIC am Internetrouter die Verbindung wieder, das war voher nicht so.
Der gewünschten VPN durch den Draytek Router hat auch nichts gebracht, da es vielleicht doch ein Bug im Router ist.
Was ich hier am Forum so liebe, ist die öfter auftauchende Frage über den Sinn einer Sache als Antwort auf eine Frage. Die Nachfrage an sich geht ja in Ordnung, jedoch wäre eine Antwort auf die Ursprüngliche Frage auch ganz nett. Gut hier war zumindest ein andere Dokumentation als Antwort gegeben worden, in so fern war das noch recht freundlich im Gegensatz zu manchen anderen Anfragen hier im Forum.
Frage also: Würde das mit NAT auf dem Server auch gehen?
Clients (an NIC1 des Server)-> Server (Router 1)-> Internetrouter (hängt an NIC2 des Servers)-> Internet
Der Vigor 5500Pro enthält einen Virenscanner, eine UTM Firewall, Spamfilter u. mehr bereits im Router, daher möchte ich Ihn gerne vor dem Server haben.
Gruß
Dimugi
Du hast definitiv einen fehler im Netzwerk oder im Internetrouter in der Konfig. Dieses Szeanrio ist ein Standardszenario was zigfach im Einsatz ist ! Das ist natürlich Unsinn das du deine NIC am Router aktivieren und deaktivieren musst. Erstens geht das bei DSL Routern gar nicht, da du dir ja dann den Konfig Ast absägen würdest auf dem du selber sitzt und zweitens kann das mit der Funktion rein gar nichts zu tun haben und schliesst eher auf einen HW Fehler im Router...das ist klar ! Diese Beschreibung ist also irgenwie verwirrend...
Aber beantworten wir mal deine Fragen der Reihe nach...
Da du ja scheinbar Schwierigkeiten hast das korrekte Packet Routing durch den Server und/oder den DSL Router zu verstehen hier für dich nochmal das kommentierte Packet Durchlaufprotokoll aus dem Tutorial für so einen Weg von einem Cleint Rechner ins Internet über beide Systeme:
Damit man einmal sieht wie das zusammenspielt ist hier eine kleine Geschichte über die Reise eines solchen Packetes am Beispiel eines Pings vom Client PC mit der 172.16.1.1 via Router mit der Adresse 192.168.1.1 zu www.administrator.de angefügt:
1.) Client ist auf dem Netz 172.16.1.0 mit der Hostadresse .1 und erhält vom Ping Programm den Auftrag ein ICMP echo request Packet an www.administrator.de zu schicken.
1a.) Oha, www.administrator.de verstehe ich gar nicht...Hilfe ich brauche eine IP Adresse also erstmal schnell den DNS Server gefragt und 82.149.225.22 zurückbekommen
2.) Nun merkt der Client das diese Zieladresse (82.149.225.22) nicht sein IP Segment ist (anderes Netz, denn seins ist ja 172.16.1.0) !), denn er kennt ja seine eigene IP Adresse und befragt den PC IP Stack also ob er ein Default Gateway Eintrag hat, wo er das Packet hinschicken kann, denn das Gateway wird schon wissen wie es weitergeht…
3.) Hurra, da hat er die 172.16.1.254 und das ist der Server, also ab mit dem Packet dahin...
4.) Der Server empfängt nun das Packet, sieht auf die Zieladresse 192.168.1.1 und sieht daraufhin in seiner Routing Tabelle nach.....
5.) Gut !, Das 192.168.1.0er Netz ist an mir direkt angeschlossen also raus damit auf der NIC1 an diesem Segment zum Router, denn der steht hier als Def. Gateway...
6.) Nun landet das Packet beim Router und der sieht das das Ziel 82.149.225.22 ist. Der sieht nach was er machen soll...OK Routing Tabelle nachgesehen default Gateway (Provider) gefunden ab damit dahin.
Halt...!! Voher muss ich noch NAT machen und die Absender IP 172.16.1.1 im Packet ersetzen mit meiner eigenen DSL Provider IP (nehmen wir mal die 212.1.1.1 als Beispiel)
Also, los gehts.. und so geht das Spielchen weiter bis zu www.administrator.de, 82.149.225.22 der nun das Packet empfängt und sieht aha ein ICMP echo request (Ping) auf das ich mit einem echo reply antworten muss. OK das Antwortpacket von www.administrator.de zurück an meinen Client hat nun als Absenderadresse die 82.149.225.22 und als Empfängeradresse die 212.1.1.1 und landet dann wieder an meinem Router !
7.) Der Router sieht dann nachdem das packet ihn erreicht hat in der NAT Sessiontabelle nach: Aha, da habe ich ja meinen Eintrag ! Das Adresspärchen 82.149.225.22/gehört zu meinem Client 172.16.1.1. Also schnell wieder die Empfängeradresse von 212.1.1.1 in 172.16.1.1 umgeschrieben im Packet und weiter gehts....
Router sieht nun in seiner Routing Tabelle nach....und nun die Gretchenfrage....
Du hast eine statische Route aufs 172.16.1.0er Netz drin => Weiter bei 9.)
Du hast keine statische Route aufs 172.16.1.0er Netz drin => Weiter bei 8.)
8.) OK, ich nehme die default Route ins Internet da ich 172.16.1.0 anderweitig nicht kenne und es an mir selber ja nicht dran ist...
Hier verliert sich nun die Spur vom Packet 192.168.1.1, da dies eine RFC 1918 IP Adresse ist die nicht geroutet wird im Internet und der Providerrouter das Packet kommentarlos brutal und unbarmherzig in den Datenmülleimer verfrachtet. Im Client erscheint ein "Keine Antwort von 192.168.1.1" und dimugi ist frustriert… (Ist ja so passiert da du die Route vergessen hast !!!)
9.) Aha, in der Routing Tabelle steht eine statische Route die mir sagt alles für 172.16.1.0 schicke bitte an die 192.168.1.254 meinen Server im Routersegment. Ok, und ab mit dem echo reply Packet an diese Adresse...
10.) Der Server empfängt nun das Packet sieht auf die Zieladresse 172.16.1.1 und sieht daraufhin wieder in seiner Routing Tabelle nach.....
11.) Klasse, das 172.16.1.0er Netz ist an mir direkt angeschlossen also raus damit auf der NIC2 an diesem Segment zum Client...
12.) Perfekt, das Packet mit der echo Antwort vom Router ist da und erzeugt ein freudestrahlendes "Antwort von 82.149.225.22 !!!" Dimugi ist happy und sagt bingo! es rennt....
Damit siehst du das es dem Client herzlich egal ist welche IP Adresse der Router hat...ihn interessiert immer nur sein Gateway wo er Packet mit für ihn unbekannten Adressen hinschicken kann und damit ist für ihn der Fall erledigt....
Zweitens kannst du sehen wie immens wichtig die statische Route im Router ist (natürlich nur bei einem sauber gerouteten Design ohne NAT am Server !), denn sonst würde das Packet den Weg vom NAT Router niemals zurück ins Client Segment finden !
In einem NAT Szeanrio schon am Server wie du es hast passiert dieser Schritt 6.) auch schon am Server. Alle Packete aus dem Client Segment tauchen dann hier schon mit der Server Adresse aus dem 192.168.1.0er Netz auf. Dadurch das der Router dann durch dieses NAT gar nicht mehr weiss das überhaupt ein Clientnetz existiert musst du gar nicht mehr statisch routen auf dem Router, denn der sieht ja durch das NATen am Server nur noch IP Packete aus dem 192.168.1.0er Netz. Diese Packete wiederum NATet er nun wiederum nochmal auf die öffentliche Provider IP.
Da kannst du nun schon sehen wie unsinnig diese 2malige NATen ist.
Ferner beantwortet es deine VPN Frage relativ klar:
a.) Willst du das VPN am Server terminieren musst du statisch mit 2 Port Forwarding Listen am Router UND auch am Server dies überwinden. Ein fast aussichtsloses Unterfangen kann aber mit viel Bastelei klappen wenn du Glück hast.
b.) Terminierst du das VPN am Router hast du immer noch den NAT Prozess am Server den du für jede Session auf einen Client PC überwinden musst. Wie du ja sicher selber weisst geht Port Forwarding pro TCP oder UDP Port nur genau ein Mal. Mehrere PCs im Client Segment damit zu erreichen ist also unmöglich. Das Problem hast du bei Variante a.) oben analog.
Fazit deine Frage: Ein transparenter VPN Zugang ins Client Segment ist nur sehr sehr bedingt möglich so mit 2 Mal NAT oder generell NAT am Server !
(P.S.: ICMP echo ist deaktiviert bei www.administrator.de ! Wunder dich also nicht wenn du das Beispiel von oben real ausprobierst das keine Antwort kommt ! Ersetz das Bsp. dann mit www.heise.de oder www.spiegel.de )
Aber beantworten wir mal deine Fragen der Reihe nach...
Da du ja scheinbar Schwierigkeiten hast das korrekte Packet Routing durch den Server und/oder den DSL Router zu verstehen hier für dich nochmal das kommentierte Packet Durchlaufprotokoll aus dem Tutorial für so einen Weg von einem Cleint Rechner ins Internet über beide Systeme:
Damit man einmal sieht wie das zusammenspielt ist hier eine kleine Geschichte über die Reise eines solchen Packetes am Beispiel eines Pings vom Client PC mit der 172.16.1.1 via Router mit der Adresse 192.168.1.1 zu www.administrator.de angefügt:
1.) Client ist auf dem Netz 172.16.1.0 mit der Hostadresse .1 und erhält vom Ping Programm den Auftrag ein ICMP echo request Packet an www.administrator.de zu schicken.
1a.) Oha, www.administrator.de verstehe ich gar nicht...Hilfe ich brauche eine IP Adresse also erstmal schnell den DNS Server gefragt und 82.149.225.22 zurückbekommen
2.) Nun merkt der Client das diese Zieladresse (82.149.225.22) nicht sein IP Segment ist (anderes Netz, denn seins ist ja 172.16.1.0) !), denn er kennt ja seine eigene IP Adresse und befragt den PC IP Stack also ob er ein Default Gateway Eintrag hat, wo er das Packet hinschicken kann, denn das Gateway wird schon wissen wie es weitergeht…
3.) Hurra, da hat er die 172.16.1.254 und das ist der Server, also ab mit dem Packet dahin...
4.) Der Server empfängt nun das Packet, sieht auf die Zieladresse 192.168.1.1 und sieht daraufhin in seiner Routing Tabelle nach.....
5.) Gut !, Das 192.168.1.0er Netz ist an mir direkt angeschlossen also raus damit auf der NIC1 an diesem Segment zum Router, denn der steht hier als Def. Gateway...
6.) Nun landet das Packet beim Router und der sieht das das Ziel 82.149.225.22 ist. Der sieht nach was er machen soll...OK Routing Tabelle nachgesehen default Gateway (Provider) gefunden ab damit dahin.
Halt...!! Voher muss ich noch NAT machen und die Absender IP 172.16.1.1 im Packet ersetzen mit meiner eigenen DSL Provider IP (nehmen wir mal die 212.1.1.1 als Beispiel)
Also, los gehts.. und so geht das Spielchen weiter bis zu www.administrator.de, 82.149.225.22 der nun das Packet empfängt und sieht aha ein ICMP echo request (Ping) auf das ich mit einem echo reply antworten muss. OK das Antwortpacket von www.administrator.de zurück an meinen Client hat nun als Absenderadresse die 82.149.225.22 und als Empfängeradresse die 212.1.1.1 und landet dann wieder an meinem Router !
7.) Der Router sieht dann nachdem das packet ihn erreicht hat in der NAT Sessiontabelle nach: Aha, da habe ich ja meinen Eintrag ! Das Adresspärchen 82.149.225.22/gehört zu meinem Client 172.16.1.1. Also schnell wieder die Empfängeradresse von 212.1.1.1 in 172.16.1.1 umgeschrieben im Packet und weiter gehts....
Router sieht nun in seiner Routing Tabelle nach....und nun die Gretchenfrage....
Du hast eine statische Route aufs 172.16.1.0er Netz drin => Weiter bei 9.)
Du hast keine statische Route aufs 172.16.1.0er Netz drin => Weiter bei 8.)
8.) OK, ich nehme die default Route ins Internet da ich 172.16.1.0 anderweitig nicht kenne und es an mir selber ja nicht dran ist...
Hier verliert sich nun die Spur vom Packet 192.168.1.1, da dies eine RFC 1918 IP Adresse ist die nicht geroutet wird im Internet und der Providerrouter das Packet kommentarlos brutal und unbarmherzig in den Datenmülleimer verfrachtet. Im Client erscheint ein "Keine Antwort von 192.168.1.1" und dimugi ist frustriert… (Ist ja so passiert da du die Route vergessen hast !!!)
9.) Aha, in der Routing Tabelle steht eine statische Route die mir sagt alles für 172.16.1.0 schicke bitte an die 192.168.1.254 meinen Server im Routersegment. Ok, und ab mit dem echo reply Packet an diese Adresse...
10.) Der Server empfängt nun das Packet sieht auf die Zieladresse 172.16.1.1 und sieht daraufhin wieder in seiner Routing Tabelle nach.....
11.) Klasse, das 172.16.1.0er Netz ist an mir direkt angeschlossen also raus damit auf der NIC2 an diesem Segment zum Client...
12.) Perfekt, das Packet mit der echo Antwort vom Router ist da und erzeugt ein freudestrahlendes "Antwort von 82.149.225.22 !!!" Dimugi ist happy und sagt bingo! es rennt....
Damit siehst du das es dem Client herzlich egal ist welche IP Adresse der Router hat...ihn interessiert immer nur sein Gateway wo er Packet mit für ihn unbekannten Adressen hinschicken kann und damit ist für ihn der Fall erledigt....
Zweitens kannst du sehen wie immens wichtig die statische Route im Router ist (natürlich nur bei einem sauber gerouteten Design ohne NAT am Server !), denn sonst würde das Packet den Weg vom NAT Router niemals zurück ins Client Segment finden !
In einem NAT Szeanrio schon am Server wie du es hast passiert dieser Schritt 6.) auch schon am Server. Alle Packete aus dem Client Segment tauchen dann hier schon mit der Server Adresse aus dem 192.168.1.0er Netz auf. Dadurch das der Router dann durch dieses NAT gar nicht mehr weiss das überhaupt ein Clientnetz existiert musst du gar nicht mehr statisch routen auf dem Router, denn der sieht ja durch das NATen am Server nur noch IP Packete aus dem 192.168.1.0er Netz. Diese Packete wiederum NATet er nun wiederum nochmal auf die öffentliche Provider IP.
Da kannst du nun schon sehen wie unsinnig diese 2malige NATen ist.
Ferner beantwortet es deine VPN Frage relativ klar:
a.) Willst du das VPN am Server terminieren musst du statisch mit 2 Port Forwarding Listen am Router UND auch am Server dies überwinden. Ein fast aussichtsloses Unterfangen kann aber mit viel Bastelei klappen wenn du Glück hast.
b.) Terminierst du das VPN am Router hast du immer noch den NAT Prozess am Server den du für jede Session auf einen Client PC überwinden musst. Wie du ja sicher selber weisst geht Port Forwarding pro TCP oder UDP Port nur genau ein Mal. Mehrere PCs im Client Segment damit zu erreichen ist also unmöglich. Das Problem hast du bei Variante a.) oben analog.
Fazit deine Frage: Ein transparenter VPN Zugang ins Client Segment ist nur sehr sehr bedingt möglich so mit 2 Mal NAT oder generell NAT am Server !
(P.S.: ICMP echo ist deaktiviert bei www.administrator.de ! Wunder dich also nicht wenn du das Beispiel von oben real ausprobierst das keine Antwort kommt ! Ersetz das Bsp. dann mit www.heise.de oder www.spiegel.de )
