1721 VPN config problem

Phil Smith · ‎10-10-2012

I am having a problem configuring a VPN connection from a 1721 router to an ASA5520.

The router has already been configured, but I have been asked to setup the VPN.

I think the issue is because they are using a Loopback interface (which I have never configured for before).

The "sh crypto isakmp sa" command shows:

dst src state conn-id status

5.6.7.8 1.2.3.4 QM_IDLE 4 ACTIVE

where 5.6.7.8 is the ip on Loopback0, 1.2.3.4 is remote peer ip.

Pings to the remote network don't work.

Here is the (slightly edited) config of the 1721 . . .

---------------------------------------

Current configuration : 3838 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname 1721

!

boot-start-marker

boot-end-marker

!

no logging buffered

enable secret 5 dummy

!

no aaa new-model

ip cef

!

ip auth-proxy max-nodata-conns 3

ip admission max-nodata-conns 3

!

username dummy privilege 15 password 0 dummy

!

crypto isakmp policy 10

encr 3des

hash md5

authentication pre-share

lifetime 28800

crypto isakmp key dummy-key address 1.2.3.4

!

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

!

crypto map mymap local-address Loopback0

!

crypto map myumap 10 ipsec-isakmp

set peer 1.2.3.4

set security-association lifetime seconds 28800

set transform-set myset

match address 120

!

interface Loopback0

ip address 5.6.7.8 255.255.255.240

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly

!

interface FastEthernet0

ip address 192.168.1.1 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

ip virtual-reassembly

speed auto

!

interface Serial0

no ip address

no ip proxy-arp

ip nat outside

ip virtual-reassembly

encapsulation frame-relay IETF

no fair-queue

frame-relay lmi-type cisco

!

interface Serial0.1 point-to-point

ip address 5.6.9.1 255.255.255.252

ip nat outside

ip virtual-reassembly

frame-relay interface-dlci 297 IETF

crypto map mymap

!

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 Serial0.1

!

ip http server

ip http authentication local

ip http secure-server

ip nat inside source route-map nonat interface Loopback0 overload

!

access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 130 deny ip 192.168.1.0 0.0.0.225 192.168.2.0 0.0.0.255

access-list 130 permit ip 192.168.1.0 0.0.0.255 any

!

route-map nonat permit 10

match ip address 130

!

control-plane

!

line con 0

line aux 0

line vty 0 4

exec-timeout 40 0

privilege level 15

password dummy

login local

transport input telnet ssh

!

end

1721#

------------------------------

Phil Smith · ‎10-10-2012

sorry, typo in crypto map name above. It is actually mymap, not myumap.

John Blakley · ‎10-10-2012

Phil,

Does your ASA have a route to the 192.168.1.0 network?

HTH, John *** Please rate all useful posts ***

Phil Smith · ‎10-10-2012

Yes, the ASA is showing the tunnel as up, but it shows no RX packets, only TX.

cadet alain · ‎10-10-2012

Hi,

post sh crypto ipsec sa output from 1721.

Regards.

Alain

Don't forget to rate helpful posts.

Phil Smith · ‎10-10-2012

Researching this, I have just seen a sample config where the crypto map is applied to the Loopback interface, not the physical interface. Could this be the issue? I thought the crypto map needed to be applied to the physical interface.

Phil Smith · ‎10-10-2012

sh crypto ipsec sa # (edited with dummy ip addresses)

interface: Loopback0

Crypto map tag: mymap, local addr 5.6.7.8

protected vrf: (none)

local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)

current_peer 1.2.3.4 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

#pkts decaps: 3446, #pkts decrypt: 3446, #pkts verify: 3446

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 5.6.7.8, remote crypto endpt.: 1.2.3.4

path mtu 1514, ip mtu 1514, ip mtu idb Loopback0

current outbound spi: 0x6F9DD475(1872614517)

inbound esp sas:

spi: 0x43384E3B(1127763515)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

conn id: 2001, flow_id: C1700_EM:1, crypto map: mymap

sa timing: remaining key lifetime (k/sec): (4459465/26811)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0x6F9DD475(1872614517)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

conn id: 2002, flow_id: C1700_EM:2, crypto map: mymap

sa timing: remaining key lifetime (k/sec): (4459842/26811)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

outbound ah sas:

outbound pcp sas:

1721#

cadet alain · ‎10-10-2012

Hi,

ok so you are not encapsulating nor encrypting packet on your side but receiving ones from asa which correlates the fact that asa sees only transmitted packets but none received.

Now indeed doing the vpn tunnel on physical interface should solve the problem but why was it decided to use the loopback ?

Regards.

Alain

Don't forget to rate helpful posts.

Phil Smith · ‎10-10-2012

Its a bit complicated.

The router is at an "agents" site. They own and run the router, but need a vpn connection into our central network, for access to one of our servers.

They tried to configure it, but it didn't connect, so they asked if I could sort the vpn connection for them.

So, the config is "as was". I am now thinking it may be a routing issue on the 1721. If I can't get it sorted, then I will check if I can config without the loopback.