asked on

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

Alan Huseyin Kayahan

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?

ecsginc

ASKER

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.

Alan Huseyin Kayahan

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?

ecsginc

ASKER

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.

ASKER CERTIFIED SOLUTION

Alan Huseyin Kayahan

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ecsginc

ASKER

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.

Alan Huseyin Kayahan

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