04-03-2014 11:27 AM - edited 03-11-2019 09:01 PM
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.
04-04-2014 06:16 AM
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
04-04-2014 07:55 AM
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.
04-05-2014 07:31 AM
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
04-07-2014 06:29 AM
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
04-07-2014 06:45 AM
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
04-07-2014 08:30 AM
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.
04-07-2014 08:39 AM
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.
04-07-2014 11:48 PM
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
04-08-2014 08:43 AM
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.
04-09-2014 02:18 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide