11
Cisco PIX und ASA Workshop Teil 2 - IPSEC Site-to-Site Tunnel konfigurieren
Von Berlin nach Tokio übers wilde Internet. Tunnelblick inklusive!
Im Cisco PIX und ASA Firewall Workshop Teil 1 - Basiskonfiguration haben wir uns das Security Konzept der Cisco Security Appliances angesehen sowie eine Basiskonfiguration erstellt.
Heute gehts darum, eine IPSEC Verbindung von Berlin nach Tokio zu konfigurieren.
Eine Berliner Firma hat eine Niederlassung in Tokio und möchte diese per IPSEC an ihr Berliner Firmen-LAN koppeln. Dazu sollen zwei Cisco PIX Firewalls verwendet werden, die ideal geeignet sind um Firmenniederlassungen per IPSEC Tunnel miteinander zu verbinden.
Wie man die Interfaces der Komponenten konfiguriert haben wir bereits im ersten Teil unseres PIX/ASA Tutorials gesehen.
IP-Konfiguration Testlab
Router BERLIN (Router-1)
Router TOKIO (Router-2)
PIX Firewall BERLIN (PIX-1)
PIX Firewall TOKIO (PIX-2)
Router BERLIN (Router-1)
Router TOKIO (Router-2)
PIX Firewall BERLIN (PIX-1)
PIX Firewall TOKIO (PIX-2)
Damit wir die Konnektivität testen können schalten wir ICMP frei.
Die PIX blockiert ja per default ICMP Pakete, bzw. die ICMP Reply Pakete (Antwortpakete auf Ping Anfragen) werden per default am OUTSIDE Interface der PIX blockiert.
Um PING Tests machen zu können müssen wir entsprechende access-listen schreiben und die ACLs an die Interface binden damit sie wirken können.
Wenn man nur einen einzelnen PC freischalten will kann man auch "host <ip-adress>" verwenden.
Die access-list synthax:
oder wenn man nur einzelne IPs freischalten will...
PIX-BERLIN
PIX-TOKIO
Nun können wir testen ob der Ping von PIX1 zu PIX2 funktioniert.
Wenn ping nicht funktioniert, kann es sein dass das Interface noch nicht hochgefahren wurde!
Das testet man mit Befehl
Wenn das Interface nicht hochgefahren wäre, würde man folgende Ausgabe sehen:
Nun gehts ans Eingemachte.
Wir wollen zwischen den PIXen PIX-BERLIN und PIX-Tokio einen IPSEC Tunnel einrichten.
IPSEC ist eine Protokoll-Suite die im wesentlichen aus 2 Phasen besteht.
IKE Phase 1 und IKE Phase2.
IKE Phase 1 dient grob gesagt dazu einen sicheren Verbindungskanal zum VPN-Partner aufzubauen.
Über diesen sicheren (weil verschlüsselten) Kanal werden dann die Parameter für IKE Phase 2 ausgetauscht. Die zwei VPN Partner einigen sich auf Verschüsselungsalgorithmuy, Hash-Algorithmus sowie Lifetime Parametern (wie lange der ausgehandelte Sessionkey gültig sein soll) usw.
Zunächst mal konfigurieren wir die PIXen so, dass sie IPSEC Traffic unabhängig von bestehenden ACLs nicht blocken sollen.
Zunächst wird eine access-list konfiguriert. Diese hat die Aufgabe zu definieren, welcher Traffic von der Niederlassung Berlin überhaupt in den IPSEC-Tunnel geschickt werden soll.
Es kann ja sein dass nur bestimmter Traffic (z. B. vom Netz 20.20.20.0/24) in den Tunnel geschickt werden soll und anderer Traffic nicht.
Im Beispiel wollen wir dass der gesamte Traffic der vom Berliner Netz an das Tokio Ziel-Netz 3.3.3.0/30 addressiert ist, in den Tunnel geschickt wird, und umgekehrt (Traffic von Tokio nach Berlin soll auch in den Tunnel geschickt werden).
Wir müssen eine "extended" ACL verwenden. Mit "standard" ACLs funktioniert das nicht.
ACL-Bereich ("interesting traffic") von NAT ausklammern
Nun benötigen wir eine NAT-Regel Traffic die den "interesting traffic"-Bereich vom NAT ausklammert.
PIXen brauchen per Design für jede Verbindung eine NAT-Regel, wenn "nat-control" aktiviert ist).
Wenn wir nat-control sowieso abgeschaltet haben (mit Befehl "no nat-control") können wir diesen Schritt auch überspringen.
So konfigurieren wir auch die PIX-TOKIO
"Transform-Set"
Das Transform-Set definiert die Verschlüsselungs-Algorithmen die wir für unseren Tunnel verwenden wollen. Man kann mehrere Algorithmen aufführen, die zwei VPN-Partner werden in dem Fall aushandeln auf welche der Verschlüsselungs-Varianten sie sich einigen wollen. Man kann jedoch auch nur eine Variante definieren - diese muss dann aber auch der VPN-Partner kennen und können, sonst wirds nix mit dem VPN-Tunnel! Wir wählen im Beispiel die Variante "AES 256bit Verschlüsselung".
Nun müssen wir eine so genannte "CRYPO-MAP" konfigurieren.
Die Crypto-Map ist die Summe der Parameter die man für den Tunnel verwenden möchte.
Die Crypto-Map beinhaltet das oben definierte Transform-Set, die Peer IP-Adressen, crypto ACL, PFS und die SA-spezifische Lifetime.
Die Crypto-Map wird zu guter Letzt an das Interface gebunden, das als Tunnel-Endpunkt dienen soll.
PIX-1 (BERLIN)
PIX-1(config)#sysopt connection permit-vpn
PIX-1(config)#isakmp enable outside
PIX-1(config)#isakmp policy 10 encryption des
PIX-1(config)#isakmp policy 10 hash sha
PIX-1(config)#isakmp policy 10 authentication pre-share
PIX-1(config)#isakmp policy 10 group 5
PIX-1(config)#isakmp policy 10 lifetime 86400
PIX-1(config)#tunnel-group 2.2.2.2 type ipsec-l2l
PIX-1(config)#tunnel-group 2.2.2.2 ipsec-attributes
PIX-1(config-tunnel-ipsec)#pre-shared-key pa55w0rd
PIX-1(config-tunnel-ipsec)#exit
PIX-1(config)#access-list 111 permit ip 1.1.1.0 255.255.255.252 3.3.3.0 255.255.255.252
PIX-1(config)#access-list 111 permit icmp 1.1.1.0 255.255.255.252 3.3.3.0 255.255.255.252
PIX-1(config)#nat (inside) 0 access-list 111
PIX-1(config)#crypto ipsec transform-set TFS esp-aes-256
PIX-1(config)#crypto map MAP 10 match address 111
PIX-1(config)#crypto map MAP 10 set peer 2.2.2.2
PIX-1(config)#crypto map MAP 10 set transform-set TFS
PIX-1(config)#crypto map MAP 10 set security-association lifetime seconds 86400
PIX-1(config)#crypto map MAP 10 set pfs group5
PIX-1(config)#crypto map MAP interface OUTSIDE
PIX-2 (TOKIO)
PIX-2(config)#sysopt connection permit-vpn
PIX-2(config)#isakmp enable outside
PIX-2(config)#isakmp policy 10 encryption des
PIX-2(config)#isakmp policy 10 hash sha
PIX-2(config)#isakmp policy 10 authentication pre-share
PIX-2(config)#isakmp policy 10 group 5
PIX-2(config)#isakmp policy 10 lifetime 86400
PIX-2(config)#tunnel-group 2.2.2.1 type ipsec-l2l
PIX-2(config)#tunnel-group 2.2.2.1 ipsec-attributes
PIX-2(config-tunnel-ipsec)#pre-shared-key pa55w0rd
PIX-2(config-tunnel-ipsec)#exit
PIX-2(config)#access-list 111 permit ip 3.3.3.0 255.255.255.252 1.1.1.0 255.255.255.252
PIX-2(config)#access-list 111 permit icmp 3.3.3.0 255.255.255.252 1.1.1.0 255.255.255.252
PIX-2(config)#nat (inside) 0 access-list 111
PIX-2(config)#crypto ipsec transform-set TFS esp-aes-256
PIX-2(config)#crypto map MAP 10 match address 111
PIX-2(config)#crypto map MAP 10 set peer 2.2.2.1
PIX-2(config)#crypto map MAP 10 set transform-set TFS
PIX-2(config)#crypto map MAP 10 set security-association lifetime seconds 86400
PIX-2(config)#crypto map MAP 10 set pfs group 5
PIX-2(config)#crypto map MAP interface OUTSIDE
Es ist völlig normal dass die Konfiguration nicht auf Anhieb klappen wird.
Beim Troubleshooting muss man systematisch vorgehen.
1. Ist OHNE VPN Konfiguration eine Verbindung zwischen den zwei PIXen gegeben? Testen mit Ping.
2. Kann Router-1 den Router-2 pingen? Wenn nicht, Routen checken mit "show ip route"
3. VPN Troubleshooting:
Im Cisco PIX und ASA Firewall Workshop Teil 1 - Basiskonfiguration haben wir uns das Security Konzept der Cisco Security Appliances angesehen sowie eine Basiskonfiguration erstellt.
Heute gehts darum, eine IPSEC Verbindung von Berlin nach Tokio zu konfigurieren.
Eine Berliner Firma hat eine Niederlassung in Tokio und möchte diese per IPSEC an ihr Berliner Firmen-LAN koppeln. Dazu sollen zwei Cisco PIX Firewalls verwendet werden, die ideal geeignet sind um Firmenniederlassungen per IPSEC Tunnel miteinander zu verbinden.
Inhaltsverzeichnis
Testlab
Wie man die Interfaces der Komponenten konfiguriert haben wir bereits im ersten Teil unseres PIX/ASA Tutorials gesehen.
IP-Konfiguration Testlab
Router BERLIN (Router-1)
interface FastEthernet1/0
ip address 1.1.1.1 255.255.255.252
no shutdownRouter TOKIO (Router-2)
interface FastEthernet1/0
ip address 3.3.3.1 255.255.255.252
no shutdownPIX Firewall BERLIN (PIX-1)
interface Ethernet0
nameif INSIDE
security-level 100
ip address 1.1.1.2 255.255.255.252
!
interface Ethernet1
nameif OUTSIDE
security-level 0
ip address 2.2.2.1 255.255.255.252PIX Firewall TOKIO (PIX-2)
interface Ethernet1
nameif INSIDE
security-level 100
ip address 3.3.3.2 255.255.255.252
!
interface Ethernet0
nameif OUTSIDE
security-level 0
ip address 2.2.2.2 255.255.255.252Routing Konfiguration
Router BERLIN (Router-1)
router-1(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.2Router TOKIO (Router-2)
router-2(config)#ip route 0.0.0.0 0.0.0.0 3.3.3.2PIX Firewall BERLIN (PIX-1)
pix-1(config)#route outside 0.0.0.0 0.0.0.0 2.2.2.2PIX Firewall TOKIO (PIX-2)
pix-2(config)#route outside 0.0.0.0 0.0.0.0 2.2.2.1ICMP (PING) erlauben
Damit wir die Konnektivität testen können schalten wir ICMP frei.
Die PIX blockiert ja per default ICMP Pakete, bzw. die ICMP Reply Pakete (Antwortpakete auf Ping Anfragen) werden per default am OUTSIDE Interface der PIX blockiert.
Um PING Tests machen zu können müssen wir entsprechende access-listen schreiben und die ACLs an die Interface binden damit sie wirken können.
Wenn man nur einen einzelnen PC freischalten will kann man auch "host <ip-adress>" verwenden.
Die access-list synthax:
access-list <NAME> <permit oder deny> <protokoll> <quell-ip> <quell-maske> <ziel-ip> <ziel-maske> eq <Port>oder wenn man nur einzelne IPs freischalten will...
access-list <NAME> <permit oder deny> <protokoll> host <quell-ip> host <ziel-ip> PIX-BERLIN
PIX-1(config)# access-list OUTSIDE_IN permit icmp host 2.2.2.2 host 2.2.2.1
PIX-1(config)#interface ethernet 1
PIX-1(config-if)# access-group OUTSIDE_IN in interface OUTSIDEPIX-TOKIO
PIX-2(config)# access-list OUTSIDE_IN permit icmp host 2.2.2.1 host 2.2.2.2
PIX-2(config)#interface ethernet 0
PIX-2(config-if)# access-group OUTSIDE_IN in interface OUTSIDENun können wir testen ob der Ping von PIX1 zu PIX2 funktioniert.
pix-1(config)# ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 30/40/50 msWenn ping nicht funktioniert, kann es sein dass das Interface noch nicht hochgefahren wurde!
Das testet man mit Befehl
PIX-TOKIO# show interface
Interface Ethernet1 "OUTSIDE", is up, line protocol is up Wenn das Interface nicht hochgefahren wäre, würde man folgende Ausgabe sehen:
Interface Ethernet1 "OUTSIDE", is administratively down, line protocol is up Konfiguration IPSEC Site-to-Site Tunnel
Nun gehts ans Eingemachte.
Wir wollen zwischen den PIXen PIX-BERLIN und PIX-Tokio einen IPSEC Tunnel einrichten.
IPSEC ist eine Protokoll-Suite die im wesentlichen aus 2 Phasen besteht.
IKE Phase 1 und IKE Phase2.
IKE Phase 1 dient grob gesagt dazu einen sicheren Verbindungskanal zum VPN-Partner aufzubauen.
Über diesen sicheren (weil verschlüsselten) Kanal werden dann die Parameter für IKE Phase 2 ausgetauscht. Die zwei VPN Partner einigen sich auf Verschüsselungsalgorithmuy, Hash-Algorithmus sowie Lifetime Parametern (wie lange der ausgehandelte Sessionkey gültig sein soll) usw.
Zunächst mal konfigurieren wir die PIXen so, dass sie IPSEC Traffic unabhängig von bestehenden ACLs nicht blocken sollen.
PIX-1(config)#sysopt connection permit-vpnPIX-2(config)#sysopt connection permit-vpnKonfiguration access-list für "interesting traffic"
Zunächst wird eine access-list konfiguriert. Diese hat die Aufgabe zu definieren, welcher Traffic von der Niederlassung Berlin überhaupt in den IPSEC-Tunnel geschickt werden soll.
Es kann ja sein dass nur bestimmter Traffic (z. B. vom Netz 20.20.20.0/24) in den Tunnel geschickt werden soll und anderer Traffic nicht.
Im Beispiel wollen wir dass der gesamte Traffic der vom Berliner Netz an das Tokio Ziel-Netz 3.3.3.0/30 addressiert ist, in den Tunnel geschickt wird, und umgekehrt (Traffic von Tokio nach Berlin soll auch in den Tunnel geschickt werden).
Wir müssen eine "extended" ACL verwenden. Mit "standard" ACLs funktioniert das nicht.
PIX-1(config)#access-list 111 permit ip 1.1.1.0 255.255.255.252 3.3.3.0 255.255.255.252
PIX-1(config)#access-list 111 permit icmp 1.1.1.0 255.255.255.252 3.3.3.0 255.255.255.252
PIX-1(config)#nat (inside) 0 access-list 111PIX-2(config)#access-list 111 permit ip 3.3.3.0 255.255.255.252 1.1.1.0 255.255.255.252
PIX-2(config)#access-list 111 permit icmp 3.3.3.0 255.255.255.252 1.1.1.0 255.255.255.252
PIX-2(config)#nat (inside) 0 access-list 111ACL-Bereich ("interesting traffic") von NAT ausklammern
Nun benötigen wir eine NAT-Regel Traffic die den "interesting traffic"-Bereich vom NAT ausklammert.
PIXen brauchen per Design für jede Verbindung eine NAT-Regel, wenn "nat-control" aktiviert ist).
Wenn wir nat-control sowieso abgeschaltet haben (mit Befehl "no nat-control") können wir diesen Schritt auch überspringen.
PIX-1(config)#nat (INSIDE) 0 access-list 111PIX-2(config)#nat (INSIDE) 0 access-list 111IKE Phase 1 ("ISAKMP") konfigurieren
PIX-1(config)#isakmp enable outside
PIX-1(config)#isakmp policy 10 encryption 3des
PIX-1(config)#isakmp policy 10 hash sha
PIX-1(config)#isakmp policy 10 authentication pre-share
PIX-1(config)#isakmp policy 10 group 5
PIX-1(config)#isakmp policy 10 lifetime 86400So konfigurieren wir auch die PIX-TOKIO
PIX-2(config)#isakmp enable outside
PIX-2(config)#isakmp policy 10 encryption 3des
PIX-2(config)#isakmp policy 10 hash sha
PIX-2(config)#isakmp policy 10 authentication pre-share
PIX-2(config)#isakmp policy 10 group 5
PIX-2(config)#isakmp policy 10 lifetime 86400IKE Phase 2 ("IPSEC") konfigurieren
"Transform-Set"
Das Transform-Set definiert die Verschlüsselungs-Algorithmen die wir für unseren Tunnel verwenden wollen. Man kann mehrere Algorithmen aufführen, die zwei VPN-Partner werden in dem Fall aushandeln auf welche der Verschlüsselungs-Varianten sie sich einigen wollen. Man kann jedoch auch nur eine Variante definieren - diese muss dann aber auch der VPN-Partner kennen und können, sonst wirds nix mit dem VPN-Tunnel! Wir wählen im Beispiel die Variante "AES 256bit Verschlüsselung".
PIX-1(config)#tunnel-group 2.2.2.2 type ipsec-l2l
PIX-1(config)#tunnel-group 2.2.2.2 ipsec-attributes
PIX-1(config-tunnel-ipsec)#pre-shared-key pa55w0rd
PIX-1(config-tunnel-ipsec)#exit
PIX-1(config)#crypto ipsec transform-set TFS esp-aes-256PIX-2(config)#tunnel-group 2.2.2.1 type ipsec-l2l
PIX-2(config)#tunnel-group 2.2.2.1 ipsec-attributes
PIX-2(config-tunnel-ipsec)#pre-shared-key pa55w0rd
PIX-2(config-tunnel-ipsec)#exit
PIX-2(config)#crypto ipsec transform-set TFS esp-aes-256Konfiguration "Crypto-Map"
Nun müssen wir eine so genannte "CRYPO-MAP" konfigurieren.
Die Crypto-Map ist die Summe der Parameter die man für den Tunnel verwenden möchte.
Die Crypto-Map beinhaltet das oben definierte Transform-Set, die Peer IP-Adressen, crypto ACL, PFS und die SA-spezifische Lifetime.
Die Crypto-Map wird zu guter Letzt an das Interface gebunden, das als Tunnel-Endpunkt dienen soll.
PIX-1(config)#crypto map MAP 10 match address 111
PIX-1(config)#crypto map MAP 10 set peer 2.2.2.2
PIX-1(config)#crypto map MAP 10 set transform-set TFS
PIX-1(config)#crypto map MAP 10 set security-association lifetime seconds 86400
PIX-1(config)#crypto map MAP 10 set pfs group5
PIX-1(config)#crypto map MAP interface OUTSIDEPIX-2(config)#crypto map MAP 10 match address 111
PIX-2(config)#crypto map MAP 10 set peer 2.2.2.1
PIX-2(config)#crypto map MAP 10 set transform-set TFS
PIX-2(config)#crypto map MAP 10 set security-association lifetime seconds 86400
PIX-2(config)#crypto map MAP 10 set pfs group5
PIX-2(config)#crypto map MAP interface OUTSIDEPIX VPN Konfiguration Schnellüberblick
PIX-1 (BERLIN)
PIX-1(config)#sysopt connection permit-vpn
PIX-1(config)#isakmp enable outside
PIX-1(config)#isakmp policy 10 encryption des
PIX-1(config)#isakmp policy 10 hash sha
PIX-1(config)#isakmp policy 10 authentication pre-share
PIX-1(config)#isakmp policy 10 group 5
PIX-1(config)#isakmp policy 10 lifetime 86400
PIX-1(config)#tunnel-group 2.2.2.2 type ipsec-l2l
PIX-1(config)#tunnel-group 2.2.2.2 ipsec-attributes
PIX-1(config-tunnel-ipsec)#pre-shared-key pa55w0rd
PIX-1(config-tunnel-ipsec)#exit
PIX-1(config)#access-list 111 permit ip 1.1.1.0 255.255.255.252 3.3.3.0 255.255.255.252
PIX-1(config)#access-list 111 permit icmp 1.1.1.0 255.255.255.252 3.3.3.0 255.255.255.252
PIX-1(config)#nat (inside) 0 access-list 111
PIX-1(config)#crypto ipsec transform-set TFS esp-aes-256
PIX-1(config)#crypto map MAP 10 match address 111
PIX-1(config)#crypto map MAP 10 set peer 2.2.2.2
PIX-1(config)#crypto map MAP 10 set transform-set TFS
PIX-1(config)#crypto map MAP 10 set security-association lifetime seconds 86400
PIX-1(config)#crypto map MAP 10 set pfs group5
PIX-1(config)#crypto map MAP interface OUTSIDE
PIX-2 (TOKIO)
PIX-2(config)#sysopt connection permit-vpn
PIX-2(config)#isakmp enable outside
PIX-2(config)#isakmp policy 10 encryption des
PIX-2(config)#isakmp policy 10 hash sha
PIX-2(config)#isakmp policy 10 authentication pre-share
PIX-2(config)#isakmp policy 10 group 5
PIX-2(config)#isakmp policy 10 lifetime 86400
PIX-2(config)#tunnel-group 2.2.2.1 type ipsec-l2l
PIX-2(config)#tunnel-group 2.2.2.1 ipsec-attributes
PIX-2(config-tunnel-ipsec)#pre-shared-key pa55w0rd
PIX-2(config-tunnel-ipsec)#exit
PIX-2(config)#access-list 111 permit ip 3.3.3.0 255.255.255.252 1.1.1.0 255.255.255.252
PIX-2(config)#access-list 111 permit icmp 3.3.3.0 255.255.255.252 1.1.1.0 255.255.255.252
PIX-2(config)#nat (inside) 0 access-list 111
PIX-2(config)#crypto ipsec transform-set TFS esp-aes-256
PIX-2(config)#crypto map MAP 10 match address 111
PIX-2(config)#crypto map MAP 10 set peer 2.2.2.1
PIX-2(config)#crypto map MAP 10 set transform-set TFS
PIX-2(config)#crypto map MAP 10 set security-association lifetime seconds 86400
PIX-2(config)#crypto map MAP 10 set pfs group 5
PIX-2(config)#crypto map MAP interface OUTSIDE
VPN Fehlersuche
Es ist völlig normal dass die Konfiguration nicht auf Anhieb klappen wird.
Beim Troubleshooting muss man systematisch vorgehen.
1. Ist OHNE VPN Konfiguration eine Verbindung zwischen den zwei PIXen gegeben? Testen mit Ping.
2. Kann Router-1 den Router-2 pingen? Wenn nicht, Routen checken mit "show ip route"
3. VPN Troubleshooting:
- show run
- show running-config tunnel-group
- show running-config crypto
- show crypto isakmp sa
- show ipsec sa
- debug crypto isakmp 7 (Zeigt in Echtzeit an wie der VPN Tunnel aufgebaut wird, IKE Phase1)
- debug crypto ipsec 7 (Zeig in Echtzeit IKE Phase 2 an)
- no debug crypto isakmp (Nach Fehlersuche wieder debug abschalten!)
- no debug crypto ipsec (Nach Fehlersuche wieder debug abschalten!)
- packet-tracer als analyse-tool einsetzen
pix-1(config)# packet-tracer input INSIDE icmp 1.1.1.1 1 1 3.3.3.1
Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 OUTSIDE
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 141, packet dispatched to next module
Phase: 7
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 136, using existing flow
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: allow
pix-1(config)#Gängige Fehler VPN Konfiguration
- alte Konfigurations- oder Test-Überbleibsel stören den VPN Aufbau
- Falsches Pre-Shared Passwort
- Parameter-Werte der beiden Peers weichen voneinander ab (Lifetime, Verschlüsselungsvariante, Hash-Variante)
- Peer-IP-Adressen falsch gesetzt
- kein VPN Traffic erlaubt "sysopt connection permit-vpn"
- ACL für "interesting traffic" falsch konfiguriert
- NAT Regeln verhindern VPN Aufbau "nat (INSIDE) 0 access-list 111" oder "no nat-control"
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 89184
Url: https://administrator.de/contentid/89184
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
11 Kommentare
Neuester Kommentar
PIX-1(config)#tunnel-group 2.2.2.2 type ipsec-l2l
PIX-1(config)#tunnel-group 2.2.2.2 ipsec-attributes
PIX-1(config-tunnel-ipsec)#pre-shared-key pa55w0rd
PIX-1(config-tunnel-ipsec)#exit
PIX-1(config)#tunnel-group 2.2.2.2 ipsec-attributes
PIX-1(config-tunnel-ipsec)#pre-shared-key pa55w0rd
PIX-1(config-tunnel-ipsec)#exit
Hallo,
ich habe eine Frage zu dem Site-to-Site Lab.
Wir haben auf den einen Site eine Pix 501, die Version 6.3(5) hat.
Wie nenne ich unserer Pix 501 die tunnel-group und das pre-shared password ?
Andere Site ist eine Pix 515 E, da passen die Kommandos.
Gruss Roland
Bei 6.3 weiss ich nicht - prinzipiell ist die tunnel-group eine Zahl, wenn man pre-shared key benutzt.
Z. B.
tunnel-group 10 type ipsec-l2l
Will man Namen benutzen (z. B. tunnel-group MyTunnelGroup) geht das nur wenn man RSA statt Pre-Shared-Key benutzt (Zertifikate).
Man kann jedoch die IP-Adresse benutzen (statt namen) wenn man pre-shared key benutzen will, wi eim Beispiel.
tunnel-group 2.2.2.2 type ipsec-l2l (l2l bedeutet lan-to-lan bzw. site-to-site).
Ich denke wenn du eine Zahl verwendest (z. B. tunnel-group 10) kannst nicht viel falsch machen...
So ich schmeiss jez den Grill an bevors wieder regnet. ### Wetter aber auch!
Z. B.
tunnel-group 10 type ipsec-l2l
Will man Namen benutzen (z. B. tunnel-group MyTunnelGroup) geht das nur wenn man RSA statt Pre-Shared-Key benutzt (Zertifikate).
Man kann jedoch die IP-Adresse benutzen (statt namen) wenn man pre-shared key benutzen will, wi eim Beispiel.
tunnel-group 2.2.2.2 type ipsec-l2l (l2l bedeutet lan-to-lan bzw. site-to-site).
Ich denke wenn du eine Zahl verwendest (z. B. tunnel-group 10) kannst nicht viel falsch machen...
So ich schmeiss jez den Grill an bevors wieder regnet. ### Wetter aber auch!
Morgen,
mein Problem ist, dass unsere kleine Pix 501 die "tunnel-group" nicht kennt.
Gruss Roland
gute Idee
mein Problem ist, dass unsere kleine Pix 501 die "tunnel-group" nicht kennt.
Gruss Roland
So ich schmeiss jez den Grill an bevors wieder regnet. ### Wetter aber auch!
gute Idee
Wie wärs mit nem PIX Upgrade auf 8.3?
6.X ist ja schon ne ganze Weile her...
6.X ist ja schon ne ganze Weile her...
Wie wärs mit nem PIX Upgrade auf 8.3?
gute Idee, aber wir haben keinen Account auf der Cisco Site. Cisco will da heute richtig Kohle für...
Gruss Roland
Tja, nix ist umsonst.
Selbst wenn du dir ein 8.3 irgendwo besorgst, wirds IPSEC ohne Activation Key nicht funktionieren, und das ist an die Hardware gebunden..
Selbst wenn du dir ein 8.3 irgendwo besorgst, wirds IPSEC ohne Activation Key nicht funktionieren, und das ist an die Hardware gebunden..
bin gerade dabei uns einen Cisco Accont einzurichten.
Unser Händler hat schon die Seriennummern der Pixen.
Kostet natürlich Geld, ist aber vertretbar und macht Sinn.
Gruss Roland
Unser Händler hat schon die Seriennummern der Pixen.
Kostet natürlich Geld, ist aber vertretbar und macht Sinn.
Gruss Roland
Wird vermutlich sowieso nicht mehr aktuell sein, aber PIX 501, 506E und 520 unterstützen keine SW > 6.3
Wird vermutlich sowieso nicht mehr aktuell sein, aber PIX 501, 506E und 520 unterstützen > keine SW > 6.3
ich danke für die Antwort.
Hatte es allerdings inzwischen schon selber in Erfahrung gebracht
Gruss Roland
Wird es auch bald ein "Cisco PIX und ASA Workshop Teil 3" geben?! Hinsichtlich Remote Access VPN!?!
Genau wie im Teil 1 Outside / Inside Interface mit öffentlichen IPs... Danke
Erstmal Lob an die ersten beiden Teile...
Genau wie im Teil 1 Outside / Inside Interface mit öffentlichen IPs... Danke
Erstmal Lob an die ersten beiden Teile...
Kinder, wie die Zeit vergeht!
Ne, nen Teil 3 wirds wohl nicht geben.
Für Remote Access nimmt man Juniper SSL-VPN.
Und das ist so einfach, da braucht man keine Anleitung. Hehe.
Ne, nen Teil 3 wirds wohl nicht geben.
Für Remote Access nimmt man Juniper SSL-VPN.
Und das ist so einfach, da braucht man keine Anleitung. Hehe.
