Welche Ports für VPN am router "natten"

[Mr.John_Doe 10]

Hallo,

 

ich richte gerade bei unserer Testumgebung ein VPN ein.

Im optimalsten Falle soll jeder die Möglichkeit, von außen auf das Netzwerk zugreifen zu können. Und das so sicher wie möglich.

Innerhalb unseres Netzes funktioniert das schon gut über L2TP. Jetzt hab ich aber versucht, von außerhalb über das Internet eine Verbindung herzustellen, was mir leider misslang. Ich kriege keine Verbindung zum VPN-Server.

Wir verwenden ein ELSA-DSL-Modem für die DSL-Einwahl und verwenden DynDNS.

Ich habe beide Ports (den für PPTP und den für L2TP) via NAT zum RAS weitergeleitet.

 

Kennt jemand das Problem und eine entsprechende Lösung?

 

Danke im voraus.

[Hr_Rossi 10]

Hi

 

Probier am anfang immer mit ip !

Dann kommt noch vor das man bei manchen routern den GRE (Generic Routing Encapsulation) Tunnel auch weiterleiten muss !

sonst für pptp: 1723,GRE

und für ipsec:

L2TP -(UDP) 500, UDP 1701

NAT-T - UDP 4500

ESP - Internet Protocol (IP) protocol 50

 

bei ipsec noch zusätzlich nat-t schaun obs unterstützt wird sonst bekommst probleme !

und den MS-KB-818043

 

mfg

rossi

 

p.s.: mit was natest du router oder linux oder mit was ?

[Mr.John_Doe 10]

Ich hab das jetzt mal mit einem anderen Testnetz versucht. Dort steht ein anderer Router.

 

Ich habe nur schnell PPTP eingerichtet und dann versucht, die Verbindung herzustellen.

Hier kommt er schon bis zur Option "Computername und Kennwort werden verifiziert"

Allerdings bricht er hier mit dem Fehler 721 ab "Der Computer antwortet nicht."

 

Wir nutzen hier ein ELSA-Gerät, was sich sehr bescheiden konfigurieren lässt.

Ich hab leider nirgends eine Option für das Generic Routing Encapsulation gefunden. Kannst du das vielleicht näher erklären?

 

Danke im voraus

[Hr_Rossi 10]

hallo

 

wekches betriebssytem ??

 

bei xp routing & ras dienst gestartet ?ß

 

bei w2k3 domäne ras clients ips zugewiesen bzw im AD ras einwählen der benutzer erlaubt ??

 

GRE ist nicht unbedingt nötig bei manchen routern da diese dies automatisch machen !

 

GRE ist dazu da um die verbindung dynamisch handzuhaben sprich nach der auth. auf einen anderer port weoter zu übertragen !

sonst wär ja nur ein vpn möglich und dann wär der 1723er port zu :D

 

mfg

 

rossi

[grizzly999 11]

hallo

GRE ist dazu da um die verbindung dynamisch handzuhaben sprich nach der auth. auf einen anderer port weoter zu übertragen !

sonst wär ja nur ein vpn möglich und dann wär der 1723er port zu :D

 

mfg

 

rossi

Das wäre mir aber völlig neu. Nein, PPTP läuft immer über TCP 1723. und ich hätte auch in der Praxis nie was anderes festgestellt.

Vor allem, wenn dem so wäre, dann dürfte ich meine FW ja gleich mal für tasuende Ports aufmachen

 

 

grizzly999

[Mr.John_Doe 10]

Der Server ist ein Windows Server 2003, der Client zum Testen ist ein XP mit SP2

Innerhalb des LAN funktioniert es ja Probremlos, aber aus dem Inet her nicht.

 

Ich hab aber Port 1723 weitergeleitet und die Firewall blockt das auch nicht.

IP-Adresse wird übern DHCP zugewiesen.

 

Wie schon gesagt, bei der zweiten Testumgebung kommt er durch. Das muss an dem ELSA liegen.

 

P.S. Ich hab noch eine Frage.

Ist es denn irgendwie möglich, Arbeitsplätzen, welche nie in der Domäne waren, Zertifikate zu übergeben. Ich meine die Rechner, welche zu Hause stehen, und von denen dann später gearbeitet werden soll?

[Hr_Rossi 10]

hi grizzly

 

Hab ich mir auch immer gedacht das dies nur über tcp1723 läuft ....

 

mit unserer linux firewall mit iptables wurde ich besseres geleert denk ich, denn da hat nur alleine das port-forwarding mit 1723 nicht geklappt, es ging nur mit 1723 bis zu benutzeranmeldung, nachdem du dich angemeldet hast ging nichts mehr.

 

Erst nachdem ich den GRE tunnel auch erlaubt hab gings dannn auch, und der tunnel stand.

 

GRE hin GRE her bei meinem Fall hab ichs auf alle Fälle gebraucht !

 

Hab mir dann auch angeschaut mit netstat welche ports verwendet werden, nachdem der tunnel stand und da war kein 1723 ...

 

mfg

 

rossi

[grizzly999 11]

GRE ist auch Protokollkennung 47, hat also keinen Port, weil ja alles verschlüsselt ;)

Das muss natürlich auch durchgelassen werden, aber an Ports nur der 1723

 

 

grizzly999

[Hr_Rossi 10]

ok ok

 

dann ists ja geklärt

 

mfg

 

rossi

 

p.s: welche zeretifikate meinst du für ipsec ??

muss aber gestehn das ich mit zertifikaten nicht soviel am hut hab da gibts sicher leute die dir besser helfen können !

[Mr.John_Doe 10]

Ich hatte gerade in dem Testraum einen Zwischenfall.

Dafür muss ich erklären:

 

Der Raum ist ans Internet über einen eigenständigen Anschluss angebunden (DSL Flat)

Die Internetverbindung wird über ein ELSA durchgeführt. Dahinter ist eine CISCO Pix als Firewall. Der ELSA schickt alles zur CISCO und die CISCO filtert u.a. nach Ports und leitet den Rest weiter. Das klappt auch wunderbar.

Jetzt hab ich die Firewallregeln der Pix nocheinmal überprüft und festgestellt, dass nur die eingehenden Pakete auf 1723 durchgelassen werden, nicht aber die ausgehenden.

Ich hab eine zweite Regel geaddet, dass auch der Ausgehende 1723-Verkehr durchgelassen werden soll und ab diesem Moment war das Internet des gesamten Raumes tot.

Ich entfernte die Regel und es ging wieder alles.

Warum wirkt sich das so aus?

 

Irgendwo hat mal einer angedeutet, das VPN einen Internetanschluss komplett dicht macht. Aber das hat dort widerum ein anderer verneint.

Was war da los?

 

Ich hab allerdings vorher schon einmal mit nem Packetsniffer geschaut und dann versucht, eine Verbindung herzustellen. Es kam am Server allerdings kein einziges Packet an.

[raiserle 10]

Ich habe nur schnell PPTP eingerichtet und dann versucht, die Verbindung herzustellen.

Hier kommt er schon bis zur Option "Computername und Kennwort werden verifiziert"

Allerdings bricht er hier mit dem Fehler 721 ab "Der Computer antwortet nicht."

 

Also ich habe das selbe Problem....

da ja weiter unten keine Lösung gekommen ist, werde ich halt nochmal fragen?

Was muss ich an meinem Router einstellen.