Jump to content

hegl

Abgemeldet
  • Gesamte Inhalte

    704
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von hegl

  1. hegl

    CISCO VPN Client

    Bei CISCO habe ich gerade folgendes gefunden: Q. Why does the VPN Client disconnect after 30 minutes? Can I extend this time period? A. If there is no communication activity on a user connection during this 30-minute period, the system terminates the connection. The default idle timeout setting is 30 minutes, with a minimum allowed value of 1 minute and a maximum allowed value of 2,147,483,647 minutes (more than 4,000 years). Select Configuration > User Management > Groups and choose the appropriate group name to modify the idle timeout setting. Select Modify Group, go to the HW Client tab, and type the desired value in the User Idle Timeout field. Type 0 to disable timeout and allow an unlimited idle period. Leider habe ich keinen Schimmer, wo das einzustellen ist :mad: Wer weiss was?
  2. hegl

    CISCO VPN Client

    Welche HW nutzt ihr als VPN-Peer? Mit welcher Version?
  3. Hallo, ich teste gerade den CISCO VPN Client in Verbindung mit einer PIX 520, Version 6.3.3. Grundsätzlich funktioniert die Verbindung auch; das Problem ist aber dass die Verbindung in unregelmäßigen Abständen - mal 5 min, 15 min , 60 min oder mehr - getrennt wird. Auf der Client-Seite erhalte ich die Fehlermeldung "Secure VPN Connection terminated locally by the Client. Reason 412: The remote peer is no longer responding." Merkwürdigerweise laufen Site-to-Site VPN´s und PPTP-Clients weiter. Hat jemand eine Idee was das sein könnte, bzw. wie ich an die Sache herangehen kann? Ein ping auf das VPN-Peer ist ok, d.h. keine Zeitüberschreitungen oder erhöhte Antwortwerte. Gruß hegl
  4. hegl

    ACL bei VPN

    erledigt!
  5. hegl

    Pix, Icmp

    Hallo, ich habe Die config von Markus (Blacky_24) http://www.mcseboard.de/cisco-forum-allgemein-38/pix-501-any-definition-90296.html?highlight=icmp mal eins zu eins übernommen, weil ich den ping nicht hinbekomme :( Leider funktioniert sein Beispiel bei mir nicht - warum auch immer? Es funktioniert nur, wenn ich: access-list OUTSIDE-IN permit icmp any any konfiguriere. Sobald ich die object-group mit angebe, geht´s nicht mehr. Hat jemand eine Idee warum? Fehlermeldung ist immer: No translation group found for icmp <inside IP> <outside IP> (type 8, code 0) Irgendwie ganz merkwürdig, denn alle anderen ACL´s für unterschiedlichste Ports und Destinations laufen. Bin für jede Anregung dankbar.
  6. Hallo, ich habe folgendes Szenario: PIX mit DMZ (172.20.20.0) über die von INSIDE (10.10.10.0 ) über die DMZ in ein anderes LAN zugegriffen wird. Funktioniert prächtig :-) Alle INSIDE-Clients greifen gleichzeitig auf Ressourcen über ein VPN (OUTSIDE) auf Ressourcen (172.30.30.0) an einem anderen Standort zu. Funktioniert auch prächtig :-) Nun muss aber aus dem fremden LAN über die DMZ ein Zugriff über das VPN erfolgen. Problem ist hierbei, dass weder die Adressen aus diesem LAN, als auch die aus der DMZ nicht durch den Tunnel dürfen. Also habe ich mir gedacht, ich "verstecke" mich hinter einer IP-Adresse aus dem INSIDE. Dazu habe ich folgendes konfiguriert: static (inside,dmz) 172.20.20.1 10.10.10.1 netmask 255.255.255.255 static (outside,inside) 10.10.10.1 172.30.30.1 netmask 255.255.255.255 Soll heißen: die INSIDE-Adresse 10.10.10.1 ist in Wirklichkeit die hinter dem VPN (172.30.30.1) und die 172.20.20.1 ist das mapping aus der DMZ nach INSIDE. Leider funktioniert´s nicht. Der Zugriff aus dem INSIDE über die virtuelle Adresse funktioniert aber! Was mache ich falsch? Ich habe auch schon versucht testweise das DMZ-Netz mit in den Tunnel zu schieben, aber auch dann kommt auf der anderen Seite nichts an. Heisst für mich auch, dass der Fehler vorher irgendwo liegt. Nur wo? THX.
  7. Hast Du mal überlegt, ob der Netgear ggf. das Problem ist? Soviele schlechte Erfahrungen wie mit dieser Marke habe ich noch nie erlebt!
  8. hegl

    Ping zu hoch

    Bisher ist mir dieses Sympton verborgen geblieben, aber du hast Recht. Sämtliche Switche in unserem LAN zeigen das gleiche Verhalten und wir haben noch nie irgendwelche Performance-Probleme gehabt. Scheint also irgendwie normal zu sein. Aber woran kann es liegen? Der Switch muss auf ein icmp-Paket antworten, also wird Rechenleistung verlangt, während beim ping auf einen angeschlossenen Rechner nur über die interne table das Paket weitergeleitet wird. Dies ist aber nur ein Vermutung!
  9. Warum sollte dies komplizierter sein? Die DMZ ist doch nichts anderes als das (inside-) LAN, nur dass die security beim LAN höher ist.
  10. Nachdem ein Freund wochenlang täglich mehrere Stunden damit verbracht hat, dieses "WinAntiVirusPro 2006" zu deinstallieren/löschen war der einzige Ausweg eine Neuinstallation. Trotz tatkräftiger Hilfe aus dem HiJacker-Forum war es ihm nicht gelungen, den PC wieder sauber zu kriegen. Mein Tipp wäre also sich nicht mit säubern aufzuhalten!
  11. Ich gehe mal davon aus, dass du von den 501-ern ins inside der 506-er zugreifen kannst. Dazu hast Du ja bestimmte access-lists eingerichtet. Wieso machst Du nicht das gleiche für die DMZ?
  12. hegl

    remotedesktop

    Habs zwar nicht ausprobiert, aber beim aktivieren oder deaktivieren ändern sich der folgende Schlüssel: HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Control\ TerminalServer\ fDenyTSConnections REG_DWORD=0 bzw. 1
  13. hegl

    PIX, VPN, Xauth

    Für alle die´s interessiert: habe jetzt zusätzlich mal den Befehl isakmp peer ip <ip-address> no-xuath konfiguriert und schon klappt´s.
  14. hegl

    PIX, VPN, Xauth

    Hallo, ich habe seit einiger Zeit mehrere Site-to-Site, sowie eine VPN-Client Verbindung (testweise) auf einer PIX Version 6.3.3 konfiguriert. Soweit läuft auch alles zufriedenstellend. Nun möchte ich, da die Clients nun wirklich produktiv laufen sollen, neben der Authentifizierung des groupname und pw zusätzlich eine Authentifizierung der User konfigurieren. Dazu habe ich folgendes konfiguriert: crypto map map-name client authentication aaa-group-tag Auf den ersten Blick funktioniert das auch ganz gut. Aber nach Ablauf der Timer zur Erneuerung der Site-to-Site Schlüssel kommen diese Tunnel nicht mehr hoch, obwohl ich, wie im manual gefordert den isakmp key mit no-xauth konfiguriert habe: isakmp key secretkey1234 address 10.2.2.2 netmask 255.255.255.255 no-xauth Weiss einer wo der Fehler liegt oder muss ich noch mehr konfugurieren? THX. | EDIT: Da ich bei der Identifizierung des Peers über die IP-Adresse gehe isakmp identity address habe ich auf den Befehl isakmp peer fqdn no-xauth (wie in der Doku angegeben) verzichtet.
  15. Hallo Markus, ich sehe das Board als Medium von Austausch von Informationen. Selbstverständlich liegt mir die Doku vor und ich habe vor meiner Anfrage dieses 462-Seiten starke Skript vor-und-zurück gewälzt um eine Lösung zu finden - leider vergeblich. Deshalb bin ich froh, wenn sich hier jemand die Mühe macht, mir zu helfen, anstatt abzuwarten bis des Rätsels Lösung vorhanden ist und dann mit klugen Ratschlägen aufzuwarten. Nichts für ungut, will Dir nicht zu nahe treten, aber es gibt Menschen wie mich, die selbst mit manch konzeptionellen Dingen in Beschreibungen nichts anfangen können und sich sehr über ein solches Forum wie hier freuen! hegl P.S. Bevor ich jetzt lange suchen muss: was heisst "RTFM" ?
  16. Jippie - ich habe Dich verstanden :) :) :) Vielen Dank für Deine Geduld und Mühe.
  17. So, allmählich versteh´ ich Dich besser :) Im Prinzip heisst das also, obwohl ich beim NAT schon eine Zugriffskontrolle mache, wird diese nicht angezogen, weil ich sie nicht dem inside interface zuordne. Also beschränkt sie sich erstmal nur auf´s NAT. Erst mit weiteren access-list mit anderen access-list id´s und Zuordnung zum inside interface solte alles funktionieren (Zugriffskontrolle). Richtig so?
  18. Irgendwie scheinen wir zwei ganz schön aneinander vorbei zu reden? Wichtig für mich ist, dass die gruppierten internen IP´s auf unterschiedliche externe IP´s genattet werden, z.B. 10.10.10.0 --> 80.80.80.80 10.10.11.0 --> 80.80.80.81 10.10.12.0 --> 80.80.80.82 usw. wobei die auch noch unterschiedliche Berechtigungen haben, weil in dem 10-er Netz "normale" User sind, im 11-er Netz "etwas mehr berechtigte" User und im 12-er Netz die Admins.
  19. Wenn das so geht, wäre ich postiv überrascht. Bin bis jetzt eigentlich davon ausgegangen, wenn ich eine access-list konfiguriere, muss ich diese auch einer access-group zuordnen. Ist das ein Trugschluss? So wie Du es darstellst, kann ich eine access-list auf zweierlei Arten zuorden: - einmal per nat / global - oder per access-group Ich lass mich überraschen :)
  20. Die Leitung ist was länger, kannst Du mir bitte ein Beispiel schreiben? THX.
  21. 1) Leider verstehe ich Deine Frage nicht. Wie soll ich das in eine ACL machen? 2) Jepp, die Hosts aus verschiedenen Netzen sollen unterschiedlichen exterenen IPs zugeordnet werden. Bin weiterhin für jede Anregung dankbar. hegl
  22. Was verstehst Du bei einer PIX unter einem Subinterface? VLAN? - No chance! Vielleicht habe ich mich auch nicht richtig ausgedrückt, dass hier niemand Hilfe zu m.E. basics geben kann. Im Momnet arbeite ich nur mit einzlenen IP´s bei den policies, dann sieht das ungefähr so aus: access-list traffic_out permit tcp any any eq www access-list traffic_out permit tcp host 10.10.10.10 any eq pop3 access-list traffic_out permit tcp host 10.10.11.11 any eq ssh global (outside) 10 80.80.80.80 netmask 255.255.255.255 global (outside) 20 80.80.80.81 netmask 255.255.255.255 global (outside) 30 80.80.80.82 netmask 255.255.255.255 nat (inide) 10 10.10.10.10 255.255.255.255 nat (inside) 20 10.10.11.11 255.255.255.255 nat (inside) 30 0 0 access-group traffic_out in interface inside Somit habe ich verschiedenen Usern unterschiedliche Berechtigungen zugeteilt, welche dann auch noch eine unterschiedliche NAT-Adresse erhalten. Bei meiner neuen Konfiguration arbeite ich mit object-groups. Das sieht dann ungefähr so aus, nachdem ich die object-groups definiert habe: access-list traffic_out_10 permit tcp object-group Special_User any object-group EMail_Ports access-list traffic_out_20 permit tcp object-group ALL_User any object-group Web_Ports global (outside) 10 80.80.80.80 255.255.255.255 global (outside) 20 80.80.80.81 255.255.255.255 nat (inside) 10 access-list traffic_out_10 nat (inside) 20 access-list traffic_out_20 So, und nun mein Problem: die verschiedenen access-list muss ich nun dem interface inside zuordnen, da dort die policy ziehen soll. Doch leider kann ich ja nur eine access-list einem interface zuordnen. Grübel, grübel, grübel... :confused: Vielleicht weiß ja doch einer was? :) Bevor jetzt die Frage kommt, warum ich dies mache: Ich habe es mit 8 CLASS-C VLAN´s zu tun, sprich 8 x 255 Adressen. Bei meiner aktuellen config hat dies mittlerweile Ausmaße erreicht, die nicht mehr zu handeln sind - deswegen nun alles über object-groups. THX.
  23. Hallo zusammen, hat jemand eine Idee, wie ich am einfachsten folgendes Szeanrio konfiguriere? Ich habe mehrere Gruppen von IP-Adressen. Gruppe1 sollen z.B.nur per http Internet nutzen, Gruppe2 dagegen zusätzlich pop3, smtp, eine weitere Gruppe alle Ports. Gleichzeitig sollen die Gruppen auch unterschiedliche NAT- bzw. PAT-Adressen erhalten. Also habe ich verschiede object-groups network bzw. object-groups service. Konfiguriere ich jetzt die access-lists kann ich aufgrund der Zuordnung beim nat-Befehl: access-list (inside) 10 access-list 100 nur eine access-list-anziehen (siehe unten). Da ich aber verschiede PAT-Adressen erzwingen möchte habe ich ein Problem. Konfiguriere ich: global (outside) 10 access-list 100 global (outside) 20 access-list 200 nat (inside) 10 access-list 100 nat (inside) 20 access-list 200 kann ich bei der Zuordung zum interface ja nur eine access-group anziehen, z.B. access-group 100 in interface inside Eine Mehrfachzuordnung zum interafce ist nicht möglich, da dann überschrieben wird. Wie komme ich aus dem Dilemma heraus? THX.
  24. Das siehst Du genau richtig! Gruß hegl
  25. schau mal hier, ob das passt: Configuring Router-to-Router Dynamic-to-Static IPSec with NAT* [iPSec Negotiation/IKE Protocols] - Cisco Systems
×
×
  • Neu erstellen...