Jump to content

hegl

Abgemeldet
  • Gesamte Inhalte

    704
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt 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. 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. 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.

  6. 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 :confused:

    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.

  7. Hallo,

     

    ich würde gerne wissen ob es möglich ist, die vergebenen IP-Adressen von eingewählten VPN-Clients in einer PIX 506 fest zu vergeben. Sei es über die Konfiguration des VPN-Clients von Cisco oder direkt in der PIX.

     

    Für jede Hilfe bin ich dankbar.

     

    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.

     

     

    Oder kann ich den Adressenpool für die VPN-Einwahl über die PIX auf meinen internen DHCP-Server legen ?

     

     

    Dies möchte ich mal verneinen, da mir nichts bekannt ist.

  8. 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?

  9. 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:

  10. 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!

  11. 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...

  12. 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

  13. 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

×
×
  • Neu erstellen...