dongel 10 Geschrieben 11. März 2004 Melden Teilen Geschrieben 11. März 2004 hallo @all Bin ein ziemlicher Frischling im Cisco Bereich und hab folgende Fragen: Ich möchte einen PPTP-Tunnel zu einem VPN-Server Aufbauen. WKS>Cisco801>VPN-Server. wenn ich von meiner workstation(win2000pro) einen Tunnel aufbauen will kommt ne Meldung "Port is not connected" von einem anderem Rechner (xp pro) ebenso mit der zusätzlichen Meldung das es am NAT des Routers liegen könnte. Der VPN-Server funktioniert, hab einen Kollegen extern testen lassen. So, hab mal NAT deaktiviert das Ergebnis ist, daß nicht geroutet wird. Versuchsweise mal auf BRI0 deak und dann auf ETH0. Immer dasselbe Ergebnis das nicht geroutet wird. Wieso brauch ich denn NAT? Grundsätzlich ist doch kein NAT für einen Routing -Prozess nötig. Wo ist der Fehler? Und wenn NAT sein muß , wie öffne ich denn dann die benötigten Ports? Ach ja , nochwas: was ist denn die Escape -Sequence bei einem traceroute , hab schon wie bescheuert versucht und gesucht, aber nix gefunden. Vielen Dank und Gruß dongel Zitieren Link zu diesem Kommentar
Pretender 10 Geschrieben 11. März 2004 Melden Teilen Geschrieben 11. März 2004 Poste doch mal deine Config. Aber denk dran. Passwörter und alle sicherheitsrelevanten Sachen schmeiss raus. Zitieren Link zu diesem Kommentar
dongel 10 Geschrieben 11. März 2004 Autor Melden Teilen Geschrieben 11. März 2004 Hier also die config: Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname cisco ! enable secret ! username cisco password ! ! ! ! ip subnet-zero no ip source-route ! isdn switch-type basic-net3 ! ! process-max-time 200 ! interface Ethernet0 ip address 192.168.7.2 255.255.255.248 ip access-group 121 in no ip directed-broadcast no ip proxy-arp ip nat inside ! interface BRI0 no ip address no ip directed-broadcast encapsulation ppp shutdown dialer pool-member 1 isdn switch-type basic-net3 ppp authentication chap pap callin ! interface Dialer1 description ISP ip address negotiated ip access-group 121 in no ip directed-broadcast no ip proxy-arp ip nat outside encapsulation ppp no ip split-horizon dialer remote-name Cisco1 dialer idle-timeout 300 dialer string 019389697 class DialClass dialer hold-queue 10 dialer pool 1 dialer-group 1 ppp authentication chap pap callin ppp chap hostname ppp chap password ppp pap sent-username ! ip nat inside source list 18 interface Dialer1 overload no ip http server ip classless ip route 0.0.0.0 0.0.0.0 Dialer1 ! ! map-class dialer DialClass access-list 18 permit 192.168.7.0 0.0.0.7 access-list 121 deny udp any eq netbios-dgm any access-list 121 deny udp any eq netbios-ns any access-list 121 deny udp any eq netbios-ss any access-list 121 deny tcp any eq 137 any access-list 121 deny tcp any eq 138 any access-list 121 deny tcp any eq 139 any access-list 121 permit ip any any time-range TIME dialer-list 1 protocol ip permit ! line con 0 exec-timeout 0 0 transport input none stopbits 1 line vty 0 4 exec-timeout 0 0 login local ! time-range TIME periodic daily 0:00 to 23:59 ! end Zitieren Link zu diesem Kommentar
Pretender 10 Geschrieben 11. März 2004 Melden Teilen Geschrieben 11. März 2004 Du benötigst vom Interface Dialer x einen GRE Tunnel zum VPN-Server. Also bei mir sieht das für einen einfachen GRE Tunnel so aus: interface Tunnel0 no ip address ip broadcast-address 0.0.0.0 tunnel source xxx tunnel destination xxx und dann noch eine passende Route: ip route 0.0.0.0 0.0.0.0 Tunnel0 Zusätzlich solltest du Port 1723 auf den VPN Server weiterleiten: ip nat inside source static tcp 192.168.0.4 1723 interface Dialer1 1723 Zitieren Link zu diesem Kommentar
dongel 10 Geschrieben 11. März 2004 Autor Melden Teilen Geschrieben 11. März 2004 VIelen Dank Wie man sieht ist das gre- Protokoll disabled, oder seh ich das falsch? Wie bekomm ich das denn an? Auf der Wks kommt jetzt "there was no answer" Und wie ist das mit NAT? Kann man den Router denn ohne fahren? cisco#sh int tunnel0 Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 1476 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (10 sec) Tunnel source 192.168.7.0, destination x.x.x.x Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Checksumming of packets disabled Last input never, output never, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/0, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out Zitieren Link zu diesem Kommentar
Pretender 10 Geschrieben 11. März 2004 Melden Teilen Geschrieben 11. März 2004 tunnel source ist Dialer 1 und destination die IP deines Server Zitieren Link zu diesem Kommentar
dongel 10 Geschrieben 11. März 2004 Autor Melden Teilen Geschrieben 11. März 2004 also habs genau so konfiguriert , aber auf der WKS bekomm ich nur " the specified port is not connected" . Fehlt noch was oder hab ich was falsch gemacht? Auf der Firewall des VPN-Servers seh die pakete auch ankommen GRE und PORT1723 und laufen laut FW auch durch. Und an der FW kanns ja nich liegen , die hab ich ja extern noch mal getestet. Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 1476 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (10 sec) Tunnel source 0.0.0.0 (Dialer1), destination 80.140.23.245 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Checksumming of packets disabled Last input never, output never, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/0, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out Danke und Gruß dongel Zitieren Link zu diesem Kommentar
dongel 10 Geschrieben 12. März 2004 Autor Melden Teilen Geschrieben 12. März 2004 also ich hab mal den tunnel von der cisco gestartet Resultat: cisco#tunnel name.homedns.org Translating "name.homedns.org"...domain server (62.225.252.244) [OK] Trying name.homedns.org (80.140.23.245, 57)... % Connection timed out; remote host not responding Wobei ich ja vermute das die 57 der Port ist der benutzt wird , zumal auf der Firewall auch soetwas ankommt IP + Destination port 57, wird natürlich geblockt. Wenn das das GRE -Protokoll sein sollte , dann ist das doch wohl falsch!! Hingegen wenn ich ich pptp vom 2000client starte, dann sieht das so aus als wenn GRE tatsächlich benutzt wird ( andererseits auf dem client "the specified port is not connected) , also auf der Firewall zu sehen. Bin echt ratlos. Ich muss gestehen, bin jetzt erst recht verwirrt. Kann mir das jemand mal erklären?? Wenn das GRE tatsächlich einen falschen Port nimmt, wie kann ich das denn ändern? Was geht denn da ab?? Danke und Gruß dongel Zitieren Link zu diesem Kommentar
Pretender 10 Geschrieben 12. März 2004 Melden Teilen Geschrieben 12. März 2004 Also.... ich bin mir sehr sicher, das 1723 der Port für PPTP ist. Und das GRE Protocol hat direkt keinen Port sondern ist eben ein IP Protocol. Wenn ich die Infos über das Tunnel0 Interface bei Dir richtig lese, dann verwundern mich ein zwei Zeilen. Die erste Tatsache ist dein Keepalive von 10sec..... (Hast du die eingestellt?) und dann die Tatsache, das die Destination die IP zu sein scheint, die du per ipcp zugewiesen bekommst. Poste bitte noch einmal deine Config. Zitieren Link zu diesem Kommentar
dongel 10 Geschrieben 12. März 2004 Autor Melden Teilen Geschrieben 12. März 2004 ich habe nix weiter konfiguriert, bin da deinen Anweisungen gefolgt. Hier nochmal die Konfig. was ich ausprobiert habe ist das IPnat unter int tunnel und direkt unter conf t, ändert nix; was ist denn richtig? Die destination ist über DYNDNS erreichbar, also ich geb da die domain an, wird auch direkt aufgelöst, sollte eigentlich nicht das Problem sein;oder? Danke und Gruß Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname cisco ! enable secret ! username cisco password! ! ! ! ip subnet-zero no ip source-route ! ip name-server 62.225.252.244 isdn switch-type basic-net3 ! ! process-max-time 200 ! interface Tunnel0 no ip address ip broadcast-address 0.0.0.0 no ip directed-broadcast tunnel source Dialer1 tunnel destination 80.140.23.245 ! interface Ethernet0 ip address 192.168.7.2 255.255.255.248 ip access-group 121 in no ip directed-broadcast no ip proxy-arp ip nat inside ! interface BRI0 no ip address no ip directed-broadcast encapsulation ppp shutdown dialer pool-member 1 isdn switch-type basic-net3 ppp authentication chap pap callin ! interface Dialer1 description ISP ip address negotiated ip access-group 121 in no ip directed-broadcast no ip proxy-arp ip nat outside encapsulation ppp no ip split-horizon dialer remote-name Cisco1 dialer idle-timeout 300 dialer string 019389697 class DialClass dialer hold-queue 10 dialer pool 1 dialer-group 1 ppp authentication chap pap callin ppp chap hostname ppp chap password ppp pap sent-username ! ip nat inside source list 18 interface Dialer1 overload ip nat inside source static tcp 192.168.7.4 1723 interface Dialer1 1723 no ip http server ip classless ip route 0.0.0.0 0.0.0.0 Dialer1 ip route 0.0.0.0 0.0.0.0 Tunnel0 ! ! map-class dialer DialClass access-list 18 permit 192.168.7.0 0.0.0.7 access-list 121 deny udp any eq netbios-dgm any access-list 121 deny udp any eq netbios-ns any access-list 121 deny udp any eq netbios-ss any access-list 121 deny tcp any eq 137 any access-list 121 deny tcp any eq 138 any access-list 121 deny tcp any eq 139 any access-list 121 permit ip any any time-range TIME dialer-list 1 protocol ip permit ! line con 0 exec-timeout 0 0 transport input none stopbits 1 line vty 0 4 exec-timeout 0 0 login local ! time-range TIME periodic daily 0:00 to 23:59 ! end Zitieren Link zu diesem Kommentar
n@ppo 10 Geschrieben 13. März 2004 Melden Teilen Geschrieben 13. März 2004 hi, das problem bei einer pptp-session via nat ist das der gre-tunnel vom server aufgebaut wird. der router muß also irgendwie erkennen das, das antwort-gre paket auf die pptp session für den client gedacht ist. das funktioniert zurzeit nur mit der pix im release 6.1/6.2/6.3 (fixup protocol pptp 1723) alternativen: 1: wie schon pretender erwähnt einen gre-tunnel von deinem router zum server konfigurieren. das problem ist das der server eine dyndns-adresse hat. d.h. du mußt mit einem script (des öfteren) überprüfen pb sich die destination gre-adresse ändert und gegebenenfalls ändern, alldieweil der router einen dyndns-adresse nur einmal auflöst wenn du sie im tunnel-interface einträgst. 2: du machst einen statischen nat eintrag für gre zu deinem client. das problem ist das es so etwas (zumindest direkt) nicht gibt. eventuell gibt es noch die möglichkeit das ganze mit einer route-map zu lösen. das sieht dann so aus. diesen befehl habe ich auf einem 1700er getestet mit einem 12.3er ios. bei meinem 2610er mit einem 12.2(T)-Release gibt es ihn so nicht.....testen # ip nat inside source static "adresse vom gre-client" interface dialer 1 route-map gre ! route-map gre 10 match ip address 101 access-list 101 permit gre any any ! access-list 101 permit ! access-list 101 permit gre any any # der befehl bzw. die tastenkombination für das abrechen eines trace ist. entweder strg+c, strg+z oder strg+shift+6 und dann x. wie pretender schon erwähnt hat pptp läuft auf tcp port 1723 und gre setzt auf ip protokoll-type 47 auf. Zitieren Link zu diesem Kommentar
dongel 10 Geschrieben 13. März 2004 Autor Melden Teilen Geschrieben 13. März 2004 also das geht auch nicht scheitert an: ip nat inside source static 192.168.7.4 interface dialer1 route-map gre ^ % Invalid input detected at '^' marker. .....er meckert das "interface" an. Unter Ip hab ich gesehen das es den vry command gibt: vrf Configure an IP VPN Routing/Forwarding instance was hat es denn damit auf sich?? Hab gerad schon versucht damit was zu machen, komm da aber auch nich weiter cisco(config)#ip vrf vpn % Can't create VRF vpn Grundsätzlich hab ich ja angenommen das die cisco alles auf Layer 2 routet ,bis auf das, was ich in der Access-list verbiete. Lieg ich denn da völlig falsch?? Das kann doch nicht sein das man einen stinknormalenPPTP-Tunnel nicht aufbauen kann : das ist ja jetzt "nur" client to side, wie sieht es denn dann erst mit einem side to side Netz-Design aus oder gar mit IPsec?? Da kann ja die Freeware -Geschichte fli4l mehr. Das kann doch nicht sein!! DAs muss sich doch mit einem angeblich professionellen Gerät bewerkstelligen lassen. *verzweifel* *zweifel* Was kann man denn jetzt noch machen? Ich will auch nich so schnell aufgeben, es muss!! eine Lösung geben. Vieeleicht fällt euch ja noch was ein!!!? Kann man den nich das NAT deaktivieren und trotzdem routen?Wenn NAT da im Wege steht kann man das doch einfach weglassen und es wird alles geroutet?? danke und Gruß dongel Zitieren Link zu diesem Kommentar
Pretender 10 Geschrieben 13. März 2004 Melden Teilen Geschrieben 13. März 2004 Dh. dein Server steht irgendwo ausserhalb deines Netzes und du willst mit einem Client aus deinem Netzwerk auf diesen connecten ? Zitieren Link zu diesem Kommentar
dongel 10 Geschrieben 13. März 2004 Autor Melden Teilen Geschrieben 13. März 2004 Genau so ist es- ups, hab ich das nich gesagt?? Gibt es denn ne Möglichkeit das so aufzusetzen? Danke und Gruß dongel Zitieren Link zu diesem Kommentar
dongel 10 Geschrieben 14. März 2004 Autor Melden Teilen Geschrieben 14. März 2004 tja liebe Kollegen, sieht so aus als ließe sich dieses Szenario nicht mit der 801 verwirklichen---Echt bitter :mad: Es sei denn Euch fällt noch irgendetwas ein!! Danke und Gruß dongel Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.