How do I keep my lan-to-lan VPN tunnel alive 24x7?

First - I am an experienced IT professional but primarily a "software guy".  I have plenty of exposure to network configuration and equipment but I am not a CISCO certified engineer, nor do I play one on TV and I've never slept at a Holiday Inn Express.  I am familiar with creating and maintaining VPN tunnels in limited circumstances.  That is to say, I understand what I've done in the circumstances where I have been involved in creating and maintaining the tunnel but my knowledge base is limited to only those experiences.  This is my first experience with CISCO products.

I have an ASA 5505 vpn appliance.  It is installed, configured and working OK.  It IS NOT configured using the "Easy VPN" stuff.  It is configured with a l2l tunnel (connected to a CISCO 3000 VPN concentrator on the other end).  My issue is that it appears to shut the tunnel down in periods when there is no activity across the tunnel.  The users on the "other side" of the tunnel cannot re-establish the tunnel once it is down.  I re-establihse it by using the ASDM tool to trace packets from our side to thiers.

It appears that the tunnel will stay established as long as there is activity Ispecifically, activity originating from our side of the tunnel) and, as such, I have put a persitant ping in place from to ping from our side to the other side once per minute.  The tunnel appears to persist under this condition.

Any ideas?  I have attached the ASA 5505's running configuration.  However, I have "redacted" the public IP's for security reasons...  (if it helps  "x.y.z.0" is out public subnet, "t.u.v.0" is our internal prival LAN subnet, "a.b.c" is the universal subnet used on teh tunnel and "j.k.l" is the public subnet on the other side of the tunnel)

: Saved
:
ASA Version 7.2(2)
!
hostname ---------
domain-name -------.com
enable password ------------------ encrypted
names
!
interface Vlan1
 nameif outside
 security-level 0
 ip address x.y.z..213 255.255.255.0
!
interface Vlan2
 nameif inside
 security-level 0
 ip address t.u.v.254 255.255.255.0
!
interface Ethernet0/0
!
interface Ethernet0/1
 switchport access vlan 2
!
interface Ethernet0/2
 switchport access vlan 2
!
interface Ethernet0/3
 shutdown
!
interface Ethernet0/4
 shutdown
!
interface Ethernet0/5
 shutdown
!
interface Ethernet0/6
 shutdown
!
interface Ethernet0/7
 shutdown
!
passwd FmZUfYft9vhrGvu2 encrypted
ftp mode passive
clock timezone EST -5
clock summer-time EDT recurring
dns domain-lookup inside
dns server-group DefaultDNS
 domain-name ecsginc.net
dns server-group ecsginc.com
 name-server t.u.v.1
 domain-name ecsginc.com
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
access-list outside_vpn extended permit ip host a.b.c.33 host a.b.c.25
access-list inside_access_in extended permit ip any any
access-list outside_access_in extended permit tcp any host x.y.z.213 eq ssh
pager lines 24
logging enable
logging asdm-buffer-size 512
logging buffered debugging
logging asdm debugging
logging facility 23
mtu outside 1500
mtu inside 1500
no failover
monitor-interface outside
monitor-interface inside
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-522.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 t.u.v.4 255.255.255.255
static (inside,outside) a.b.c.33 t.u.v.4 netmask 255.255.255.255
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 x.y.z.1 1
route outside a.b.c.25 255.255.255.255 x.y.z.213 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 uauth 0:05:00 absolute
group-policy DfltGrpPolicy attributes
 banner none
 wins-server none
 dns-server none
 dhcp-network-scope none
 vpn-access-hours none
 vpn-simultaneous-logins 3
 vpn-idle-timeout 30
 vpn-session-timeout none
 vpn-filter none
 vpn-tunnel-protocol IPSec l2tp-ipsec
 password-storage disable
 ip-comp disable
 re-xauth disable
 group-lock none
 pfs disable
 ipsec-udp disable
 ipsec-udp-port 10000
 split-tunnel-policy tunnelall
 split-tunnel-network-list none
 default-domain none
 split-dns none
 intercept-dhcp 255.255.255.255 disable
 secure-unit-authentication disable
 user-authentication disable
 user-authentication-idle-timeout 30
 ip-phone-bypass disable
 leap-bypass disable
 nem disable
 backup-servers keep-client-config
 msie-proxy server none
 msie-proxy method no-modify
 msie-proxy except-list none
 msie-proxy local-bypass disable
 nac disable
 nac-sq-period 300
 nac-reval-period 36000
 nac-default-acl none
 address-pools none
 client-firewall none
 client-access-rule none
 webvpn
  functions url-entry
  html-content-filter none
  homepage none
  keep-alive-ignore 4
  http-comp gzip
  filter none
  url-list none
  customization value DfltCustomization
  port-forward none
  port-forward-name value Application Access
  sso-server none
  deny-message value Login was successful, but because certain criteria have not been met or due to some specific group policy, you do not have permission to use any of the VPN features. Contact your IT administrator for more information
  svc none
  svc keep-installer installed
  svc keepalive none
  svc rekey time none
  svc rekey method none
  svc dpd-interval client none
  svc dpd-interval gateway none
  svc compression deflate
username admin password ------------- encrypted privilege 15
http server enable
http 0.0.0.0 0.0.0.0 inside
http 0.0.0.0 0.0.0.0 outside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set ESP-3DES-HMAC esp-3des esp-md5-hmac
crypto map outside_map0 1 match address outside_vpn
crypto map outside_map0 1 set peer j.k.l.189
crypto map outside_map0 1 set transform-set ESP-3DES-HMAC
crypto map outside_map0 1 set reverse-route
crypto map outside_map0 interface outside
crypto isakmp enable outside
crypto isakmp policy 10
 authentication pre-share
 encryption 3des
 hash md5
 group 2
 lifetime 43200
crypto isakmp nat-traversal  20
tunnel-group j.k.l.189 type ipsec-l2l
tunnel-group j.k.l.189 ipsec-attributes
 pre-shared-key *
no tunnel-group-map enable ou
telnet timeout 1440
ssh 0.0.0.0 0.0.0.0 outside
ssh 0.0.0.0 0.0.0.0 inside
ssh timeout 30
console timeout 0

!
class-map inspection_default
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect icmp error
!
service-policy global_policy global
smtp-server x.y.z.13
prompt hostname context
no compression svc http-comp
Cryptochecksum:4362f4d3bfbfa98870ba242e44cf148c
: end
asdm image disk0:/asdm-522.bin
no asdm history enable
ecsgincAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
Advertise Here
 
Alan Huseyin KayahanConnect With a Mentor Commented:
" on our side to be accessed 192.168.0.4 and the machine we are trying to access on thier side would be, say, 192.168.0.200"  this explains everything :) but thanks for detailed description
   you have nat-traversal enabled, so what I recommend is checking the match acl in cisco 3000 and the route in a.b.c.25 . Match acl defines the traffic to flow through tunnel

following is yours
access-list outside_vpn extended permit ip host a.b.c.33 host a.b.c.25

 "our local machine has a static route telling it that all traffic to the 66.66.66.0 subnet should route through the 192.168.0.254 gateway - which is the ASA 5505"  and you have route in t.u.v.4

nothing is wrong in your side. Remote admin should check
    *The match acl
    *Static entry
    *Added route in d.e.f.xx


Following is the idle timeout of the tunnel specified in your default group policy. You can set it to a higher value, of course remote site has to do also.
vpn-idle-timeout 30



0
 
Alan Huseyin KayahanCommented:
In my opinion, problem is not keeping tunnel up 7/24. The problem is
"The users on the "other side" of the tunnel cannot re-establish the tunnel once it is down"
     A normal tunnel can be triggered from both sites.

access-list outside_vpn extended permit ip host a.b.c.33 host a.b.c.25
  Can you explain the ACL above? Remote site and local site is in same subnet?
  Are you able to post cisco 3000's config?
0
 
ecsgincAuthor Commented:
I cannot publish the VPN 3000's config because I am not the administrator of that machine and there are two different enterprises involved (aka another company owns that equiopment and I have no administrator access)

By way of explainig the access list...
The tunnel is very specific, at the moment.  It is essentially a tunnel between two machines.  In order to avoid IP conflict between machines on the two private networks, we used global IP's for the VPN endpoints.  Each of us is then using static routes and NAT to route the traffic from the respective global IP's to the private IP behind the respective firewalls.

As you can see from the config the ASA 5505 has en external public IP of (x.y.z.213) and an internal IP of (t.u.v.254) with an external gateway of (x.y.z.1)

The VPN 3000 has an external public IP of (j.k.l.189)

So the traffic flow looks like:

t.u.v = "our" local LAN subnet
x.y.z = "our" public IP subnet
a.b.c = global IP subnet
j.k.l = "thier" public IP subnet
d.e.f = "thier" local LAN subnet

The IPSEC TUNNEL
                   "us"                                               "them"
a.b.c.33--->x.y.z.213 <--IPSEC TUNNEL-->j.k.l.189---->a.b.c.25

end-to-end traffic flow (us to them)
t.u.v.4-->t.u.v.254-->(as a.b.c.33)--->IPSEC TUNNEL--->(a.b.c.25)-->[whatever they do]

end-to-end traffic flow (them to us)
[thier LAN]-->(as a.b.c.25)--->IPSEC TUNNEL--->(a.b.c.33)-->(ASA at t.u.v.254 NAT)-->(t.u.v.4)

on our side we have a NAT rule to translate (a.b.c.33) to (t.u.v.4) and the actualy machine (t.u.v.4) has a static route for the (a.b.c.0)  subnet to send traffic destined to (a.b.c.0) via (t.u.v.254) (the ASA 5505)

My inexperience is probably showing here as I can only explain it in terms that I completely undestand but I hope this provides some more clarity as to why the ASA5505 is confifured as it is.

I think I mentioned it before but the ASA 5505 is deployed for this sole purpose.  There is another network firewall appliance that handles the bulk of the (t.u.v.0) subnet and is the (t.u.v.0) gateway.  It's address is (t.u.v.1).  That's why there are very specific route rules for the VPN traffic to bypass the default routing on the (t.u.v.0) subnet.
0
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

Download Now!
 
Alan Huseyin KayahanCommented:
d.e.f = "thier" local LAN subnet
 And never takes place in your above diagrams, couldnt understand the nature of this l2l
also
t.u.v = "our" local LAN subnet
x.y.z = "our" public IP subnet  
j.k.l = "thier" public IP subnet
d.e.f = "thier" local LAN subnet

are enough to establish a l2l vpn, what is a.b.c = global IP subnet    for?

My question is,
   lets say that remote local network is 172.16.10.0/24 and your local network is 192.168.1.0/24  and you want communication between 192.168.1.x and 172.16.10.y and vice versa, am I correct?
0
 
ecsgincAuthor Commented:
My bad on the d.e.f - since we only address the global IP I didn't use it.  d.e.f is burried in the "whatever they do" part of the diagram.  It really never should have been addressed.

the a.b.c subnet protects against local ip subnet conflicts adter the tunnel is established.

so, for example, let's say

Our subnet is 192.168.0 (and it isn't) and their subnet is 192.168.0.  (it isn't either)
The Global subnet is 66.66.66.0 (and it isn't)
That would make the IP of the machine on our side to be accessed 192.168.0.4 and the machine we are trying to access on thier side would be, say, 192.168.0.200.

There is no guarantee that we don't have an IP on our subnet that conflicts with thier 200 machine and visa versa for our 4 machine.  So, in order to guarantee a globally unique IP address on each subnet, we took two IPs out of a public IP pool and assigned each end of the tunnel one of the gloabally unique IP's.  So, in this example, our end would be 66.66.66.33 and thiers would be 66.66.66.25.

So, on our side, we NAT 66.66.66.33 to 192.168.0.4 and on thier side they NAT 66.66.66.25 to 192.168.0.200.  Our machine on our local network addresses thier machine as 66.66.66.25 which travels over the VPN tunnel because our local machine has a static route telling it that all traffic to the 66.66.66.0 subnet should route through the 192.168.0.254 gateway - which is the ASA 5505.  Once the ASA5505 gets the 66.66.66.25 traffic it knows to send it over the VPN tunnel.  I am assuming that the traffic on the other end (VPN 3000 and the "200" machine) is handled the same way.  I know for sure that they address us as 66.66.66.33.

All of this routing works, the VPN tunnel gets established properly and all network conversations on both LAN's and over the IPSEC tunnel works properly.  The only issue we are encountering is this *apparent* inactivity timeout and, as you say, the inability for traffic coming in from 66.66.66.25 to re-establish the tunnel.

In reality, both LAN's have mutliple private local subnets and the machines in question don't have conflicting subnets but the thought process from "thier" end was to use the globally unique addresses to protect against potential conflict in the future.  Since it all works and allows both of our organizations to proceed with whatever local LAN configuration we want we have no real issue with it.
0
 
ecsgincAuthor Commented:
I tweaked the idle timeout on the tunnel to be "unlimited" which is what it was on the other end.  This has made the tunnel much more stable.  When the tunnel is down, it will only reestablish when I reboot the ASA 5505 so thtre is still some wotk to be done.  I suspect a firmware upgrade may help.  However, having another set of eyes review the config, respond in complete and comprehendable language is extremely valuable.  Thanks.
0
 
Alan Huseyin KayahanCommented:
You are welcome ecsginc, but remember, this is an issue which should be worried about/solved by the remote administrator, since they are the side that cant trigger the tunnel
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.