ASA Tunnel config.

[Chris McCann]

Hi Folks,

I have an ASA (8.3) and I am attempting to create a VPN tunnel to another off site device. The tunnel looks to be coming up ok (viewing via the ASDM) but wont pass traffice. I have done a packet-tracer and getting the following error.

(rpf-violated) Reverse-path verify failed

From what I have read it could be 'NAT' causeing problems. Do I really need to NAT for tunnels ?

Any help appreciated.

C.

[Marius Gunnerud]

You do not NAT traffic that is going into a tunnel, unless you have a specific reason for doing so, but you do need to prevent the VPN traffic from being NAT-ed.  So, yes you do need NAT configuration for the VPN traffic stating that it is not to be NAT-ed or to keep its current source IP and not be NAT-ed to the public IP...if that makes sense.

depending on what type of tunnel this is (site2site or remote access) you need to issue the packet tracer twice, if the tunnel is not already established.  This is in the case of site2site tunnels.  The first packet tracer brings the tunnel up and the second trace will show the correct results.  As for remote access connections, this can not be tested using packet tracer unless the remote client is already connected.

To help you further we would need to know what type of tunnel it is you are trying to set up, and what the remote device is (some devices requires that the ASA and/or the remote device has some special config to be able to establish a connection).  Also if you could post a full running configuration (sanitized) that will help us in deciphering if there is a configuration issue.

--

Please remember to rate and select a correct answer
 

[Chris McCann]

Hi Marius,

Thanks for the info, here is some of the config

crypto map outside_map 5 match address outside_cryptomap_3
crypto map outside_map 5 set pfs group1
crypto map outside_map 5 set peer xxx.xxx.xxx.xxx
crypto map outside_map 5 set transform-set ESP-AES-256-MD5 ESP-AES-256-SHA ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-DES-SHA ESP-DES-MD5 ESP-3DES-MD5 ESP-3DES-SHA

ciscoasa# sh access-list outside_cryptomap_3
access-list outside_cryptomap_3; 2 elements; name hash: 0x4c48cff2
access-list outside_cryptomap_3 line 1 extended permit ip object-group DM_INLINE_NETWORK_40 192.168.0.0 255.255.255.0 0xe461e16f
access-list outside_cryptomap_3 line 1 extended permit ip mainsiteinternaladdress 192.168.0.0 255.255.255.0 (hitcnt=44) 0x7e977ff3

The remote site uses range 192.168.0.0 /24

Looking at the above the tunnel looks like its coming up, hitcnt=44, also I am using the asdm logging and that indicates that the Phase1&2 come up ok, I can see the keepalives.

The router on the external site is a craddlepoint MD1400, config looks straight forward on it.

object-group network DM_INLINE_NETWORK_40 begin our internal address range.

Any help appreciated.

[Marius Gunnerud]

Well to confirm that the tunnel is coming up you can issue the following command:

show crytpo ikev1 isakmp sa

or

show crypto isakmp sa

Depending on the version ASA you are running it will be one of the two.  If you are using ikev2 then you need to replace the ikev1 with ikev2.  If you see the connection as QM_IDLE or MM_IDLE, again depending on if you are using Quick Mode or Main Mode, that means the tunnel is up.  If it is not up then try to send some traffic over the tunnel in an attempt to bring the tunnel up and then check the show commands again.

If the tunnel shows as up and traffic is not passing, it is most likely either a misconfiguration in either the crypto ACL or NAT at one of the ends...or both for that matter.

Please check to make sure that the tunnel is up as per my above comments.  If the tunnel is up please post the NAT configuration also so we can check that, and then we will have to take a closer look at the Craddlepoint router if it is still not resolved.

--

Please remember to rate and select a correct answer

[Chris McCann]

Hi Marius,

I have the following

48  IKE Peer: xxx.xxx.xxx.xxx
    Type    : L2L             Role    : responder
    Rekey   : no              State   : MM_ACTIVE

So I take it Phase1 is good.

We have another tunnel built which works fine, however this does only connect to a device within our DMZ.

There is a lot of config on the firewall, rather than display the entire NAT config is there a simple rule I could put in merely for the relavant addresses (is the peer addresses that are used )

many thanks

[Marius Gunnerud]

Actually, it looks as though there is a mismatch in your phase 1 (MM_Active means it is trying to find a policy match, but is not able to find one).  But to narrow it down further we would need to debug the the VPN connection.

debug crypto isakmp

Although this should not have an affect on your network, it is best to do this in a service window or when there is not much traffic expected on the network.

--

Please remember to rate and select a correct answer

[Chris McCann]

Hi Marius,

Are you sure MM_Active means the connection is incomplete. I am not sure myself but can see plenty of other connections which are working and display MM_Active.

[Chris McCann]

Also using the ASDM monitoring the phase 1&2 come up complete.

Running debug crypto isakmp brings nothing up relating to the connection I have.

C.

[Marius Gunnerud]

You are correct phase 1 is ok.

if you issue the command

show crypto ipsec sa

Does it show both encrypted and decrypted traffic at both sites?

--

Please remember to rate and select a correct answer
 

[Chris McCann]

Hi Marius,

This is what I have

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #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.: xxx.xxx.xxx.xx/0, remote crypto endpt.: yyy.yyy.yyy.yyy/0
      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: 0103C655
      current inbound spi : 15AC595E

    inbound esp sas:
      spi: 0x15AC595E (363616606)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 263798784, crypto-map: outside_map
         sa timing: remaining key lifetime (sec): 3587
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0x0103C655 (17024597)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 263798784, crypto-map: outside_map
         sa timing: remaining key lifetime (sec): 3585
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

Which doesn't look too good.

C.

[Marius Gunnerud]

Yup, that is not good at all.  But since the tunnel seems to be coming up but traffic is not being encrypted we have narrowed it down a bit.  Next check to make sure that the crypto ACL is the mirror image of eachother at both ends of the tunnel, also make sure that the nat exempt / nat 0 statements are correct and that VPN traffic is not being NATed.

--

Please remember to rate and select a correct answer