Jump to content

hegl

Abgemeldet
  • Gesamte Inhalte

    704
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von hegl

  1. Jepp, die PIX administriere ich auch. Auf der PIX habe ich zuerst einmal mit dem PDM und dabei mit dem VPN Wizzard die Befehle erstellen lassen. Merkwürdig hierbei ist, dass eine vpngroup angelegt wird,also so wie beim Client mit user-id und pw. Auf dem Linksys muss ich dagegen bei der Tunneleinrichtung einen PSK angeben; das passt natürlich nicht. Linksysmodell ist der BEVP41 Linksys.com – Produkte/Drahtgebunden/Netzwerk-Basisprodukte/Router, Modems und Gateways/BEFVP41
  2. Ich habe zwar das Forum gründlich dursucht, aber nichts passendes gefunden. Hat jemand ein Beispiel wie ich über meinen DSL-Anschluss zu Hause mit einer dyn. IP eine Verbindung zu einer PIX 6.3.(5) mit statischer IP aufbaue? VPN-Client kriege ich hin, genauso site-to-site mit statischer IP, aber mittels meines Linksys-VPN-Router mit dyn. IP zur PIX nicht.
  3. Hallo, folgendes Szenario: Ich betreibe für eine Firma ein PIX mit ein Netz (DMZ) 10.10.10.0/24, das per Site-to-Site-VPN in ein DataCenter (172.20.20.0/24) einer anderen Firma verbunden ist. Der Tunnel klappt soweit auch. Nun muss ich aber aus dem DataCenter hinaus von einem Server ins inside-LAN der PIX zu einem Netzwerkdrucker (10.20.20.1/24) drucken. Das Problem ist, dass im DataCenter dieses Netz schon bekannt ist. Also habe ich mir gedacht, ich verstecke dieses Netz bzw. diese eine IP hinter einer Adresse der DMZ. Dazu habe ich ein static (inside,dmz) 10.10.10.1 10.20.20.1 netmask 255.255.255.255 conduit permit tcp host 10.10.10.1 eq 515 host 172.20.20.1 konfiguriert. Nur leider funktioniert das nicht. Bei einem telnet per tcp/515 erhält der Server 172.20.20.1 keine Antwort. Zum Testen habe ich die zwei Befehle wieder gelöscht und einen Drucker mit dieser IP in die DMZ gestellt; hier klappt das telnet per tcp/515 hervorragend. Also muss es doch m.E am NAT liegen? Im CISCO-Forum hat mir einen CISCO-Mitarbeiter geschrieben, ich müsste die inside-IP mit in die encrypted ACL aufnehmen. Das kann doch wohl nicht wahr sein, wofür habe ich denn sonst NAT?
  4. hegl

    VLANs mit ASA

    Unsere PIX soll nun einer ASA weichen. Ich möchte nun auf den verschiedenen Interfacen mehrere VLAN´s konfigurieren - soweit auch kein Problem. Was mir Kopfzerbrechen bereitet ist die Struktur, d.h. wie ich dies an dem physikalischen Interface zur Verfügung stelle. Ordne ich dem physikalischen Interface ein Dummy-Netz zu und konfiguriere alle VLAN´s als Subinterface oder nehme ich eins der VLAN´s als physikalisches und den Rest dann als Subinterface. Ich sehe die Vor- bzw. Nachteile nicht bei den beiden Varianten. Weiss jemand mehr?
  5. hegl

    CISCO VPN Client

    Des Rätsels Lösung heisst nat-traversal! isakmp nat-traversal 20 (20 = default) Damit nutzt der Client udp/4500 der natürlich auch freigeschaltet sein muss! Sag´ Bescheid, ob´s funktioniert!
  6. Jepp, so kann man sich täuschen :mad: Mit Wireshark festgestellt, dass es doch der ****e Virenscanner ist. Da hat sich ein Fehler in die Softwareverteilung eingeschlichen und zeigt bei den Updates doch nicht auf unseren lokalen Server. Danke für die Tipps.
  7. Hallo, ich stelle seit kurzem fest, dass unsere neuen PC´s mit XP-Installation alle 5 min. versuchen eine FTP-Verbindung aufzubauen. Merkwürdigerweise immer auf unterschiedliche IP-Adressen, aber immer als anonymous mit pw: somebody@somecompany.com. Ausser dem OS ist nur ein aktueller Virensacnner installiert, der seine Updates von einem lokalen Server bezieht. Das kann ich also ausschließen. Welche Möglichkeiten habe ich zu erfahren, welcher Prozess die ftp-connection initiiert und was dahinter steckt. Wenn ich die IP-Adressen checke erhalte ich Zugehörigkeiten nach USA, Kanada, Schweden oder England.
  8. Hallo, kennt sich jemand mit "password aging" beim ACS-Server aus? Bis dato müssen unsere Mobile-User sich bei der VPN-Einwahl über den ACS-Server gegen die Windows-Data-Base authentifizieren. Nachteil ist hier, dass die User dabei ihr Passwort nicht ändern können. Der ACS-Server bietet hierzu aber das feature "password aging" an, mit dem dies möglich sein soll. Leider habe ich hier ein Verständigungsproblem und schaffe die Einrichtung nicht Was mir vorschwebt ist, dass es eine von der Windows-Domäne losgelöste Datenbank gibt, in der UserID und Passwort verwaltet werden (egal ob local oder extern Database) und User rechtzeitig vor Ablaufen des PW warnt und zur Eingabe eines neuen PW auffordert.
  9. M.E. müsste dies über den ACS-Server von Cisco möglich sein. Hab´s noch nicht probiert, aber die Optionen kannst Du bei den Usern festlegen, wenn Sie sich authentifizieren. Inwiefern dies auch freie Radius-Server ermöglichen, weiß ich nicht. Dies möchte ich mal verneinen, da mir nichts bekannt ist.
  10. Hallo, unsere User müssen sich beim Internetzugang erst an der PIX authentifizieren. Dazu nutze ich den Befehl virtual telnet. Zur Verbesserung der Benutzerfreundlichkeit würde ich dieses gerne über eine Web-Site laufen lassen - so mit Buttons für An- und Abmeldung. Das Problem hierbei ist, dass dann die IP-Adresse des WEb-Servers auf der die Web-Site liegt freigeschaltet wird. Heisst also, dass die Web-Site die IP-Adresse des anfragenden Clients weitergeben muss. Hat jemand eine Idee, wie man dies bewerkstelligen kann?
  11. Du musst ESP (Protokoll-Nr. 50) und ISAKMP (UDP/500) erlauben, dann sollte es klappen. Nutzt Du AH (Protokoll-Nr. 51) musst Du auch dieses freischalten.
  12. Gibt es Erfahrungswerte wieviel Speicher, speziell bei einer 520-er, zur Verfügung stehen sollte? Meine PIX hat mal gerade 200kB von 32 MB zur Verfügung. Wie kann ich sehen, wo der Speicher verbraucht wird? CPU-Auslastung liegt bei 1%. Was hilft, ausser einem Neustart? THX
  13. hegl

    CISCO VPN Client

    Verbindung ohne Router, also direkt mit PPPoE, bricht genauso aus unerklärlichen Gründen ab. Selbst wenn ich die CISCO-Vorgaben, d.h. beim VPN-Client die MTU auf 576 und bei der Netzwerkkarte auf 1300 reduziere ändert sich nichts :mad: :mad: :mad: Nur so nebenbei: Eine T-DSL Verbindung klappt dagegen hervorragend, auch mit Router :rolleyes:
  14. hegl

    CISCO VPN Client

    Habe explizit nichts konfiguriert, CISCO sagt dazu: The keepalive interval can be between 10 and 3600 seconds. The retry interval can be between 2 and 10 seconds, with the default being 2 seconds. The retry interval is the interval between retries after a keepalive response has not been received. You can specify the keepalive interval without specifying the retry interval, but cannot specify the retry interval without specifying the keepalive interval. Da im log von heute morgen nach dem ersten nicht beantworteten DPD_Request 1 min und 22 sec vergehen, bevor die Re-Initialisierung startet, und dazwischen der Client alles 5 sec einen neuen DPD_Request schickt, dürfte dies auch nichts bringen. Aber probieren geht über studieren... Und bis hierhin schon mal recht herzlichen Dank für deine Unterstützung!
  15. hegl

    CISCO VPN Client

    Und wie geht das ? Finde bei CISCO nichts! :mad:
  16. hegl

    CISCO VPN Client

    Wie zu erwarten war, hat es nichts mit XAuth zu tun - abbruch nach 9 min. und in der firma läuft´s und läuft´s und... Soll ich jetzt oder :) @Schusterharry: von dir hört man gar nichts mehr; hast du nichts neues?
  17. hegl

    CISCO VPN Client

    Bin schon wieder am testen - ist halt der Vorteil, wenn man(n) krank zu Hause ist und Langeweile hat ;) Habe mal versucht das log zu verstehen - nach einwandfreiem Aufbau gibts immer ein folgendes Szenario: 1 07:27:49.147 12/05/06 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY: DPD_REQUEST) to 222.111.222.111 2 07:27:49.147 12/05/06 Sev=Info/6 IKE/0x6300003D Sending DPD request to 222.111.222.111, our seq# = 1091218983 3 07:27:49.207 12/05/06 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 222.111.222.111 4 07:27:49.207 12/05/06 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY: DPD_ACK) from 222.111.222.111 5 07:27:49.207 12/05/06 Sev=Info/5 IKE/0x63000040 Received DPD ACK from 222.111.222.111, seq# received = 1091218983, seq# expected = 1091218983 Irgendwann kommt vom VPN-Peer keine Antwort mehr: 227 08:13:52.000 12/05/06 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY: DPD_REQUEST) to 213.168.100.252 228 08:13:52.000 12/05/06 Sev=Info/6 IKE/0x6300003D Sending DPD request to 213.168.100.252, our seq# = 1091219028 229 08:13:57.007 12/05/06 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY: DPD_REQUEST) to 213.168.100.252 230 08:13:57.007 12/05/06 Sev=Info/6 IKE/0x6300003D Sending DPD request to 213.168.100.252, our seq# = 1091219029 Dann erfolgt eine Re-Initialisierung, XAuth-Fenster poppt auf und ich werde aufgefordert die Anmeldedaten einzugeben. 278 08:15:14.919 12/05/06 Sev=Info/5 IKE/0x63000047 This SA has already been alive for 0 seconds, setting expiry to 3600 seconds from now 279 08:15:14.919 12/05/06 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 213.168.100.252 280 08:15:14.919 12/05/06 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 213.168.100.252 281 08:15:14.919 12/05/06 Sev=Info/4 CM/0x63100015 Launch xAuth application Da ich diese aber nicht so schnell eingeben kann, wird die Verbindung getrennt! Die Frage ist aber weiterhin: Wieso antwortet die PIX nicht mehr auf den DPD_Request? Ich habe jetzt einmal XAuth deaktiviert - schaun wir mal, was jetzt passiert...
  18. hegl

    CISCO VPN Client

    Könnte es was damit zu tun haben? CSCee11278: Change DPD algo to be less aggressive in detecting short Ab 6.3.4 soll dies geändert worden sein..
  19. hegl

    CISCO VPN Client

    Ein update würde ich allenfalls auf 6.3.5 machen. Aber wieso tippst Du auf die PIX, wenn es doch grundsätzlich läuft?
  20. hegl

    CISCO VPN Client

    Router habe ich schon mal getauscht - negativ! Ein anderer Kollege berichtet über die gleiche Problematik; anderer Provider und 6 MBit-DSL-Anschluss an einer anderen HW.
  21. hegl

    CISCO VPN Client

    Ich bin per DSL im Netz und habe den gleichen Provider wie unsere Firma. Also ist der connect auch nur ein paar Hops. Merkwürdigerweise läuft der VPN Client auf einem PC, angeschlossen hinter dem Provider-Router (also im gleichen Netz wie unser VPN-Peer), den ganzen Tag schon störungsfrei, während ich zu Hause mehrmals geflogen bin. Pings sind aber nach wie vor von daheim bestens, d.h. keine Zeitüberschreitungen und selten mal ein Wert über 100 ms, sonst alles bei ca. 45 ms. Habe mittlerweile auch mit mehreren Rechnern gleichzeitig zu Hause getestet. Fazit: ich fliege bein allen gleichzeitig raus, ist egal ob die eine schon 10 min und die andere Verbindung schon 30 min läuft. Mein Provider erzählte mir gerade (habe gute Connection :) ) ich solle es mal mit einem extended log auf der PIX versuchen. Davon habe ich aber leider (noch) keine Ahnung. Wer weiß mehr? hegl
  22. Kann ich davon ausgehen, dass Software, die unter XP läuft auch unter MCE läuft?
  23. hegl

    CISCO VPN Client

    Das log-file enthält ca. 11000 Zeichen und ich kann nur 4000 posten :mad: Also muss ich wohl auf die Freischaltung warten hegl
  24. hegl

    CISCO VPN Client

    Ich habe weiter getestet und einen Dauerping auf eine freigegebene Ressource laufen lassen. Ergebnis, auch nach fast 3 Stunden war der Tunnel noch aktiv. Nachdem ich den ping dann beendete, wurde die VPN- Verbindung nach weiteren 16 min. getrennt. Ich habe mal das logging beim Client als Kopie angehangen. Interessant wird es ab Ereignis 179, wobei da noch alles seinen rechten Weg zu gehen scheint. In Zeile 220 folgt dann eine erste Fehlermeldung, die verantwortlich für den Abbruch scheint. Leider sagt mir dies gar nichts. WER KANN HELFEN??? Abbruch nach 3 Stunden.txt
  25. hegl

    CISCO VPN Client

    Das scheint damit aber auch nichts zu tun zu haben. Ich habe eben mal alle time-out-Werte auf 8 Stunden gesetzt. Zur Zeit fliege ich ca. alle 15 min raus :confused: wobei die PIX ohne eine Unterbrechung in vernünftigen Zeiten antwortet.
×
×
  • Neu erstellen...