Problems with our VPN connection to RelayHealth RevRunner

[Jim Beall]

We have an on-going problem with our VPN connection to RelayHealth’s RevRunner application.

Topic

[LeeAnne Kardas]

I am just starting to develop adt interface to RevRunner.  Please let me know what your resolution to this connectivity issue.

Thank you.

[Paul Johnston]

Hi Jim ,

We do not have an interface to RevRunner but do have another interface where we are experiencing a very similar situation/problem.  I would interested in your solution and or ideas other have designed.

Thanks

[Chris Williams]

You may want to rule out that any “boxes” between Cloverleaf and the remote system are timing out. Routers, switches, VPNs etc all have their own time-out settings. We set the keep-live on our Cloverleaf box at 15 minutes (default is 2 hours) which is usually shorter than the similar settings on all the other network components.

[Anand Raghavan]

We experienced a similar problem to yours with a couple of our interfaces using VPN. As Chris suggested, you have to adjust the tcp_keepidle parameter.

We run CL 5.6 on IBM AIX 5.3.   We contacted our System Admin to change the tcp_keepidle command to 1800 half seconds (you need root access to change that)

Here is our setting:

---

$ uname -a

AIX ieprod 3 5

$ no -a | grep tcp_keepidle

            tcp_keepidle = 1800

---

Hope that helps.

[Jim Beall]

I appreciate the replies but we’re pretty sure the problem isn’t on our side.  Keep alive on our CLoverleaf box is set for 30 minutes and our network guy said it’s even higher on our side of the VPN.  Plus these disconnects occur during the day at times where we’d never go more than a couple of minutes without activity.

[Scott Folley]

Most likely the problem is with the firewall on the receiving side.  Are they seeing connections that eat up the ports in their ephemeral range?  We saw this with a receiving system a long time ago.  What was happening was the connection was timing out at the firewall/VPN concentrator on the receiving side and the tunnel was collapsing without notifying the two ends of the communication.  Our side would reconnect because we had alerts that would fire if we were up but had messages to be sent.  This would cause their side to still be up because it had not seen the disconnect and then we would connect and eat up another port.  This would happen over and over until they ran out of ports in the ephemeral range and they would have to bounce their server box in order to free things up.

[John Custer]

We had a simular situation and the vendor made the following change … here is our senerio …

When the line dropped another connection was established ……  the message went across “line a” and the ack came back on “line b” ….. the vendors response was …. We disabled the keepalives in the IPSEC configuration on our side to resolve

[Author]

Replies