We have an ASA5520 in our data center and an RV180 in our branch office. The tunnel between the two comes up but periodically, about every 2-3 days, it times out and won't come back without a hard reset. Sometimes it does this in the middle of the day when users are actively using the connection.
We started with the ASA5520 and an FVS318 from Netgear. I replaced that with the RV180 thinking the netgear was unreliable as it had some ports on it that appeared to work intermittently or not at all.
However the problem has not gone away even though I've completely replaced the hardware. I also had additional power circuits and a UPS installed thinking maybe we were having some spikes or sags that caused the problem.
I've got logging turned on and never see any thing out of the ordinary. I've set up a continuous ping from a monitoring tool which, if nothing else, ought to keep the tunnel up since traffic would be flowing. I've set the ASA's idle time out on this VPN connection to "none", per cisco support.
I'm at a loss. I really need the tunnel to stay up. I should mention we have a second VPN in that office (on a totally different provider circuit, using a netgear FVS318 and connected to the same ASA5520 using a different VPN instance) and that one never ever goes down. That VPN tunnel supports the IP phones in that office. I do see it renegotiate the tunnel in the logs from time to time but the phones never even blink. I thought that maybe the phones, because they are in constant contact with the pbx, were keeping the tunnel up. But in looking at the logs, it does re-key withouth causing outage.
I am not a huge VPN expert. Where do I start looking or more to the point...what if any settings could I set that would keep the tunnel alive indefinately? This thing is killing the users. They are losing files, they drop their citrix sessions and thus lose their profiles...it's bad.
Users come into the branch office where teh RV180 is located. Their Citrix appliation icons tell them there is 'no connection'. But they can connect to the public network, and hit the company extranet from the public wan, and work that way. So we know the provider itself is not down.
Further more, I have a ping utility set up at the data center and it can ping and get replies every minute to and from devices in that branch office, on the private IP network. So we know the tunnel is up.
And yet, they cannot get to things. About 30 minutes after the first user comes in, suddenly stuff starts working. I don't reset anything, I don't do anything. I have been know as a matter of testing to connect using http to printers in that office. This was how I first discovered the tunnel was not the problem.
It's as if people on that side can't initiate the tunnel after it's gone inactive (timed out or whatever) but if I come in and start a conversation with something on that side, then it comes the rest of the way up. But if that's so, then how come the pings that I leave running all night get replies?
Frustrated. My users are frustrated. We can't seem to get any resolution on the Cisco side. The behavior is consistent with the FVS318 from netgear that we traded out thinking the problem was the FVS318 becuase the beahivor was so strange...it didn't act like a configuration problem else the tunnel wouldn't come up at all. Once it comes up in the monring it stays active all day; they don't have issues until the next morning. No amout of rebooting the RV180 allows them to talk, either.
Question: am I making a bad assumption? Just because my pings go over and come back, does that really prove the tunnel is up? I don't even know what I'm chasing anymore. I have a VPN tunnel that acts like it can send traffic initiated from point B to point A; but all the while traffic started from point A to point B is returned just fine; and eventually for no reason anyone can tell, point B starts sending again...
may have stumbled on something: PFS was set one end not on other. Unsure why tunnel would ever work like that but maybe they don't have to be the same. matched them and will see what happens, else definately will post configs monday.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...