isakmp enable outside
isakmp identity address

isakmp key XXXXXXXXXXXXXXXX address 192.0.1.2

isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 5

access-list ipsecvpn permit ip
  172.16.0.0 255.255.0.0
  172.30.0.0 255.255.0.0 

access-list nonat permit ip
  172.16.0.0 255.255.0.0
  172.30.0.0 255.255.0.0

nat (inside) 0 access-list nonat

crypto ipsec transform-set ts1 esp-3des esp-md5-hmac

crypto map mymap 10 ipsec-isakmp
crypto map mymap 10 match address ipsecvpn
crypto map mymap 10 set peer 192.0.1.2
crypto map mymap 10 set transform-set ts1
crypto map mymap 10 set pfs group5

crypto map mymap interface outside

sysopt connection permit-ipsec

!
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 5
!
crypto isakmp keepalive 3600
!
crypto isakmp key XXXXXXXXXXXXXXXX address 192.0.1.1
!
crypto ipsec transform-set ts1 esp-3des esp-md5-hmac
!
crypto map wan 10 ipsec-isakmp
 description VPN Home - Work
 set peer 192.0.1.1
 set transform-set ts1 
 set pfs group5
 match address work
!
ip access-list extended work
 remark VPN Home - Work
 permit ip 172.30.0.0 0.0.255.255 172.16.0.0 0.0.255.255
!
interface Dialer1
 ...
 crypto map wan

• Re: IPSec von PIX nach IOS
  Geschrieben von Karsten (Link) am Dienstag, 9. Oktober 2007, 20:23
  
  Zwei Anmerkungen:
  1) In den PIX-ACLs ist vermutlich beim copy & paste ein Teil verlorengegangen. Da fehlt die source.
  
  2) Wenn man versucht die größtmögliche Sicherheit herauszuholen (z.B. PFS), dann sollte man doch auch das bessere Hash-Verfahren benutzen (nämlich SHA1).
  
  Und warum habt ihr die PIX gegen eine Linux-Box ersetzt?
  
  
  • Re: IPSec von PIX nach IOS
    Geschrieben von Beat Rubischon (Link) am Mittwoch, 10. Oktober 2007, 09:04
    
    1) In den PIX-ACLs ist vermutlich beim copy & paste ein Teil verlorengegangen. Da fehlt die source.
    
    Tatsächlich. Da ist beim Verstecken der echten IPs noch etwas mehr verlorengegangen... Habe den Artikel korrigiert.
    
    2) Wenn man versucht die größtmögliche Sicherheit herauszuholen (z.B. PFS), dann sollte man doch auch das bessere Hash-Verfahren benutzen (nämlich SHA1).
    
    Ich überege mir gerade, warum ich da md5 benutzt habe. Sicherlich spielte eine Rolle, dass mich die existierenden Ansätze zum Aushebeln von md5 nicht wirklich erschreckt haben - andererseits habe ich eine dumpfe Erinnerung, dass ein früher IOS Release für meinen 836er kein sha1 im Griff hatte.
    
    Kurzerhand habe ich von md5 nach sha1 umgestellt und der Cisco ist happy. Das ist also definitiv kein Problem.
    
    Bei der Encryption bin ich jedoch auf 3des beschränkt. Der Cryptochip im 836er kann kein aes256 und die CPU ist zu schlapp als dass sie das in Software machen könnte.
    
    Und warum habt ihr die PIX gegen eine Linux-Box ersetzt?
    
    Das Ding hatte noch Version 6 drauf. Ein Upgrade - um überhaupt wieder Sicherheitsmässig up to date zu sein - hätte mehr Memory und eine neue Softwarelizenz gekostet.
    
    Linux Know How war vorhanden, genauso wie Wünsche nach mehreren Default Routen je nach Protokoll. Sicher auch das alles mit IOS oder dem PIX OS machbar, hätte aber massiv grösseren Aufwand bedeutet.
    
    Aktuell hat die Box zwei Uplinks (10MBit Fibre, 10MBit Cable), zwei DMZs mit separaten IP Ranges und Policies, ein LAN, mehrere IPsec LAN Interconnects, einen bald obsoleten cipe Tunnel und einen OpenVPN Server für Road Warriors. Ein Postfix filtert Mails aufgrund gültiger Adressen im AD. Eine Spinne im Netz, die sicherlich an mich als Person gebunden ist - auf die andere Seite aber auch vier separate Boxen konsolidert hat.