Hi,

ich habe WinXP Professional und bin dabei ein VPN (= Virtual Private Network) über das Internet aufzubauen, will dabei aber meine Firewall NIS2003 (= Norton Internet Security 2003) trotzdem laufen lassen. Ich muss also eine Regel erstellen, damit ankommende Anfragen zum Login in das VPN auch durchkommen. Welche Ports muss ich in der Firewallregel freigeben, damit ein reibungsloser VPN-Betrieb (Login usw.) möglich ist ? Ich weiß absolut nicht, welche Ports für VPN zuständig sind.

Danke für Eure Hilfe.

Torsten Hähnel

Och, das hängt davon ab, welchen Du auswählst

Wenn Du z.Bsp. IPsec over TCP machst, ist meist TCP 10000 der default Port. Aber default weist schon darauf hin, dass man jeden anderen wählen kann. Dann gibt's noch IPsec over UDP als NAT/PAT Alternative, dann haben meist VPN Dialer eine integrierte Firewall, die per Loopback auf localhost mehrere TCP Anschlüsse offen hält und so weiter und so lustig.

Was ich nicht verstehe: Deine NIS Firewall fragt doch bei jedem Verbindungsverscuh ab, ob dieser erlaubt sein soll. So sollte die Freigabe der benötigten Ports doch ein Leichtes sein!? (Ausser es gibt ein paar default Regeln bei NIS, die VPN verhindern, was man aber bei erfolglosem Verbindungsversuch durch das Log feststellen kann...).

</font><blockquote>Zitat:</font><hr />Original erstellt von Bo Derek:
Was ich nicht verstehe: Deine NIS Firewall fragt doch bei jedem Verbindungsverscuh ab, ob dieser erlaubt sein soll. So sollte die Freigabe der benötigten Ports doch ein Leichtes sein!? </font>[/QUOTE]Vielleicht sollte man hier berücksichtigen, dass selbst so eine Aktion den durschnittlichen NPF User normalerweise schon bei weitem überfordert.

wizard

Naja, bin schon ein wenig mehr als durchschnittlicher NPF-User.
Das Kuriose ist, dass ich keine Meldung der NPF bekomme. Ich weiß, dass normaler Weise die Meldung kommt, dass ein Remote-Computer auf ein bestimmtes Proggi zugreifen will. Ich habe aber auch die automatische Programmsteuerung ausgeschalten, bekomme also immer eine Meldung, wenn ein unbekanntes Programm zugreifen will.
Ich vermute, dass die svchost.exe hinter der Sache mit VPN steckt, da der RAS-Server mit der svchost.exe gestartet und wahrscheinlich auch verwaltet wird. Die EXE steht bei mir nicht in der Liste der manuellen Programmsteuerung. Die svchost.exe hat allerdings eine ganze Menge Ports offen, so dass ich nicht eindeutig zuweisen kann, was alles für Dienste dahinter stecken. Deswegen möchte ich auch nicht eine generelle Freigabe für die svchost.exe machen. Die Sache mit der Protokollierung schau ich mir mal an, auf die Idee bin ich noch nicht gekommen.

So, jetzt hab ich mal genauere Information dank der NPF-Protokollierung. Folgendes Protokoll wird bei einem Verbindungsversuch und aktivierter FW ausgespuckt (die DYNDNS und IP des Remote-Computers hab ich entfernt):

TCP-Syn-Paket an nicht abhörendem Anschluss. Das Paket wurde nicht übertragen.
Quell-IP-Adresse: xxx.xxx.xxx.xxx
Ziel-IP-Adresse: spirit-t-h(192.168.1.110)
TCP-Quellanschluss: 1558
TCP-Zielanschluss: pptp(1723)
TCP-Nachrichten-Flags: 0x00000002

Es handelt sich offensichtlich um den PPTP-Port, der ja für VPN zuständing ist (zumindest das PPTP-Protokoll). Nun hab ich eine Firewall-Regel erstellt, die diesen Port durchlässt, aber es kommt noch immer die selbe Nachricht. NPF glaubt, dass dahinter kein Programm steht und blockiert diesen Port, so das der andere Computer denkt, da ist nix.
Wenn ich jetzt aber die Firewall ausschalte oder denjenigen mit seiner IP-Adresse (per Dynamischer DNS) als Vertrauenswürdig einstufe, dann funktioniert alles korrekt. Weiß ehrlich gesagt jetzt nicht mehr weiter. Ich vermute nur, dass dieser Port vielleicht erst angepingt wird und da Pings von der NPF blockiert werden, denkt der Client da ist nix und gibt es dann auf. Jedenfalls bekommt der VPN-Client dann eine Meldung, dass der Server (also mein Computer) nicht erreichbar ist.

PS: Meine IP Addresse ist so, weil ich hinter einem Router sitze. Mein Computer ist per DMZ offiziell von außen sichtbar, oder auch nicht, wenn die Firewall alles blockiert.