l2l VPN tunnel disconnects?

[eddie.sardinha]

Hi All, 

I've recently migrated one of our locations to internet circuits and VPN tunnels and removed the old MPLS.  I have a few users who are now complaining they are getting disconnected from their telnet sessions to our ERP application over the tunnel.  What is a good way to troubleshoot this?  I've already done constant ping tests and haven't really seen a big loss at all.  Are there logs in the firewall i can check specifically related to their telnet sessions?

Thanks,

[Francesco Molino]

Hi,

If I understand good, before through MPLS it was working and traffic wasn't passing through a firewall. Am I right? If yes, can you check all tcp timeout values on your ASA?
The telnet session is disconnecting every time after a fixed amount of time or not?

[eddie.sardinha]

Yes how do I check the TCP timeout value?  Traffic is passing just that every so often we disconnect from the telnet session.

[Francesco Molino]

Sorry for my answer delay. As Dean mentionned, you can check that on your config by looking at the command "timeout conn".
You can also see some specific value under policy-map if someone modified it in the past.

[Julio E. Moisa]

Hi

It should be totally transparent for you (CE side), basically the configuration should be checked by the ISP, you could verify your end for anything related to routing or QoS. 

Have you tried bypassing the firewall? also if it is an ASA you could verify the connections, using show conn 

Hope it is useful

:-)

[Dean Romanelli]

Is your VPN tunnel to the location where your ERP apps reside a straight shot P2P VPN, or do you VPN this site's traffic to a data center and then VPN from the data center to another site which has the ERP application?  

I have had this problem numerous times when transitioning from MPLS to IPSec; Primarily when my concentrator is an ASA and when the tunnel is static. Here are some things I've done to fix it.  Sometimes one works and not the other and vice-versa:

1. In your VPN concentrator, set your NTP server to the IP address of the ERP application that is dropping the connections and make sure that traffic goes down the tunnel (source inside keywords). This will send a ping every 64 seconds from your VPN concentrator at your remote location to the ERP server, which should keep all SA's pertinent to that flow along the way "alive".

i.e. ntp server 10.16.48.120 source inside

2. If you have an ASA, ensure your connection timeout is set to a value higher than 1 hour:

timeout conn 8:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02.

Also ensure your users reporting the issues are not idle for too long and are actually getting kicked out while actively working.

3. If you have a "layover"hub where your VPN traffic comes into before it gets to the facility where the ERP apps are (i.e. Branch location----VPN----Data Center A------VPN----Data Center B where ERP is), take the tunnel down and build it directly to the facility where the ERP application lives.  This creates some decentralization, which sucks for a network guy, but it usually resolves the issue.

4. Use Teamviewer or another remote control tool to get on someone's PC who will leave it on overnight and set up a batch file that calls out to the ERP server IP every 3 seconds and gives you a timestamp for each ping series, as well as another one that pings 8.8.8.8 every 3 seconds with timestamp in the same fashion. I've attached instructions to do both, assuming you are on Windows.  Correlate the timestamp between both batch tests and look for close time matches of ping fails. If they match up or closely match, there is more than likely a transport issue somewhere along your ISP's path than warrants a call to them.  If they don't match, or if there are no drops to 8.8.8.8, it is probably something else.  Alternatively, you can use the public IP of the far-end peer address of your VPN as opposed to 8.8.8.8 for more accuracy of checking statistics outside the tunnel. Just amend the 2nd template in my attachment if you want to do that. 

[eddie.sardinha]

I actually think this may be the issue, can you tell me what each line means? What does the 0:10:00 mean?

timeout conn 8:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02.

[Georg Pauwen]

Hello,

0:10:00 means the half open TCP connection will close after 10 minutes. Try and set it to 10:00:00 (10 hours).

timeout conn 8:00:00 half-closed 10:00:00 udp 0:02:00 icmp 0:00:02

[Georg Pauwen · Accepted solution]

Hello,

on a side note, you could try to set the idle timeout in your VPN group policy to 'none':

vpn-idle-timeout none

Can you post the configs of the firewall and the remote site router (or whatever is connected at the remote site) ? We might spot something...