- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-06-2011 11:02 AM
I am trying to setup a VPN tunnel between a Cisco ASA 5510 (Version 8.2(2)) and Sonicwall TZ200. I got tunnel up and going and I am able to ping the Cisco ASA internal IP from the Sonicwall LAN but nothing else works. When I try to ping a host behind the Cisco ASA from the Sonicwall LAN I get the following message "Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside:10.20.10.x/xxxx dst inside:10.20.2.x/xxxx denied due to NAT reverse path failures" on the ASA
Googling the above error shows issues with version 8.3 and later which looked like the nat commands were changed but the ASA I am working on is still on 8.2 and the other common issue is not adding a NAT exemption. I have double-triple checked that I did add a NAT exception rule from the hosts on the cisco network to the hosts on the Sonicwall network. Seems like I have hit a road block so any help would be appreciated. Thanks
Here are some excertps from the config file (10.20.2.0 behind the cisco and 10.20.10.0 behind the sonicwall)
nat (inside) 0 access-list nonat
..
access-list nonat extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0
access-list outside_1_cryptomap extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0
..
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set peer x.x.x.x
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
..
crypto isakmp enable outside
crypto isakmp policy 5
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 28800
..
group-policy SiteToSitePolicy internal
group-policy SiteToSitePolicy attributes
vpn-idle-timeout none
vpn-tunnel-protocol IPSec
split-tunnel-network-list none
..
tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x general-attributes
default-group-policy SiteToSitePolicy
tunnel-group x.x.x.x ipsec-attributes
pre-shared-key *****
..
Added few excerpts from config file
Solved! Go to Solution.
- Labels:
-
VPN
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2011 09:51 AM
Hello Manjitriat,
Ok, the IPSEC spoof detected is normal, it means that you are trying to send unencrypted packets over an encrypted line.
Now if you are seeing on the packet tracer that the traffic is going trough the VPN channel everything its fine in your site.
Now the packet tracer should be something like this:
packet-tracer input inside tcp private_ip_lan 1025 destination_private_ip_lan 80
Please provide us the output of the following statements after you run the packet tracer.
Show crypto Isakamp SA
Show crypto Ipsec SA
Regards,
Julio
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-06-2011 02:33 PM
Hi,
Could you provide your full NAT configuration? Forward some of the logs that you are seeing? What happens if you do a "clear local"?
Can you run a packet-tracer for the traffic flow that you are testing?
packet input inside tcp 10.20.3.20 1111 10.20.10.66 80
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-06-2011 03:17 PM
Thank you for the time Jose,
Let me first admit I am making most of the changes/configs using ASDM. Here is the NAT config
global (outside) 1 interface
nat (outside) 1 10.20.12.0 255.255.255.0
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 1 0.0.0.0 0.0.0.0
10.20.12.0 - is the L2TP VPN DHCP pool
As for the logs I see a lot of other informational messages but that is the only one I see that pertains to the VPN. and here is the log that i see in detail
5 Nov 06 2011 22:52:32 305013 10.20.2.249 9100 Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside:10.20.10.10/3727 dst inside:10.20.2.249/9100 denied due to NAT reverse path failure
I ran the Packet Tracer in ASDM and I think you meant the src ip to be 10.20.2.20:1111 to destination 10.20.10.66:80
and the result shows as "The packet is allowed"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-06-2011 07:35 PM
Hello Manjitriat,
Can you post the following commands:
-Show run route
Do a packet tracer and then give us:
-Show crypto Isakamp SA
-Show crypto Ipsec SA
Regards,
Julio
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-06-2011 07:47 PM
Hi Julio,
I finally figured out some of the issues. Running packet tracer showed the traffic going over VPN was getting NAT'd. The NAT exempt policy entered through ASDM does show up in the running config but they have no effect. I had to login through SSH and retype the exempt rule. I knew something was wrong since when I entered that command I didn't get a error saying the rule already exist.
Running the packet tracer again showed the VPN now getting exempt but it was getting blocked by an access rule even though I had entered a rule allowing IP traffic from 10.20.10.0 to 10.20.2.0 on the outside interface. So like before I logged into SSH and retyped the rule and didn't get an error saying the rule already exists. So I knew there was an issue and re-ran the packet tracer and the packets are showing passed through both (except for the one inbound as it says IPSEC spoof detected which I believe is normal).
What could I do next to figure out what the issue is?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2011 09:51 AM
Hello Manjitriat,
Ok, the IPSEC spoof detected is normal, it means that you are trying to send unencrypted packets over an encrypted line.
Now if you are seeing on the packet tracer that the traffic is going trough the VPN channel everything its fine in your site.
Now the packet tracer should be something like this:
packet-tracer input inside tcp private_ip_lan 1025 destination_private_ip_lan 80
Please provide us the output of the following statements after you run the packet tracer.
Show crypto Isakamp SA
Show crypto Ipsec SA
Regards,
Julio
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2011 10:41 AM
Julio,
The packet tracer with the above settings shows the packet is allowed.
#Show crypto Isakmp SA
1 IKE Peer: y.y.y.y
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE
#Show crypto ipsec SA
Crypto map tag: SYSTEM_DEFAULT_CRYPTO_MAP, seq num: 65535, local addr: x.x.x.x
local ident (addr/mask/prot/port): (10.20.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.20.10.0/255.255.255.0/0/0)
current_peer: y.y.y.y
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 44738, #pkts decrypt: 44741, #pkts verify: 44741
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 4, #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.: x.x.x.x, remote crypto endpt.: y.y.y.y
path mtu 1500, ipsec overhead 58, media mtu 1500
current outbound spi: B486B4E8
current inbound spi : 2E8B3062
inbound esp sas:
spi: 0x2E8B3062 (780873826)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 50290688, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP
sa timing: remaining key lifetime (sec): 19452
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0xB486B4E8 (3028727016)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 50290688, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP
sa timing: remaining key lifetime (sec): 19446
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2011 01:04 PM
Hello Manjitriat,
Seems like the configuration is the one required, as you can see the status of the vpn tunnel is active.
I would definetly recommend you to check the configuration on both sides regarding the encryption, authentication,etc, this to confirm both devices has the same settings because as I can tell you the configuration on this one is fine,
Regards,
Julio
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2011 02:48 PM
Julio,
Thank you for the reply. I am completely at a loss here too but have found something interesting. On the Sonicwall I saw the counters show a bunch of packets sent and nothing recieved so I logged into ASDM and viewed the VPN tunnel properties and it shows the same a bunch of packets but 0 sent. So looks like the ASA is recieving traffic from the Sonicwall over the tunnel but not routing any traffic over the VPN tunnel back to the Sonicwall and possibly sending it somewhere else.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2011 03:17 PM
Hello Manji,
If you do a show run route, do you see one that matches the destination (could be a default route 0.0.0.0 0.0.0.0)
Are you able to see that?
Also can you send me the output of :
show run access-group
show run access-list
Regards,
Julio
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2011 04:26 PM
On the show run route I don't see a route to the remote network and so yes it might be just on the default
route outside 0.0.0.0 0.0.0.0 x.x.x.x 1
#show run access-group is blank
#show run access-list
access-list outside_access_in extended permit ip 10.20.10.0 255.255.255.0 10.20.2.0 255.255.255.0
access-list nonat extended permit ip 10.20.2.0 255.255.255.0 10.20.12.0 255.255.255.0
access-list nonat extended permit ip 10.20.4.0 255.255.255.0 10.20.12.0 255.255.255.0
access-list nonat extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0
access-list outside_2_cryptomap extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2011 05:15 PM
Hello Manjitriat,
1-Do you have the ICMP inspect enable over your policy_global?? If not please add it
2-Can you try to ping from one internal host to another host behind the sonic firewall, Afterwards take a show crypto isakamp sa and ipsec sa
Regards,
Julio
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2011 08:53 PM
Yes inspect icmp is enabled in global_policy
The ping requests time out (The only ping that works is when I ping from the remote side to the ASA internal IP address, no other pings from either side work)
#show crypto isakmp sa
1 IKE Peer: x.x.x.x
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE
#show crypto ipsec sa
interface: outside
Crypto map tag: outside_map, seq num: 1, local addr: x.x.x.x
access-list outside_2_cryptomap extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0
local ident (addr/mask/prot/port): (10.20.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.20.10.0/255.255.255.0/0/0)
current_peer: y.y.y.y
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 39543, #pkts decrypt: 39543, #pkts verify: 39543
#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.: x.x.x.x, remote crypto endpt.: y.y.y.y
path mtu 1500, ipsec overhead 58, media mtu 1500
current outbound spi: 0ED0F897
current inbound spi : 596CCE6F
inbound esp sas:
spi: 0x596CCE6F (1500302959)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 50327552, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 7440
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x0ED0F897 (248576151)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 50327552, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 7440
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2011 07:14 AM
Julio,
This issue has been resolved. Didn't realize there was a static route added on a Layer 3 switch behind the ASA. Deleted that route and everything seems to be working fine.
Thank you for you help
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2011 09:06 AM
Hello Manjitriat,
Good to know, so as we suspected everything was perfect on the ASA.
Hope you have a great day.
Julio
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
