- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-30-2010 11:39 PM - edited 02-21-2020 05:03 PM
Hi all,
I set up a IPsec tunnel between sonicwall pro route and cisco ASA 5510 . The tunnel established well and both subnets can access each other.
Then I added a static route to one public ip on sonicwall ipsec policy , so that all traffic to that ip will go through IPsec tunnel. It's also working fine.
But the problem is aftre some times Ipsec tunnel goes down and then I need to renegotiate the ipsec on sonicwall to reestablish the tunnel.
This is happening one to two times a day. I am afraid whther this behaviour is due to the config issues. I am pasting my ASA running configuration here.Plese give some advice.
sonicwall publicip 1.1.1.2 subnet 192.168.10.0
cisco ASA publicip 1.1.1.1 subnet 192.168.5.0
ciscoasa# sh run
: Saved
:
ASA Version 8.2(1)
!
hostname ciscoasa
domain-name default.domain.invalid
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Ethernet0/0
speed 100
duplex full
nameif outside
security-level 0
ip address 1.1.1.1 255.255.255.248
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 192.168.5.1 255.255.255.0
!
interface Ethernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet0/3
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
nameif management
security-level 100
ip address 192.168.1.1 255.255.255.0
management-only
!
ftp mode passive
dns domain-lookup outside
dns domain-lookup inside
dns server-group DefaultDNS
name-server 66.28.0.45
name-server 66.28.0.61
domain-name default.domain.invalid
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
object-group service rdp tcp
port-object eq 3389
object-group service OpenVPN tcp
port-object eq 1194
access-list outside extended permit icmp any any echo-reply
access-list outside extended permit tcp any host ###### eq pptp
access-list outside extended permit gre any host ######
access-list outside extended permit udp any any eq 1701
access-list outside extended permit icmp any any
access-list outside extended permit tcp any host ###### eq ftp
access-list outside extended permit tcp any host ####### eq ssh
access-list outside extended permit tcp any host ####### object-group rdp
log disable
access-list outside extended permit tcp any host 1.1.1.1 object-group Open
VPN
access-list nonat extended permit ip 192.168.5.0 255.255.255.0 192.168.5.0 255
.255.255.0
access-list nonat extended permit ip 192.168.5.0 255.255.255.0 192.168.10.0 255
.255.255.0
access-list l2l extended permit ip 192.168.5.0 255.255.255.0 192.168.10.0 255.2
55.255.0
pager lines 24
logging enable
logging asdm informational
mtu outside 1500
mtu inside 1500
mtu management 1500
ip local pool ippool 192.168.5.131-192.168.5.151 mask 255.255.255.0
ip local pool l2tppool 192.168.5.155-192.168.5.200 mask 255.255.255.0
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-621.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (outside) 1 192.168.10.0 255.255.255.0
nat (outside) 1 192.168.5.0 255.255.255.0
nat (inside) 0 access-list nonat
nat (inside) 1 192.168.5.0 255.255.255.0
access-group outside in interface outside
route outside 0.0.0.0 0.0.0.0 38.106.51.121 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
aaa authentication ssh console LOCAL
aaa authentication telnet console LOCAL
http server enable
http 192.168.1.0 255.255.255.0 management
http 192.168.5.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set myset esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map dynmap 5 set reverse-route
crypto dynamic-map easyvpn 10 set transform-set myset
crypto dynamic-map easyvpn 10 set reverse-route
crypto map mymap 10 match address l2l
crypto map mymap 10 set peer 1.1.1.2
crypto map mymap 10 set transform-set myset
crypto map mymap 30000 ipsec-isakmp dynamic easyvpn
crypto map mymap interface outside
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
crypto isakmp policy 20
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 65535
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp nat-traversal 3600
telnet 192.168.5.0 255.255.255.0 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 5
console timeout 0
l2tp tunnel hello 10
dhcpd address 192.168.1.2-192.168.1.254 management
dhcpd enable management
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
group-policy DefaultRAGroup internal
group-policy DefaultRAGroup attributes
dns-server value 66.28.0.45 66.28.0.61
vpn-tunnel-protocol IPSec l2tp-ipsec
default-domain value cisco.com
group-policy DfltGrpPolicy attributes
group-policy easyvpn internal
group-policy easyvpn attributes
dns-server value 66.28.0.45 66.28.0.61
vpn-tunnel-protocol IPSec
ipsec-udp enable
split-tunnel-policy tunnelall
address-pools value ippool
vpn-group-policy DefaultRAGroup
tunnel-group DefaultRAGroup general-attributes
address-pool l2tppool
default-group-policy DefaultRAGroup
tunnel-group DefaultRAGroup ipsec-attributes
pre-shared-key *
tunnel-group DefaultRAGroup ppp-attributes
no authentication chap
authentication ms-chap-v2
tunnel-group 1.1.1.2 type ipsec-l2l
tunnel-group 1.1.1.2 ipsec-attributes
pre-shared-key *
tunnel-group easyvpn type remote-access
tunnel-group easyvpn general-attributes
default-group-policy easyvpn
tunnel-group easyvpn ipsec-attributes
pre-shared-key *
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect netbios
inspect tftp
inspect pptp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:5542615c178d2803f764c9b8f104732b
: end
Solved! Go to Solution.
- Labels:
-
IPSEC
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-06-2011 07:38 PM
I assume that you have typo in the ASA configuration?
access-list l2l extended permit ip 192.168.5.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list extended extended permit ip host voip pubic ip 192.168.10.0 255.255.255.0
Can you confirm that you have the following configured instead:
access-list l2l extended permit ip host voip pubic ip 192.168.10.0 255.255.255.0
Also, even though the crypto map tag says easyvpn, but the peer address is correct at 1.1.1.2
Also, not sure why you have the following configuration (but if it's not required I would suggest that to be removed, and "clear xlate" after the removal):
nat (outside) 1 192.168.10.0 255.255.255.0
Lastly, pls disable keepalive at SonicWall.
If the above still doesn't resolve the issue, can you try to remove the dynamic crypto map from the ASA (no crypto map mymap 30000 ipsec-isakmp dynamic easyvpn), clear the tunnel, and try to initiate the tunnel again between the ASA and SonicWall and grab the output of "show cry isa sa" and "show cry ipsec sa". I am curious to see why it is still referring to the easyvpn crypto map. When you remove the dynamic crypto map, the dynamic lan-to-lan and remote access vpn client will not work.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-30-2010 11:56 PM
If your Sonicwall has any keepalive configured for the IPSec tunnel, please disable it.
You would also need to make sure that the lifetime matches between the ASA and the SonicWall. I would suggest that you configure the lifetime under the L2L crypto map on the ASA, and match that to SonicWall IPSec lifetime.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-31-2010 12:49 AM
Hi jennifer
I believe that the life time is same on both routers which is 28800. I will check the keepalive parameter and update you the result.
By the way I couldn't understand the second thing you mentioned.can U please explain it..
Thanks
Hans

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-31-2010 03:38 AM
Configure the following lifetime for the L2L static crypto map:
crypto map mymap 10 set security-association lifetime seconds
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2011 09:13 PM
Hi ,
I disabled keepalive in sonicwall and confirmed that life time on both sides are same. Now I am able to reproduce the issue.
I will explain it much deeper. I added a static route in Ipsec policy at sonicwall. Traffic to that particular ip will go through ipsec tunnel.
It's happening and working fine. Then my current ipsec policy in sonicwall have two destinaions one is remote LAN subnet and other is
static public ip. My problem came after adding the staic ip in ipsec policy.
ISSUE: When ever ipsec tunnel time out and re-establishes , then the tunnel for static destination and tunnel for remote LAN subnet is established.
Then I can ping to static ip ,but I can't to remote LAN ip. in sonic wall and cisco its showing as connection established. So after 8 hours (28800 secs)
I need to press on 'renegotiate' on sonicwall to re-establish connection to remote LAN. There is no error showing for phase 1 as well as for phase 2 in sonicwall logs.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2011 09:36 PM
Not quite sure how it works. You can't just add traffic to be routed on the Sonicwall without adding the same on the ASA. If you just add that to the Sonicwall end, it looks like it just goes out to the public ip address as clear text, not through the VPN tunnel, and since the crypto ACL (traffic to be encrypted) does not match between the ASA and the SonicWall end, it breaks when the tunnel is renegotiated because one end has mismatch traffic to be encrypted than the other.
On the ASA, you have the following policy to define what needs to be encrypted:
access-list l2l extended permit ip 192.168.5.0 255.255.255.0 192.168.10.0 255.255.255.0
And you would need to have mirror image on the Sonicwall as follows:
Local LAN on SonicWall: 192.168.10.0/24
Remote LAN on SonicWall: 192.168.5.0/24
If you add an extra remote LAN on Sonicwal: public ip address of x.x.x.x for example, you would need to configure the same on the ASA as follows:
access-list l2l extended permit ip host x.x.x.x 192.168.10.0 255.255.255.0
Where is the public ip address located btw? I assume it's behind the ASA? and is the host having public ip address or you NAT it somewhere?
Further to that, after adding the new ip address/subnet to the crypto ACL on both ends, you would need to clear the tunnel so new SA is established for both subnets. Otherwise, if you just add it to the SonicWall end, without adding the same on the ASA, and without clearing and reestablishing the tunnel, the traffic is just routed as clear text, not through the VPN. That explains why it fails when the lifetime expires.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2011 10:18 PM
Thank you very much for spending your time on this.
I have confirmed that the traffic to public ip is going through Ipsec tunnel itself. As you asked,the public ip is not under ASA, it's outside ASA.
I am routing it through tunnel because voip is not allowed in India. As you told the problem is only during renegotiation.I will add acl rule for
public ip in ASA and clear the SAs once I get in to work. btw
clear crypto isakmp sa &
clear crypto ipsec sa
are the two comands to clear, right? Will it remove the present settings for ipsec?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2011 10:34 PM
Yes, absolutely correct. It will not remove the configuration, just clear the SAs.
I am assuming that you are NATing the VOIP server on the ASA itself, right? Otherwise, how are you routing the traffic after it's being decrypted at the ASA end?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2011 11:32 PM
Here , the public ip is voip servers public ip.It's a third party provider(internet). I assumes the traffic to that public ip takes a 'U' turn at WAN interface of ASA with
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface .
Is that clear?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2011 11:58 PM
Yes, that makes sense. You would need to configure "same-security-traffic permit intra-interface" to allow the U-turn traffic.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-04-2011 08:25 PM
Hi
I added the ACL rule on ASA . But again after 28000 seconds , when the routers automatically tries to re-establish the tunnel, the problem again appears.
Actually it's showing as active on both routers. But not able to ping or reach other subnet. Then If I renegotiate tunell for LAN subnet , everything again becomes perfect. One Interesting thing is that there is no issue for the traffic to public ip , issue is only for LAN subnet. Do I need to create a
seperate tunnel for each (remote LAN and voip ip)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-04-2011 08:33 PM
I noticed one interesting thing now. When enetred 'show crypto ipsec sa' command it showed crypto map 'easyvpn' for
voip ip and showed crypto map mymap for LAN subnet. That means eventhough I added voip ip to l2l acl it's matching the
crypto map easyvpn rather than mymap. Is my assumption correct?. Will there be any adverse effect with this? Also I think
crypto map easyvpn is dynamic. I don't what it means. I strongly believe that voip ip(public) should match with 'mymap'
which is mapping LAN subnets. What I need to do?
Thanks
Hans

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-04-2011 09:20 PM
That doesn't sound right. It should be under the static crypto map: mymap 10.
Did you add the public ip address to the existing VPN tunnel on the SonicWall end? You can't add a different VPN tunnel on the SonicWall end towards the ASA, it should be part of the initial tunnel.
I assume that you "clear cry isa sa" and "clear cry ipsec sa" after you added the ACL? and when you try to reestablish the VPN tunnel and also send traffic to both subnets, can you please share the output of:
show cry isa sa
show cry ipsec sa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-05-2011 03:23 AM
Hi Jennifer,
yes I cleared both isakmp sa and ipsec sa, then tried many times result is same. public ip is mapping to crypto map 'easyvpn'.
I added the public ip to the existing tunnel at the sonicwall end. I will paste output by tomorrow it self. from your words , I think that it's not possible
to create more than one ipsec tunnel from sonicwall to ASA , right?
Thank you very much for spending your time on this.
Thanks
Hans

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-05-2011 03:55 AM
I fail to understand how it falls under the dynamic map eventhough you have configured it under the static crypto map.
Can you also post the SonicWall configuration.
Tomorrow, if you can post both full config from ASA and SonicWall after you have added the extra public IP, as well as the output of the following after testing the connection:
show cry isa sa
show cry ipsec sa
that would help. Thanks.
