cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
777
Views
0
Helpful
5
Replies

Issue with Remote access VPN

Martijn de Loos
Level 1
Level 1

Hello,

I have setup a Remote access VPN on my ASA5505 firewall through the ASDM wizard.

I can succesfully connect with the Cisco VPN client. My firewall also shows me the VPN session and shows incoming Rx packets. However, Tx packets remain 0, so no traffic is going out. My ASA5505 is configured as router on a stick with 25 different VLAN's. I want to restrict traffic to one specific VLAN using a crypto map.

When I issue a ping -t command on my connected Windows box, the firewall log shows me the following message:

"IKE Initiator unable to find policy: Intf outside, Src: 10.7.11.18, Dst: 172.16.1.1."

"This message indicates that the IPSec fast path processed a packet that triggered IKE, but IKE's policy lookup failed. This error could be timing related. The ACLs that triggered IKE might have been deleted before IKE processed the initiation request. This problem will most likely correct itself."

Unfortunately, the problem doesn't correct itself...

The "sh cry isa sa" and "sh cry ips sa" commands show the following output:

2   IKE Peer: 62.140.137.99

Type    : user            Role    : responder

Rekey   : no              State   : AM_ACTIVE

interface: outside

Crypto map tag: SYSTEM_DEFAULT_CRYPTO_MAP, seq num: 65535, local addr: 85.17.xxx.xxx (outside interface IP)

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/0/0)

current_peer: 62.140.137.99, username: eclipsevpn

dynamic allocated peer ip: 172.16.1.1

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

#pkts decaps: 4351, #pkts decrypt: 4351, #pkts verify: 4351

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: 85.17.xxx.xxx/4500, remote crypto endpt.: 62.140.137.99/3698

path mtu 1500, ipsec overhead 82, media mtu 1500

current outbound spi: B3D60F71

current inbound spi : B89BA14A

inbound esp sas:

spi: 0xB89BA14A (3097207114)

transform: esp-aes esp-sha-hmac no compression

in use settings ={RA, Tunnel,  NAT-T-Encaps, }

slot: 0, conn_id: 196608, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP

sa timing: remaining key lifetime (sec): 25126

IV size: 16 bytes

replay detection support: Y

Anti replay bitmap:

0xFFFFFFFF 0xFFE1FFF8

outbound esp sas:

spi: 0xB3D60F71 (3017150321)

transform: esp-aes esp-sha-hmac no compression

in use settings ={RA, Tunnel,  NAT-T-Encaps, }

slot: 0, conn_id: 196608, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP

sa timing: remaining key lifetime (sec): 25126

IV size: 16 bytes

replay detection support: Y

Anti replay bitmap:

0x00000000 0x00000001

I have really no idea what's going on. I have setup a Remote access VPN countless times but this time it shows me the error as described above.

1 Accepted Solution

Accepted Solutions

Herbert Baerten
Cisco Employee
Cisco Employee

Hi Martijn,

just a few quick thoughts:

- is your NAT exemption ok, i.e. make sure that the return traffic is not being NAT'ed.

- make sure there are no overlapping crypto ACL's

- when connected, do a packet tracer to see what happens with the return packets.

e.g.

packet-tracer in interface inside icmp 10.7.11.18 0 0 172.16.1.1 detail

(where is the name of the interface on which 10.7.11.18 resides)

This will show you all the steps the packet goes through internally (routing, nat, encryption etc) so it should give you an idea of what happens to it, e.g. if it hits the wrong interface, wrong nat rule,  wrong crypto map entry etc.

hth

Herbert

View solution in original post

5 Replies 5

Herbert Baerten
Cisco Employee
Cisco Employee

Hi Martijn,

just a few quick thoughts:

- is your NAT exemption ok, i.e. make sure that the return traffic is not being NAT'ed.

- make sure there are no overlapping crypto ACL's

- when connected, do a packet tracer to see what happens with the return packets.

e.g.

packet-tracer in interface inside icmp 10.7.11.18 0 0 172.16.1.1 detail

(where is the name of the interface on which 10.7.11.18 resides)

This will show you all the steps the packet goes through internally (routing, nat, encryption etc) so it should give you an idea of what happens to it, e.g. if it hits the wrong interface, wrong nat rule,  wrong crypto map entry etc.

hth

Herbert

Thank you Herbert! It was the NAT exemption. After correction the tunnel works.

I have one other issue. When I connect to the VPN tunnel, I can access the remote LAN but I have no internet connection anymore. In other words, I am completely isolated except for the remote LAN.

Do you have any idea what this could be?

It sounds like your nat exemption is not only exempting the VPN traffic but all traffic... can you share your nat rules (masking any public ip addresses) ?

Or similarly, run a packet-tracer but for inside-to-internet traffic this time.

hth

Herbert

Hello,

you can also use split tunneling to use VPN access together with internet access in one time.

please see this document:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080975e83.shtml

Regards,

Jan

Jan's response made me realize I probably misinterpreted the new question.

To get internet access on the client, indeed you need to do one of 2 things:

- as Jan said, configure split-tunnel so the internet traffic does not pass through the tunnel

OR

- enable U-turn on the ASA, which includes allowing same-interface traffic and creating a NAT rule for traffic from the VPN pool to the internet

see e.g.

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080972e4f.shtml

https://supportforums.cisco.com/docs/DOC-11640

Herbert