I have recently installed four Cisco RV042 v3 VPN routers for a customer of ours to replace existing Nortel Contivity 1010 devices which were providing VPN tunnels from the customer's 3 branches to their headoffice. The original Nortel devices were working perfectly but the customer wanted some firewall rule changes and the Nortels were proving to be somewhat inflexible and incomprehensible in their configuration hence why they were replaced.
When installing the Cisco routers I configured the VPN settings to match the Nortel device settings so that I could swap out a branch at a time without taking the whole setup down for a day.
The customer has a Unix based dumb-terminal application running on a server at headoffice that they access from their branches using terminal emulators on Windows PCs and thin client hardware devices that support vt100 terminal emulation.
Prior to installing the Cisco RV042's everything was working fine. Now they are using the RV042's they keep getting the sessions from their branches dropped. Both PC users and thin client users are losing sessions and it happens with active and idle sessions. I have checked the logs on the routers when users are disconnected and there is nothing logged at that time (other than my login)... I had thought maybe it was to do with tunnel renegotioations so I have set to phase 1 / phase 2 SA timeouts to 86400 & 28800 seconds respectively but this has had no effect. I had also seen somebody else post a query regarding this issue and somebody advised disabling 'SPI' in the firewall... I have tried this and it makes no difference.
I have even updated all the routers to the latest firmware (4.1.1.01) but the problem persists.
We have used VPNs between Cisco RV042 (correction Linksys RV042 v2) with many other customers in the past without issue although that was running RDP not telnet.
Is there something wrong with the Cisco v3 models of the RV042 or don't RV042s in general work reliably with routing telnet?
The workaround is to increase the TCP timeout of the firewall from the current default value of 30 minutes to delay the timeout of an idle telnet (or database) session.
Thanks for that, but we don`t see any time out values in the RV042's firewall settings. The only time values we see are the VPN lifetimes.
I had this VPN problem also.
I tried to disable the SPI function then ok.
but i think this only the temporary soulution.
Thanks for the input / suggestions. I had already tried disabling the SPI feature without success.
I have found out from the customer that it is only idle sessions that are being disconnected - not idle and active as stated above. I have done further testing and found that 30 minutes is about the limit that an idle session will stay connected for. As stated by Bernie Ledwick there is no way of adjusting this through the web interface (maybe if Cisco hadn't deliberately stopped telnet access by interfering with the authentication mechanism on the telnet console it might have been possible to tweak the timeout?).
Anyway I contacted Cisco Small Business Support, opened a support case and ultimately received this reply:
I consulted your issue with the escalation team. Here is the response: "The timeout is for all TCP connections so it would still happen on both client to gateway and gateway to gateway VPN sessions." As Telnet uses TCP protocol, even though it is going through the tunnel, it will time out at 30 minutes.
So at this point there is no possibility to escalate this as a bug and I will be forced to close the case as not supported.
If you want to escalate this issue as a future feature request, please let me know and I will open a new case for this request.
I had created a thread of this before. the problem we got same as yours.
"To change the timeout value for TCP/UDP session on the RV042, you may access the hidden interface via the following URL:
Log into your router as normal. Then enter (or copy/paste) f_general_hidden.htm following the routr IP address. This accesses TCP and UDP timeout paramenters that are not accessible from the regular General menu.
I set the TCP timeout @ 86400 (24 hrs) and the UDP to the maximum allowable value (300). Based on several hours of testing, this seems to solve the problem.
the solution is:
Change 1800 seconds (30 minutes) to 28800 seconds (8 hour).