VPN-Server hinter DrayTek Vigor 2910
Holger Diess
bisher war ein ISA-Server 2000 als Internet-Router, Firewall und VPN-Server
direkt am Internet angeschlossen. Nun soll eine vernünftige DMZ aufgebaut
werden indem ein Draytek Vigor 2910 direkt am Internet angeschlossen wird
und Router und Firewall spielt. Der ISA 2000 bleibt als interne Firewall und
VPN-Server für das LAN hinter dem Vigor erhalten. Dazu wurde ein neues
Subnetz für die DMZ eingerichtet wobei bisher nur die 10.34.0.1 für den
Vigor und die 10.34.0.9 für den ISA benutzt wird. Internetzugriff, e-Mail,
FTP, etc. funktionieren. Nur der VPN-Server auf dem ISA ist vom Internet
nicht mehr erreichbar.
Benutzt werden soll wie bisher PPTP. Auf dem Vigor habe ich den eigenen
VPN-Server ausgeschaltet. Laut Beschreibung wird dann automatisch das
GRE-Protokoll an das interne Netz also auch an den ISA weitergeleitet.
Zusätzlich habe ich auf dem Vigor ein Portforwarding von Port 1723 auf den
ISA eingerichtet. Der interne VPN-Server wird aber nicht erreicht. Nun habe
ich den ISA sogar als DMZ-Host freigegeben. Spätestens jetzt muß es doch
laufen, aber Fehlanzeige.
Was kann/muß ich noch machen?
Viele Grüße
Holger Diess
Burkhard Ott
> Was kann/mu ich noch machen?
>
Sniffer benutzen, schau mal ob überhaupt an Deinem Port was ankommt.
Rainer Sokoll
> Benutzt werden soll wie bisher PPTP. Auf dem Vigor habe ich den eigenen
> VPN-Server ausgeschaltet. Laut Beschreibung wird dann automatisch das
> GRE-Protokoll an das interne Netz also auch an den ISA weitergeleitet.
D.h., der Vigor broadcastet GRE einfach ins interne Netz?
Das ist ja meschugge.
Rainer
Holger Diess
Wie das intern im Vigor funktioniert weiß ich leider nicht. Wenn der Vigor
intelligent ist, dann könnte er die interne Zieladresse dem Portforwarding
oder dem DMZ-Host-Eintrag entnehmen. Ansonsten muß er broadcasten. In der
Bedienungsanleitung steht leider nur: "Falls in dem LAN des Vigor ein VPN
Server aktiv ist, so muß der entsprechende Dienst im Vigor deaktiviert
werden, da ansonsten der Vigor den Einwahlversuch bedient. Hierdurch wird
ein Pass Through, also eine Weiterleitung in das LAN, des entsprechenden
Dienstes ermöglicht. Außerdem sollten die relevanten NAT Einstellungen (u.a.
DMZ, Offene Ports) überprüft werden."
Den broadcast würde ich vorübergehend akzeptieren, da wir kommendes Jahr
irgendwann auf L2TP umsteigen werden. Außerdem ist der broadcast immer noch
besser als die alte Konstruktion.
Hast Du eine Idee warum aber der VPN-Server trotz DMZ-Host-Eintrag nicht
gefunden wird?
Viele Grüße
Holger Diess
Holger Diess
> Sniffer benutzen, schau mal ob überhaupt an Deinem Port was ankommt.
Einen richtigen Sniffer haben wir leider nicht. Und wenn ich auf dem ISA ein
Ethereal oder ähnliches installiere, bekomme ich nicht nur mit meinem
Gewissen Konflikte. Der 100%ige ISA-Profi bin ich leider auch nicht. Wenn
ich die Regeln des alten ISA2000 so hinbekomme das alles funktioniert ohne
Sicherheitslöcher zu reissen, dann bin ich schon froh. Kennst Du vielleicht
im ISA noch eine Stelle wo man da nachschauen kann?
Viele Grüße
Holger Diess
Rainer Sokoll
> > Sniffer benutzen, schau mal ob überhaupt an Deinem Port was ankommt.
>
> Einen richtigen Sniffer haben wir leider nicht. Und wenn ich auf dem ISA ein
> Ethereal oder ähnliches installiere,
Wireshark (Ex-Ethereal) ist ein "richtiger" Sniffer.
> bekomme ich nicht nur mit meinem
> Gewissen Konflikte.
D.h., Dein Chef hat Bauchschmerzen? Du mußt ja nicht den Payload der
Pakete mitschneiden. Außerdem: Selbst wenn Du den Payload hättest - es
soll ja eine VPN-Verbindung sein, da kannst Du (hoffentlich) ohnehin
nichts Verwertbares lesen.
Rainer
Holger Diess
entschuldige bitte die späte Reaktion, aber es war viel zu tun.
> Viele billige Router erwaehnen nicht explizit, dass sie GRE
> weiterleiten, oft hilft es allerdings 1723/tcp auf den richtigen Server
> im Lan weiterzuleiten, dann wird oft automatisch auch GRE an diesen
> Server weitergeleitet. Einfach mal ausprobieren.
Im ersten Test hatte ich 1723/tcp, 1701/udp und 500/udp auf den internen
VPN Server weitergeleitet.Weil dies keinen Erfolg brachte hatte ich im
2. Test den DMZ-Host auf den Server eingestellt, leider auch ohne Erfolg.
Laut Bedienungsanleitung wird GRE nach intern weitergeleitet, wenn der
VPN-Server auf dem Vigor ausgeschaltet wird. Dies habe ich
selbstverständlich getan. Siehe auch meine Antwort an Rainer mit den
Zitaten aus dem Handbuch.
> Ein DMZ-Host-Eintrag sollte dafuer nie notwendig sein, aus
> Sichheitsgruenden explizit deaktivieren. Das muss auch ohne
> funktionieren. Da koennte man sich den externen Router ja gleich ganz
> schenken.
Sehe ich auch so, war halt nur so ein Test der leider keinen Erfolg brachte.
> Openvpn koennte auch fuer einen Tunnel genommen werden, als Service
> installiert wuerde das auch automatisch fuer normale user
> funktionieren. Laesst sich auch einfacher weiterleiten.
Von OpenVPN hab ich gehört, aber ich kenn es nicht. Wenn ich die
Wikipedia-Beschreibung richtig verstanden habe, muß dies auf jedem
VPN-Client der ins Netz will erst installiert werden? Dann würden
wir es nicht einsetzen.
Viele Grüße
Holger
Holger Diess
entschuldige bitte die späte Reaktion, aber es war viel zu tun.
Wenn man von außen (WAN) über den Vigor einen Test startet, dann kommt auf
dem ISA-Server keine Kommunikation an, welche auf den Port 1723/tcp,
1701/udp oder 500/udp geht. Wenn man vom LAN (also nicht über den Vigor)
einen Test startet, dann kommt 1723/tcp an. Zumindest das letztere war zu
erwarten, da das VPN vom LAN ja funktioniert. Den Fehlerfall interpretiere
ich so, daß der Vigor nicht vernünftig nach drinnen weiterleitet. Aber
warum? Sowohl Portweiterleitung als auch DMZ-Host hatte ich ausprobiert.
Viele Grüße
Holger
Andreas Beck
> Im ersten Test hatte ich 1723/tcp, 1701/udp und 500/udp auf den internen
> VPN Server weitergeleitet.Weil dies keinen Erfolg brachte hatte ich im
> 2. Test den DMZ-Host auf den Server eingestellt, leider auch ohne Erfolg.
> Laut Bedienungsanleitung wird GRE nach intern weitergeleitet, wenn der
> VPN-Server auf dem Vigor ausgeschaltet wird. Dies habe ich
> selbstverständlich getan. Siehe auch meine Antwort an Rainer mit den
> Zitaten aus dem Handbuch.
Ömm - das ist doch ein NAT-Szenario? Wohin leitet er da GRE?
Und was ist das Szenario überhaupt? Ipsec-l2tp-M$-Mischmasch? Irgendwie
irritiert mich, gleichzeitig von 1723/GRE und 500/udp zu lesen.
>> Openvpn koennte auch fuer einen Tunnel genommen werden, als Service
>> installiert wuerde das auch automatisch fuer normale user
>> funktionieren. Laesst sich auch einfacher weiterleiten.
> Von OpenVPN hab ich gehört, aber ich kenn es nicht. Wenn ich die
> Wikipedia-Beschreibung richtig verstanden habe, muß dies auf jedem
> VPN-Client der ins Netz will erst installiert werden? Dann würden
> wir es nicht einsetzen.
Äh? Das ist eine strategische Entscheidung², oder?
Und hat bestimmt was mit Industriestandard zu tun
und mit "ich habe im Managermagazin gelesen", oder?
Mein Beileid,
Andy
² Ich bin immer wieder erstaunt, welche Mittel manche Kunden gewillt
sind, in das Debugging eines bizarren "Industriestandard-Setups" zu
stecken, dessen Ziel man mit "nonstandard-Mitteln" in wenigen Minuten
erreichen könnte.
Juergen Ilse
Andreas Beck <becka-news-n...@acs.uni-duesseldorf.de> wrote:
> Holger Diess wrote:
>> Im ersten Test hatte ich 1723/tcp, 1701/udp und 500/udp auf den internen
>> VPN Server weitergeleitet.Weil dies keinen Erfolg brachte hatte ich im
>> 2. Test den DMZ-Host auf den Server eingestellt, leider auch ohne Erfolg.
>> Laut Bedienungsanleitung wird GRE nach intern weitergeleitet, wenn der
>> VPN-Server auf dem Vigor ausgeschaltet wird. Dies habe ich
>> selbstverständlich getan. Siehe auch meine Antwort an Rainer mit den
>> Zitaten aus dem Handbuch.
> Ömm - das ist doch ein NAT-Szenario? Wohin leitet er da GRE?
Oftmals zu dem Rechner, der zuletzt selbst GRE gequasselt hat ...
Ob das beim Vigor genauso ist, weiss ich natuerlich nicht, aber AFAIK
ist das eine "uebliche Heuristik" um diese Frage zu "gewaeltigen" ...
> Und was ist das Szenario überhaupt? Ipsec-l2tp-M$-Mischmasch? Irgendwie
> irritiert mich, gleichzeitig von 1723/GRE und 500/udp zu lesen.
Zusammenpassen tut das zwar nicht, aber das muss ja nicht heissen,
dass es im "Handbuch" eines Routers nicht munter unter einem Buzzword
wie "VPN-Passthrough" zusammengewuerfelt praesentiert wird ...
>>> Openvpn koennte auch fuer einen Tunnel genommen werden, als Service
>>> installiert wuerde das auch automatisch fuer normale user
>>> funktionieren. Laesst sich auch einfacher weiterleiten.
>> Von OpenVPN hab ich gehört, aber ich kenn es nicht. Wenn ich die
>> Wikipedia-Beschreibung richtig verstanden habe, muß dies auf jedem
>> VPN-Client der ins Netz will erst installiert werden? Dann würden
>> wir es nicht einsetzen.
> Äh? Das ist eine strategische Entscheidung², oder?
> Und hat bestimmt was mit Industriestandard zu tun
> und mit "ich habe im Managermagazin gelesen", oder?
Vermutlich. Evt. auch mit "wenn es nichts kostet, kann es nichts taugen".
> Mein Beileid,
Dto.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Holger Diess
> >> Im ersten Test hatte ich 1723/tcp, 1701/udp und 500/udp auf den
internen
> >> VPN Server weitergeleitet.Weil dies keinen Erfolg brachte hatte ich im
> >> 2. Test den DMZ-Host auf den Server eingestellt, leider auch ohne
Erfolg.
> >> Laut Bedienungsanleitung wird GRE nach intern weitergeleitet, wenn der
> >> VPN-Server auf dem Vigor ausgeschaltet wird. Dies habe ich
> >> selbstverständlich getan. Siehe auch meine Antwort an Rainer mit den
> >> Zitaten aus dem Handbuch.
> > Ömm - das ist doch ein NAT-Szenario? Wohin leitet er da GRE?
>
> Oftmals zu dem Rechner, der zuletzt selbst GRE gequasselt hat ...
> Ob das beim Vigor genauso ist, weiss ich natuerlich nicht, aber AFAIK
> ist das eine "uebliche Heuristik" um diese Frage zu "gewaeltigen" ...
Das weiß ich auch nicht wo er es hinleitet. Das Ziel muß aber im internen
Netz liegen
sonst macht es keinen Sinn.
> > Und was ist das Szenario überhaupt? Ipsec-l2tp-M$-Mischmasch? Irgendwie
> > irritiert mich, gleichzeitig von 1723/GRE und 500/udp zu lesen.
>
> Zusammenpassen tut das zwar nicht, aber das muss ja nicht heissen,
> dass es im "Handbuch" eines Routers nicht munter unter einem Buzzword
> wie "VPN-Passthrough" zusammengewuerfelt praesentiert wird ...
500/udp hat was mit IKE zu tun und wird bei L2TP benutzt. Was der Router
auch
kann. Mit der Fehlersuche im PPTP-Bereich hat das nichts zu tun. Ich hatte
es der
Vollständigkeit halber mit erwähnt.
Viele Grüße
Holger Diess
Holger Diess
vielen Dank für die vielen Tips. Dadurch konnte ich den Fehler weiter
einkreisen. Im Gegensatz zu meinen ersten Vermutungen liegt es nicht am
Portforwarding sondern an der Firewall. Standardmäßig ist diese beim Vigor
so eingestellt, daß ein paar Kleinigkeiten verboten sind und alles Weitere
durchgelassen wird. In dieser Einstellung würde es selbstverständlich
funktionieren. Natürlich haben wir bei uns umgestellt auf "Alles verboten"
außer die Dienste welche wirklich benutzt werden (HTML, e-Mail, NNTP, VPN,
etc.). Bei der VPN-Regel steckt nun offensichtlich ein Fehler drin, den ich
einfach nicht finden kann. Aufstellen mußte ich 2 VPN-Regeln: Die eine vom
WAN zum ISA-Server die andere umgekehrt vom ISA ins WAN. Beide leiten die
selbst erstellte Dienstgruppe "VPN" weiter, welche folgende Protokolle
enthält:
"GRE": Protokoll 47
"PPTP": TCP; Source: 1-65535, Destination: 1723
"L2TP": UDP; Source: 1-65535, Destination: 1701
"IKE": UDP; Source: 1-65535, Destination: 500
Für das vorliegende Scenario sollten eigentlich die ersten beiden Einträge
ausreichen, die beiden anderen sind der Vollständigkeit halber mit
angegeben. Leider funktioniert es nicht mit diesen Einstellungen. Wenn ich
das PPTP-Protokoll wie folgt ändere:
"PPTP": TCP; Source: 1-65535, Destination: 1-65535
dann funktioniert es. Ich bin nicht der Firewall-Guru aber ich glaub schon,
daß ich die Firewall damit vollständig geöffnet habe.
Könnt Ihr mir bitte erklären wie es richtig gemacht wird oder wo mein
Denkfehler liegt!?
Viele Grüße
Holger Diess
Wolfgang Kueter
> Hallo *,
> vielen Dank für die vielen Tips. Dadurch konnte ich den Fehler weiter
> einkreisen. Im Gegensatz zu meinen ersten Vermutungen liegt es nicht am
> Portforwarding sondern an der Firewall. [...]
> Könnt Ihr mir bitte erklären wie es richtig gemacht wird oder wo mein
> Denkfehler liegt!?
Du willst kein NAT des Vigor sondern Routing, also eine oeffentliche
IP-Adresse auf dem externen Interface Deiner ISA Kiste als VPN Endpunkt.
Besorge Dir von Deinem ISP bitte oeffentlichen Adressraum, mindestens /30.
Wolfgang
Holger Diess
> > vielen Dank fr die vielen Tips. Dadurch konnte ich den Fehler weiter
> > einkreisen. Im Gegensatz zu meinen ersten Vermutungen liegt es nicht am
> > Portforwarding sondern an der Firewall. [...]
> > K nnt Ihr mir bitte erklren wie es richtig gemacht wird oder wo mein
> > Denkfehler liegt!?
>
> Du willst kein NAT des Vigor sondern Routing, also eine oeffentliche
> IP-Adresse auf dem externen Interface Deiner ISA Kiste als VPN Endpunkt.
>
> Besorge Dir von Deinem ISP bitte oeffentlichen Adressraum, mindestens /30.
Nein, es soll ein Portforwarding sein. Also, direkt am Internet ist ein
Router DrayTek Vigor 2910 mit integrierter Firewall. Dahinter befindet sich
nicht das LAN, sondern erst einmal nur die DMZ. Dort werden später
Webserver, etc. aufgebaut. Weiterhin befindet sich in der DMZ der externe
Anschluß der zweiten (internen) Firewall. Diese läuft zur Zeit auf einem
ISA-Server 2000. Der ISA-Server ist gleichzeitig VPN-Server, damit Clients
aus dem Internet eine VPN-Verbindung zum internen LAN aufbauen können. Die
externe Firewall (Vigor 2910) muß dazu ein Pass-Through zum ISA-Server
ausführen, was auch ohne öffentliche IP-Adresse am ISA funktioniert. Nicht
alle Router beherrschen ein VPN-Pass-Through aber der Vigor 2910 kann es wie
ein erfolgreicher Test zeigt. Mich stört nur, daß ich bei dem Test die
Firewall des Vigor praktisch vollständig ausschalten mußte. Meine Frage ist
also, wie kann ich die Firewall vernünftig einstellen damit VPN trotzdem
funktioniert.
Viele Grüße
Holger Diess
Wolfgang Kueter
>> Besorge Dir von Deinem ISP bitte oeffentlichen Adressraum, mindestens
>> /30.
>
> Nein, es soll ein Portforwarding sein. Also, direkt am Internet ist ein
> Router DrayTek Vigor 2910 mit integrierter Firewall. Dahinter befindet
> sich nicht das LAN, sondern erst einmal nur die DMZ. Dort werden später
> Webserver, etc. aufgebaut. Weiterhin befindet sich in der DMZ der externe
> Anschluß der zweiten (internen) Firewall. Diese läuft zur Zeit auf einem
> ISA-Server 2000. Der ISA-Server ist gleichzeitig VPN-Server, damit Clients
> aus dem Internet eine VPN-Verbindung zum internen LAN aufbauen können.
Du willst definitiv *keine* private IP auf dem externen Interface des ISA
Servers, wenn dieser als VPN Endpunkt dienen soll, nimm das bitte einfach
mal so hin. Mit einer Privaten IP und NAT/Portweiterleitungen wird IPSec
niemals vernünftig funktionieren. Glaube mir das einfach so, oder lies die
IPSec Spezifikationen nach, damit Du versteht, warum es so ist.
Es mag sein, daß das mit der Architektur, so wie Du sie geplant hast,
kollidiert, bitte ändere Deine Planung.
Wolfgang
Gerald Vogt
> "L2TP": UDP; Source: 1-65535, Destination: 1701
Never ever. Man sollte niemals L2TP weiterleiten oder einen offenen
Port haben. L2TP wird über IPSec geschützt. Wenn Du eine IPSec
Verbindung aufbauen kannst, dann wird über diese die Verbindung zum
L2TP Server aufgebaut. Der Server kann lokal sein.
Gerald
Gerald Vogt
> das PPTP-Protokoll wie folgt ändere:
> "PPTP": TCP; Source: 1-65535, Destination: 1-65535
> dann funktioniert es. Ich bin nicht der Firewall-Guru aber ich glaub schon,
> daß ich die Firewall damit vollständig geöffnet habe.
Kann die Firewall kein Log erstellen? Wenn ich an der Firewall
Änderungen mache, dann lasse ich alles protokollieren, was gedroppt
wird. Da sieht man dann, ob man was vergessen hat oder falsch gemacht
hat.
Andere Alternative wäre, mit der obiger Regel aktiv mit einem
Netzwerksniffer zu schauen, welche Pakete ausgetauscht werden.
Vielleicht erkennst Du dann, was noch fehlt.
Gerald
P.S.: Der letzte Post ging zu früh raus. Ein L2TP Server sollte nie
einen öffentlich zugreifbaren Port haben. Er sollte nur Pakete aus dem
IPSec Tunnel akzeptieren. Das war, was ich meinte... ;-)
Holger Diess
> > Nein, es soll ein Portforwarding sein. Also, direkt am Internet ist ein
> > Router DrayTek Vigor 2910 mit integrierter Firewall. Dahinter befindet
> > sich nicht das LAN, sondern erst einmal nur die DMZ. Dort werden spter
> > Webserver, etc. aufgebaut. Weiterhin befindet sich in der DMZ der
externe
> > Anschlu der zweiten (internen) Firewall. Diese luft zur Zeit auf einem
> > ISA-Server 2000. Der ISA-Server ist gleichzeitig VPN-Server, damit
Clients
> > aus dem Internet eine VPN-Verbindung zum internen LAN aufbauen k nnen.
>
> Du willst definitiv *keine* private IP auf dem externen Interface des ISA
> Servers, wenn dieser als VPN Endpunkt dienen soll, nimm das bitte einfach
> mal so hin. Mit einer Privaten IP und NAT/Portweiterleitungen wird IPSec
> niemals vernünftig funktionieren. Glaube mir das einfach so, oder lies die
> IPSec Spezifikationen nach, damit Du versteht, warum es so ist.
>
> Es mag sein, daß das mit der Architektur, so wie Du sie geplant hast,
> kollidiert, bitte ändere Deine Planung.
Stimmt, nach der ursprünglichen IPSec-Spezifikation funktioniert es nicht.
Allerdings wurde diese mit dem sogenannten NAT-Traversal ergänzt. Damit soll
genau das Problem gelöst werden, eine IPSec Verbindung durch einen
NAT-Router zu realisieren. Einige Details dazu kannst Du in folgenden Links
finden:
http://prolinux.de/berichte/lt2003/nat-traversal.html
http://onair.funkwerk-ec.com/brueckenschlag_zwischen_nat_und_ipsec.html
http://www.nattraversal.com/
Natürlich kommen nicht alle Router mit dieser Technik klar, aber wir haben
extra den Vigor 2910 genommen, weil dieser laut Hersteller NAT-Traversal
kann. Wir werden einfach mal ausprobieren ob es klappt und wenn nicht können
wir das Konzept immer noch ändern.
Viele Grüße
Holger Diess
Wolfgang Kueter
> [NAT-Traversal]
NAT Traversal ist eine häßliche Krücke, die IPSec unsicher(er) macht aber
für mobile Clients (oft Notebooks), die einen Tunnel ins Firmennetz
aufbauen sollen, leider heutzutage oft unvermeidlich ist, weil diese
mobilen Clients eben oft hinter Gateways betrieben werden, die NAT machen.
Du kannst mir aber stumpf glauben, daß Du ein *VPN* *Gateway* nicht mit
einer privaten IP hinter einem Router betreiben willst, der NAT macht. Ich
glaube, ich habe genug VPNs eingerichtet, um das beurteilen zu können.
> Natürlich kommen nicht alle Router mit dieser Technik klar, aber wir
> haben extra den Vigor 2910 genommen, weil dieser laut Hersteller
> NAT-Traversal kann. Wir werden einfach mal ausprobieren ob es klappt und
> wenn nicht kö�nnen wir das Konzept immer noch ändern.
Eine private IP und NAT für ein VPN Gateway/Firewall ist ein krankes
Konzept. ISA wird als Firewall verkauft. Ein Gerät, das unter dieser
Bezeichnung verkauft wird, sollte ohne Probleme mit mndestens einem
Interface an einem feindlichen Netz betrieben werden können. Wenn es das
nicht abkann, sondern vorgeschalteten Schutz benötigt, darf es sich nicht
Firewall nennen.
Wolfgang
Holger Diess
> Du kannst mir aber stumpf glauben, daß Du ein *VPN* *Gateway* nicht mit
> einer privaten IP hinter einem Router betreiben willst, der NAT macht. Ich
> glaube, ich habe genug VPNs eingerichtet, um das beurteilen zu können.
Meinst Du Probleme mit der Sicherheit (Hacking) oder Probleme mit der
Zuverlässigkeit (Ausfälle), oder zu kompliziert, oder anderes?
> > Natürlich kommen nicht alle Router mit dieser Technik klar, aber wir
> > haben extra den Vigor 2910 genommen, weil dieser laut Hersteller
> > NAT-Traversal kann. Wir werden einfach mal ausprobieren ob es klappt und
> > wenn nicht kö?nnen wir das Konzept immer noch ändern.
>
> Eine private IP und NAT für ein VPN Gateway/Firewall ist ein krankes
> Konzept.
Leider fehlt mir hier die Kennung. Dann werde ich mich wohl doch noch mit
den technischen Details von IPSec und NAT-Traversal beschäftigen müssen.
Zuerst muß ich aber erst mal das PPTP sauber zum laufen bringen.
> ISA wird als Firewall verkauft. Ein Gerät, das unter dieser
> Bezeichnung verkauft wird, sollte ohne Probleme mit mndestens einem
> Interface an einem feindlichen Netz betrieben werden können. Wenn es das
> nicht abkann, sondern vorgeschalteten Schutz benötigt, darf es sich nicht
> Firewall nennen.
Mit unserem ISA-2000 bin ich höchst unzufrieden und hoffe bald auf ISA-2006
umsteigen zu können. Was die externe IP-Adresse für den ISA betrifft,
scheitert es eher am Provider und den dazu gehörigen laufenden Kosten. So
groß ist unsere Firma halt nicht.
Viele Grüße
Holger Diess
Andreas Beck
>> Du kannst mir aber stumpf glauben, daß Du ein *VPN* *Gateway* nicht mit
>> einer privaten IP hinter einem Router betreiben willst, der NAT macht. Ich
>> glaube, ich habe genug VPNs eingerichtet, um das beurteilen zu können.
> Meinst Du Probleme mit der Sicherheit (Hacking) oder Probleme mit der
> Zuverlässigkeit (Ausfälle), oder zu kompliziert, oder anderes?
Primärgrund ist vermutlich "zu kompliziert" und damit auch "Ausfälle".
Hint: Das Originalposting ist irgendwo von Anfang Dezember und das ganze
scheint immer noch nicht zu laufen.
> Mit unserem ISA-2000 bin ich höchst unzufrieden und hoffe bald auf ISA-2006
> umsteigen zu können.
Umm. Ich neige dazu, Systeme mit denen ich höchst unzufrieden bin, nicht
gerade durch deren Nachfolger zu ersetzen. Das habe ich einige male
probiert und war mit dem Ergebnis höchst unzufrieden.
> Was die externe IP-Adresse für den ISA betrifft, scheitert es eher am
> Provider und den dazu gehörigen laufenden Kosten.
Wenn ihr es Euch leisten könnt, über 1 Monat an einer nicht laufenden
VPN-Verbindung rumzufrickeln, sollte das ja nun kein Problem sein. Echt.
Ansonsten siehe meine erste Reaktion ...
CU, Andy
Wolfgang Kueter
> Meinst Du Probleme mit der Sicherheit (Hacking) oder Probleme mit der
> Zuverlässigkeit (Ausfälle), oder zu kompliziert, oder anderes?
Von allem etwas, man macht es nicht, fertig, aus die Maus. Und es wäre nett,
wenn Du mal dafür sorgen würdest, daß Dein Newsreader entweder seine
Umlaute korrekt deklariert oder Du auf Umlaute verzichten würdest.
>> Eine private IP und NAT für ein VPN Gateway/Firewall ist ein krankes
>> Konzept.
>
> Leider fehlt mir hier die Kennung. Dann werde ich mich wohl doch noch mit
> den technischen Details von IPSec und NAT-Traversal beschäftigen müssen.
Es ist lobenswert, dass Du verstehen willst, warum es Schraddel ist. Die
Laborzeit, die Du dazu brauchen wirst, gewähre ich Dir - großzügig wie ich
bin - selbstverständlich.
Ob aber Dein Chef sie Dir auch gewährt, ist eine andere Frage, der mag ja -
wie Du weiter unten schreibst - kein Geld ausgeben.
> Mit unserem ISA-2000 bin ich höchst unzufrieden und hoffe bald auf
> ISA-2006 umsteigen zu können. Was die externe IP-Adresse für den ISA
> betrifft, scheitert es eher am Provider und den dazu gehörigen laufenden
> Kosten. So groß ist unsere Firma halt nicht.
Die Zeit, die Du für Deine IPSec NAT-T Experimente, brauchst, ist teurer,
als eine ordentliche Anbindung.
Wolfgang
Juergen Ilse
Holger Diess <Holger...@gmx.de> wrote:
>> Du willst definitiv *keine* private IP auf dem externen Interface des ISA
>> Servers, wenn dieser als VPN Endpunkt dienen soll, nimm das bitte einfach
>> mal so hin. Mit einer Privaten IP und NAT/Portweiterleitungen wird IPSec
>> niemals vernünftig funktionieren. Glaube mir das einfach so, oder lies die
>> IPSec Spezifikationen nach, damit Du versteht, warum es so ist.
>> Es mag sein, daß das mit der Architektur, so wie Du sie geplant hast,
>> kollidiert, bitte ändere Deine Planung.
Wenn das NAT-Device "gut genug raet" und ESP stets an den Host im internen
Netz weiter leiten wuerde, das zuletzt ESP gequatscht hat, dann wuerde es
funktionieren, sofern man wirklich fuer IPSEC ESP verwendet und von AH die
Finger von laesst ("gut genug raet" aus dem Grund, dass ESP an sich nicht
mangels Ports nicht fuer "Port-Adress-Translation" geeignet ist).
> Stimmt, nach der ursprünglichen IPSec-Spezifikation funktioniert es nicht.
> Allerdings wurde diese mit dem sogenannten NAT-Traversal ergänzt. Damit soll
> genau das Problem gelöst werden, eine IPSec Verbindung durch einen
> NAT-Router zu realisieren. Einige Details dazu kannst Du in folgenden Links
> finden:
> http://prolinux.de/berichte/lt2003/nat-traversal.html
> http://onair.funkwerk-ec.com/brueckenschlag_zwischen_nat_und_ipsec.html
> http://www.nattraversal.com/
Ja, das ist aber noch perverser (obwohl es im Gegensatz zu dem "guten
raten des Empfaengers fuer ESP" wie ich es oben erwaehnt habe auch mehrere
IPSEC-Connection durch das selbe NAT/PAT-Device ermoeglicht. Der Router
braucht dafuer noch nicht einmal "VPN-Passthrough" oder dergleichen zu
unterstuetzen, da der IPSEC-Datenstrom dabei in einen UDP-Datenstrom
mit Zielport 4500 eingepackt wird (geeignetes Portforwarding muesste man
dann ggfs. extra konfigurieren). Auch hierbei gilt AFAIK "mit AH keine
Chance, daher ESP verwenden" (wobei ich mir in diesem Punkt nicht 100%ig
sicher bin).
Holger Diess
>Kann die Firewall kein Log erstellen? Wenn ich an der Firewall
>Änderungen mache, dann lasse ich alles protokollieren, was gedroppt
>wird. Da sieht man dann, ob man was vergessen hat oder falsch gemacht
>hat.
Asche auf mein Haupt. Die Regel für den ausgehenden PPTP-Verkehr war
fehlerhaft, jetzt läuft es.
Vielen, vielen Dank an Alle die mir geholfen haben.
Holger Diess
Holger Diess
> > Leider fehlt mir hier die Kennung. Dann werde ich mich wohl doch noch
mit
> > den technischen Details von IPSec und NAT-Traversal beschäftigen müssen.
>
> Es ist lobenswert, dass Du verstehen willst, warum es Schraddel ist. Die
> Laborzeit, die Du dazu brauchen wirst, gewähre ich Dir - großzügig wie ich
> bin - selbstverständlich.
>
> Ob aber Dein Chef sie Dir auch gewährt, ist eine andere Frage, der mag
ja -
> wie Du weiter unten schreibst - kein Geld ausgeben.
Tja, da wird dann wohl wieder der eine oder andere Feierabend
draufgehen:-( Technisches Grundwissen interessiert mich auch persoenlich.
> > Mit unserem ISA-2000 bin ich höchst unzufrieden und hoffe bald auf
> > ISA-2006 umsteigen zu können. Was die externe IP-Adresse für den ISA
> > betrifft, scheitert es eher am Provider und den dazu gehörigen laufenden
> > Kosten. So groß ist unsere Firma halt nicht.
>
> Die Zeit, die Du für Deine IPSec NAT-T Experimente, brauchst, ist teurer,
> als eine ordentliche Anbindung.
Vielen Dank für den hartnaeckigen Tip. Da werden wir unsere Konstruktion
wohl doch noch einmal durchsprechen muessen. Mir soll es Recht sein.
Viele Gruesse
Holger Diess
Holger Diess
> Hint: Das Originalposting ist irgendwo von Anfang Dezember und das ganze
> scheint immer noch nicht zu laufen.
Doch jetzt geht es. Die Firewallregel für ausgehenden PPTP-Verkehr war
Schuld.
> > Mit unserem ISA-2000 bin ich höchst unzufrieden und hoffe bald auf
ISA-2006
> > umsteigen zu können.
>
> Umm. Ich neige dazu, Systeme mit denen ich höchst unzufrieden bin, nicht
> gerade durch deren Nachfolger zu ersetzen. Das habe ich einige male
> probiert und war mit dem Ergebnis höchst unzufrieden.
Der ISA-Server soll ab Version 2004 deutlich besser sein. Da geb ich
Microsoft noch mal 'ne Chance.
> Wenn ihr es Euch leisten könnt, über 1 Monat an einer nicht laufenden
> VPN-Verbindung rumzufrickeln, sollte das ja nun kein Problem sein. Echt.
Da muß man leider noch 3-4 Wochen abziehen, wo ich andere Sachen dazwischen
schieben mußte, und 1 Woche Weihnachtsurlaub war auch noch dabei. 8 Stunden
am Tag nur an diesem einen Problem knobeln, ist auch nicht möglich. Also ist
der Arbeitszeitaufwand nicht ganz so schlimm. Die Gesamtdauer war natürlich
nicht schön aber zu verschmerzen (sonst hätten die Prioritäten anders
gelegen). Dazugelernt habe ich auch eine Menge.
Viele Grüße
Holger Diess
Wolfgang Kueter
> Vielen Dank für den hartnaeckigen Tip. Da werden wir unsere Konstruktion
> wohl doch noch einmal durchsprechen muessen.
Du hättest ja auch vorhger jemanden fragen können, der sich mit sowas
auskennt. VPN fliegt doch oft innerhalb von 1-2 Stunden, wenn man weiß, was
man tut und die Geräte, mit denen man zu tun hat, eingermaßen kennt.
Wolfgang
Wolfgang Ewert
...
> NAT Traversal ist eine häßliche Krücke, die IPSec unsicher(er) macht aber
> für mobile Clients (oft Notebooks), die einen Tunnel ins Firmennetz
> aufbauen sollen, leider heutzutage oft unvermeidlich ist, weil diese
> mobilen Clients eben oft hinter Gateways betrieben werden, die NAT machen.
Vodaphone UMTS zBleistift.
Hmm, ich schätze daher OpenVPN sehr.
</werbung>
Wolfgang
Wolfgang Kueter
> Hallo Wolfgang Kueter, Du teiltest mit:
>
> ...
>> NAT Traversal ist eine häßliche Krücke, die IPSec unsicher(er) macht aber
>> für mobile Clients (oft Notebooks), die einen Tunnel ins Firmennetz
>> aufbauen sollen, leider heutzutage oft unvermeidlich ist, weil diese
>> mobilen Clients eben oft hinter Gateways betrieben werden, die NAT
>> machen.
>
> Vodaphone UMTS zBleistift.
Bei denen gibt es mWn inzwischen sogar (manchmal) oeffentliche IP-Adressen.
T-online UMTS verwendet allerdings mindestens 172.16.0.0/16, möglicherweise
auch 172.16.0.0/12 für ihr UMTS Netz.
Außerdem klemmen jede Menge Leute ihren Firmen-Laptop zu Hause gerne hinter
irgendwelche Router, die am häuslichen DSL-Anschluss hängen.
> Hmm, ich schätze daher OpenVPN sehr.
Firmenpolicies fordern aber nun mal oft IPSec, der VPN-Client ist auch oft
vorgegeben und vorkonfiguriert, die Konfig des Clients sollte vom
Mitarbeiter auch gar nicht geändert werden können. Der Mitarbeiter will
einfach nur, dass sein Laptop zu Hause hinter seinem DSL Router
funktioniert und der macht natürlich NAT.
Wolfgang
Wolfgang Ewert
> > Vodaphone UMTS zBleistift.
>
> Bei denen gibt es mWn inzwischen sogar (manchmal) oeffentliche IP-Adressen.
Damals zum Test haben die die gleichen 10.x-Adressen genommen wie ich
für das OpenVPN - gut, Letzteres ist flexibel.
> Außerdem klemmen jede Menge Leute ihren Firmen-Laptop zu Hause gerne hinter
> irgendwelche Router, die am häuslichen DSL-Anschluss hängen.
Kein Problem für das:
> > Hmm, ich schätze daher OpenVPN sehr.
>
> Firmenpolicies fordern aber nun mal oft IPSec,
... die in diesem Falle ich bestimmen konnte :-)
> vorgegeben und vorkonfiguriert, die Konfig des Clients sollte vom
> Mitarbeiter auch gar nicht geändert werden können.
Allerdings !!!1elf!!!
Wolfgang
F'up2p