heiko2

Achtung: identity MUSS auf beiden Seiten identisch gesetzt sein.

D.h. wenn Du z.B. an der PIX bereits IPSec VPN's auf der Basis von Address-Identity betreibst, dann kannst Du dynamische VPN's knicken.

Dann können nur einzelne Clients über dynamische Maps rein.

Gruß Heiko

Hallo ...

das Update ist nicht nötig :)

1. Du baust die nächste Policy mit der nächsten priority.

z.b.

isakmp policy 30 authentication pre-share

isakmp policy 30 encryption aes-256

isakmp policy 30 hash sha

isakmp policy 30 group 5

isakmp policy 30 lifetime 3600

es werden ALLE policy während IKE Phase 1 und 2 angeboten und nach ihrer Priorität geprüft. die mit der höchsten, die auf beiden Seite passt wird verwendet.

2. Du baust die neue crypto map

crypto map KNAMAP 30 ipsec-isakmp

crypto map KNAMAP 30 match address acl_for_yyyy

crypto map KNAMAP 30 set peer y.y.y.y

crypto map KNAMAP 30 set transform-set ABC

crypto map KNAMAP 30 set security-association lifetime seconds 3600 kilobytes 4608000

3. Du baust den preshare key

isakmp key ******** address y.y.y.y netmask 255.255.255.255

und nun sollte es schon gehn

Gruß Heiko

Hallo,

in erster Instanz hängt es davon ab, wie Du die Identity gesetzt hast. D.h. steht die auf address, dann macht hier auch nur addresse einen Sinn.

Steht die auf name, dann der hostname.

Und ja, natürlich immer die der Gegenseite.

Ich bevorzuge IP-Adressen.

Um von beleibiegen IP adresse zu arbeiten (z.b. dynamische) gahen nur hostnamen.

Aus Sicherheitsaspekten ist damit schon mal klar, ip adressen sind sicherer.

Gruß Heiko

Hi Dirk,

ich hab mir gerade nochmal solch einen "uralten" 2503 reingetan. Der hat auf derm ROMMON echt kein XModem!! Dort kannst Du nur per TFTP von einem Server dir ein IOS holen und wenn das läuft per TFTP den Flash beschreiben.

Xmodem ist definitiv dor noch nicht supported!!

Gruß Heiko

Die Policy gibt lediglich einen Parametersatz zur Eruegung des IKE-SA an. Hier sind keine Peer-spezifischen Parameter.

Die Antwort ist ein klares ja. Die IKE-Policies sind wiederverwendbar und beinflussen bestehende Verbindungen nicht.

ACHTUNG: wird eine solche Policy geändert hat das nur Einfluss auf neue SA's bestehende bleiben bis zum Ende der Lifetime unberührt. D.h. diese müssen evtl. per clear explizit beräumt werden.

Hoffe das hilft.... ;)

Gruß Heiko

Hi Boris,

die PIX hält einen eigen Zertifikatsspeicher und unterhält sich wegen der Zertifikate nur mit einer CI, die auf der PIX autorisiert ist. D.h. die Clientzertifikate liegen entweder auf der PIX und sind durch ihren Path verifizierbar oder durch eine ONline-CA.

Der Radius wird ausschließlich zu Konfiguration, Accounting bzw. User-Authenifirierung vewrwendet. Das hat aber nichts mehr mit der Konfiguration des IPSec zu tun.

IPSec mit Zertifikaten tut für den Tunnel ohne Probleme.

Gruß Heiko

Ein Authentifizierungsproblem liegt nicht vor, wenn der Router erst garnicht antwortet.

Wenn der Router allein am ISDN hängt, kann auf die ISDN-Answer verzichtet werden. Dann geht der Router immer ran, wenn auf seinem S0 was ankommt.

Zu analysieren einfach:

debug dialer events ---> zeigt alle Events, die den Dialer/BRI angehen.

debug isdn events ---> damit alle Calls gesehen werden.

Gruß Heiko

Eine von externe konfigurierbare Callback-Adresse gibt es bei Cisco nicht!!

Diese Erweiterung des CBCP ist von Microsoft und nur in wenigen Access-Routern anderer Hersteller implementiert.

Bei Cisco ist nur CID-Callback möglich. D.h. in abhängigkeit der gemeldeten CID kann diese oder eine vordefinierte ander Nummer angerufen werden.

Gruß Heiko

Das Problem dürfte in der access-list 101 liegen.

Du hast diese sicher auf das Ethernet-Interface gestzt?! Wenn ja, dann hast Du die Richtung der Packete bei der Konfig nicht beachtet.

poste mal die Interface-config

gruß Heiko2

Das Problem besteht einzig und allein auf grund des aktiven NAT.

Da Du alles mit RFC-Adressen arbeitest kannst Du die ISDN-Interfaces einfach auf nat-inside setzen und die nat-config für diese löschen.

Dann tut's ...

Heiko2