February 6, 2012

Studies in VPN: Part 3

IOS Lan-to-Lan with PSK through an ASA. ***The Catch: Nat configured and Dynamic Crypto Maps configured.

Picture 8 Uploaded with plasq‘s Skitch!

I ran into an Intersting situation:

r1#sh cry map
Crypto Map "vpn" 10 ipsec-isakmp
    Peer = 136.5.122.2
    Extended IP access list r1tor2
        access-list r1tor2 permit ip 150.1.1.0 0.0.0.255 150.2.2.0 0.0.0.255
    Current peer: 136.5.122.2
    Security association lifetime: 4608000 kilobytes/3600 seconds
    PFS (Y/N): N
    Transform sets={
        3des-esp,
    }
    Interfaces using crypto map vpn:
        FastEthernet0/0
Pings fail:
r1#ping 150.2.2.2 source l0

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.2.2.2, timeout is 2 seconds: Packet sent with a source address of 150.1.1.1 ..... Success rate is 0 percent (0/5)

But it looks like its working based on the stats:
local  ident (addr/mask/prot/port): (150.1.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (150.2.2.0/255.255.255.0/0/0)
   current_peer: 136.5.122.2:4500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 29, #pkts encrypt: 29, #pkts digest 29
    #pkts decaps: 19, #pkts decrypt: 19, #pkts verify 19
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

 local crypto endpt.: 136.5.121.1, remote crypto endpt.: 136.5.122.2
 path mtu 1500, media mtu 1500
 current outbound spi: 674293ED

 inbound esp sas:
  spi: 0xBD012AAD(3170970285)
    transform: esp-3des esp-md5-hmac ,
    in use settings ={Tunnel UDP-Encaps, }
    slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn
    sa timing: remaining key lifetime (k/sec): (4590553/3219)
    IV size: 8 bytes
    replay detection support: Y

 inbound ah sas:

 inbound pcp sas:

 outbound esp sas:
  spi: 0x674293ED(1732416493)
    transform: esp-3des esp-md5-hmac ,
    in use settings ={Tunnel UDP-Encaps, }
    slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn
    sa timing: remaining key lifetime (k/sec): (4590551/3219)
    IV size: 8 bytes
    replay detection support: Y

 outbound ah sas:

 outbound pcp sas:

r1#

A little tweaking on the ASA, clear the ASA and try again:
r1#clear cry sa
r1#
r1#
r1#sh cry isa sa
dst             src             state          conn-id slot
136.5.122.2     136.5.121.1     MM_NO_STATE          1    0 (deleted)

r1#ping 150.2.2.2 source l0

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.2.2.2, timeout is 2 seconds: Packet sent with a source address of 150.1.1.1 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 8/9/12 ms r1#sh cry isa sa dst src state conn-id slot 136.5.122.2 136.5.121.1 QM_IDLE 2 0 136.5.122.2 136.5.121.1 MM_NO_STATE 1 0 (deleted)

r1#

So what was the problem? Access-list on the ACL didn’t allow NAT-T.

On another note the interesting thing about this configuration is that you have to initiate the connection from the inside since R2 is using a dynamic crypto map.

Final Configs (zipped)

Static Route Tracking with ASA 8.x

For a few days now I have been playing with static route tracking in my SNAF class.  The class is running ASA 8.0 (2).  After reading every document I can find and testing in my lab I have concluded that version 8.0 (2) does not work.  Now I can’t find a bug report on it, but i tested it over and over again.

Finally I decided to upgrade to code 8.0 (3).  Success!  Below is what I did to test and the results:

To begin, here is the topology:

static route tracking
Uploaded with plasq‘s Skitch!

First I set up the interfaces:

interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 192.168.6.2 255.255.255.0
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.0.6.1 255.255.255.0
!
interface GigabitEthernet0/2
nameif backup
security-level 0
ip address 192.168.5.25 255.255.255.0
!
[Read more...]

Are you a Cisco Reseller?

I found an interesting article that may give Cisco Resellers a glimmer of hope if they feel they have been given unfair treatment.

In the article, the company “Infra-Comm” is suing based on a claim that Cisco gave a 5-million dollar deal to AT&T. Here is what the judge says:

..the judge found three provisions in Cisco’s ICPA unconscionable: that the partner is not provided with an opportunity to negotiate the terms of the contract when using Cisco’s Web site to renew contracts; that Cisco could terminate a reseller agreement with only a month’s notice, or without notice at the beginning of each year; and that the ICPA limits damages to what a reseller pays Cisco over the course of three months for services and products, which could be unfair to longtime resellers. -Network World Article