mturba

Um was geht's überhaupt? Welcher Tunnel? Kannst du Dein Problem mal ein bisschen genauer beschreiben? Wie sieht die Konfiguration des 1812 aus?

Hm... Versuche mal, die max. zulässige Länge der DNS-Antworten hochzusetzen, z.B. auf 576: conf t fixup protocol dns maximum-length 576

no file verify auto: Cisco IOS Configuration Fundamentals Command Reference, Release 12.4 - exception core-file through ip ftp passive [Cisco IOS Software Releases 12.4 Mainline] - Cisco Systems spanning-tree extend system-id Catalyst 4500 Series Switch Cisco IOS Command Reference, 12.2(25)SG - snmp ifindex clear through vtp v2-mode [Cisco Catalyst 4500 Series Switches] - Cisco Systems

Du kannst nur eine Accessliste pro Interface haben, deswegen musst du aus den beiden ACLs eine machen z.B.: ! static (inside,outside) tcp 217.146.123.123 smtp 192.168.13.6 smtp netmask 255.255.255.255 0 0 static (inside,outside) tcp 217.146.123.123 5003 192.168.13.3 5003 netmask 255.255.255.255 0 0 ! access-list acl_outside permit tcp any host 217.146.123.123 eq smtp access-list acl_outside permit tcp any host 217.146.123.123 eq 5003 ! access-group acl_outside in interface outside

Ich habe noch eine 3 Monate gebrauchte PIX 501 mit 10-User-Lizenz übrig. Falls du daran Interesse hast, sag bescheid :)

Hm, klingt irgendwie nach nem Problem mit NAT... hast du NAT konfiguriert?

Hm, auf die Idee bin ich noch garnicht gekommen ;) Hab auch die Version 12.4(9)T am Laufen, sollte also bei mir auch so funktionieren. Danke für den Tipp! Gruß, Martin

Vielen Dank für die Lorbeeren :) Ich habe die Sache noch etwas verfeinert. Mit der folgenden Konfiguration wird auch bei unplanmäßigen Verbindungsausfällen die WebVPN-Konfiguration aktualisiert: 1. Tracking-Objekt anlegen, welches überwacht, ob an Dialer0 eine IP-Adresse konfiguriert ist: track 1 interface Dialer0 ip routing 2. Ein Event-Manager-Applet erzeugen, welches das TCL-Updateskript ausführt, sobald der Status dieses Tracking-Objekts auf "up" wechselt. event manager applet update-webvpn event track 1 state up action 1 cli command "enable" action 2 cli command "tclsh update-webvpn.tcl" 3. Wie gehabt eine Kron-Occurence, die dafür sorgt, dass die Zwangstrennung kontrolliert nachts um 4:00 erfolgt. kron occurrence disconnect-pppoe at 4:00 recurring policy-list disconnect-pppoe Die andere Occurence ist nicht mehr nötig, da durch die Trennung automatisch ein Event ausgelöst und dadurch das Updateskript ausgeführt wird. Gruß, Martin

Wenn die Meldung "Driver Failure" lautet, würde ich zumindest ein Problem mit dem Router erstmal ausschließen...

Hi, hier eine ganz minimalistische Beispielkonfiguration: webvpn gateway webvpn_gateway hostname webvpn_gateway.domain.tld ip address 1.2.3.4 port 443 inservice ! webvpn context webvpn_context ssl authenticate verify all ! ! port-forward "mypc" local-port 13389 remote-server "192.168.1.1" remote-port 3389 description "RDP auf mypc" ! policy group webvpn_policy port-forward "mypc" auto-download default-group-policy webvpn_policy aaa authentication list default gateway webvpn_gateway inservice ! end Gruß, Martin

Mit WebVPN (inzwischen wird es meist SSL VPN genannt) kann man einen Remotezugang zum Netzwerk per Webbrowser realisieren, ohne dass ein VPN-Client auf dem Rechner installiert sein muss. Finde ich ganz praktisch, wenn man mal schnell mal von unterwegs an sein Netz möchte und keinen eigenen Rechner dabei hat. Desweiteren kann man damit Geschäftspartnern vorübergehend bestimmte Dienste zur Verfügung stellen, ohne dass diese einen VPN-Client dazu benötigen. Weitere Informationen: SSL VPN - Cisco Systems Gruß, Martin

Hi, sicher gibt es noch andere außer mir, die auf ihrem Router gerne WebVPN verwenden würden, aber eine dynamische IP-Adresse von ihrem Provider zugewiesen bekommen. Die WebVPN-Konfiguration erwartet allerdings ungünstigerweise die Angabe einer festen IP-Adresse. Da mein Provider ohnehin einmal am Tag eine Zwangstrennung vornimmt, habe ich das Problem bei mir folgendermaßen gelöst: 1. Ein TCL-Skript erstellt, welches die aktuelle IP-Adresse des Dialer-Interfaces ausliest und die WebVPN-Konfiguration entsprechend aktualisiert. Dieses Skript habe ich als flash:update-webvpn.tcl auf dem Router abgelegt: set myip [regexp -inline {\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}} [exec "show ip interface brief | include Dialer0"] ] ios_config "webvpn gateway webvpn_gateway" "ip address $myip port 443" 2. Anschließend zwei Kron-Policys angelegt, eine zum Trennen der PPPoE-Verbindung, die andere zum Ausführen des TCP-Skripts: ! kron policy-list disconnect-pppoe cli clear pppoe all ! kron policy-list update-webvpn cli tclsh flash:update-webvpn.tcl 3. Zum Schluß zwei Kron-Occurences, die nachts um 4:00 (da störts am wenigsten) die Verbindung trennen und eine Minute später die WebVPN-Konfiguration aktualisieren: kron occurrence disconnect-pppoe at 4:00 recurring policy-list disconnect-pppoe ! kron occurrence update-webvpn at 4:01 recurring policy-list update-webvpn Eventuell hilft das ja jemandem weiter, der auch schon mit diesem Problem gekämpft hat... falls jemandem eine elegantere Lösung einfällt, bin ich auch gerne dafür zu begeistern :) Gruß, Martin

Hi, das ist richtig, in der ASA kann nur entweder IPS oder AntiSpam verwendet werden, nicht beides gleichzeitig.

Hat das PPP-Debugging was gebracht?

Wer vergibt denn in diesem Netz die IP-Adressen? Wird an deinem Standort mit dynamischer VLAN-Zuordnung gearbeitet?

Folgende Debugs könnten evtl. noch weiterhelfen, um die Ursache der Verbindungstrennung zu finden: debug ppp error debug ppp negotiation

Er hat damals das Bootcamp bei der Isarnet AG in München besucht, ist allerdings schon ne Weile her, das war 2003. Ein Norbert Ulmer soll auch nicht schlecht sein.

Hi Fu, ein Arbeitskollege von mir war schonmal bei nem Bootcamp, war dann auch erfolgreich in Brüssel - ich schreib ihm grad mal ne Mail, wo er da war...

Hast du mal versucht, das Ding per TFTP zu booten? Cisco 826, 827, 828, 831, 836, and 837 and SOHO 76, 77, 78, 91, 96, and 97 Routers Software Configuration Guide - ROM Monitor - Cisco Systems Z.Bsp. so: rommon 1 > IP_ADDRESS=192.168.1.1 rommon 2 > IP_SUBNET_MASK=255.255.255.0 rommon 3 > TFTP_SERVER=192.168.1.2 rommon 4 > TFTP_FILE=c827blablabla.bin rommon 5 > tftpdnld -r Wobei der TFTP-Server dann die IP-Adresse 192.168.1.2 haben und ein TFTP-Daemon laufen sollte...

Hi ich hab das selbst auch noch nie getestet, bin nur darauf gestoßen und war der Meinung, das könnte Dir weiterhelfen. Es gibt offensichtlich Tests, die während des Betriebs durchgeführt werden können und Tests, die eine Betriebsunterbrechung verursachen, weil dazu ein Reload des Switches durchgeführt wird. Im Zweifelsfall steht das dann aber wohl zu den entsprechenden Kommandos in der Command Reference: Gruß, Martin

Hallo ck84, das ist so nicht richtig, wie man zum Beispiel an diesem Thread sehen kann: http://www.mcseboard.de/cisco-forum-allgemein-38/0815-switch-trunkport-105634.html Manche nicht managebaren Switche sind so "dumm", dass sie die Frames trotz evtl. auftretender Übergröße und trotz eines für einen nicht 802.1q-fähigen Switch ungültigen Eintrags im Type-Feld des Ethernet-Frames nicht verwerfen. Nicht für alles muss man teure Hardware kaufen, wenn günstigere Hardware die Anforderungen auch erfüllt. Viele Grüße, Martin

Eventuell hilft dir eine Online-Diagnose weiter: Catalyst 3750 Switch Software Configuration Guide, 12.2(25)SEE - Configuring Online Diagnostics [Cisco Catalyst 3750 Series Switches] - Cisco Systems

Hast du auf dem 871 ein Image mit Firewall-Featureset? Dann könntest du das z.B. so lösen: ! ip inspect name permit_pptp pptp ! int dialer0 ip inspect permit_pptp out !

@sebastian.f: Welche Sachen meinst du damit? Ich hatte mit der CatOS-Dokumentation bisher noch keine Probleme...

Der Rechner müsste prinzipiell nur seine IP-Adresse im VLAN 2 haben, damit er in diesem VLAN erreichbar ist. Und natürlich das gleiche native VLAN verwenden, wie der 35xx.