VPN client keeps disconnecting

[EricPuse]

I've been having an issue with my VPN client constantly disconnecting/reconnecting. I have a CODA-4582U in bridge mode, through a switch and a Meraki MX65W. It seems that the ICMP keepalive packets aren't making it to the VPN gateway. A wireshark shows the packet loss outside my local network. Is it possible that it's the modem itself? Could a signal issue cause this? keepalive packet gets sent every 5 seconds and times out at 50 seconds which is happening quite often so there must be a lot of packet loss.

*Added Labels*

[Datalink]

OK, so, there are a couple of items to tackle here:

1.  Out of curiosity, why are you running with your current configuration:  modem -> switch -> Meraki MX65W

The usual configuration for a modem in Bridge mode would be:  modem -> Meraki MX65W

2.  Historically, running a VPN thru an Intel modem has been troublesome.  Intel's Puma chipset has normally reduced the VPN data rates for unknown reasons.  I could see that causing packet loss if you were attempting to run higher data rates thru the VPN.  It all depends on what you're trying to do thru the VPN.  Possibly, at low data rates, you might not have this issue. 

We're running gigabit service and until recently, VPNs and video conferencing wasn't a problem.  Recently an upstream OFDMA channel was enabled at our neighbourhood node.  That upstream OFDMA channel enable has caused problems in the past when it was first rolled in various parts of the Rogers network.  The engineers stopped the rollout for a period of time and then continued with it, but I don't know if the issue of upstream out of sync audio/video experienced in video conferencing was ever completely resolved.  From the comments that I've received recently, I suspect that the issue with the 4582 modem and upstream OFDMA channels has not been completely resolved.  So, personal opinion, there is a potential problem here.  I would need to see your signal levels to see where they're sitting and what your modem is using in terms of QAM and OFDM/OFDMA channels. 

You can copy the signal levels and post them in a new post.  Log into the modem, navigate to the DOCSIS WAN tab and copy the entire signal table set.  Park your curser in front of the Downstream Overview line, hold down the shift key and scroll down and to the right, to just after the last character in the very bottom OFDMA Overview section.  Release the shift key and right click .... Copy.   In a new post .... right click .... Paste.  That should paste in the entire table as it appears in the modem's user interface. 

Lastly, if you are experiencing packet loss, there definitely is the possibility that you have a problem with the external cable or its connectors.  I'm assuming that you're in a house, with an overhead or underground cable running from the local tap to the house's external demarcation point, where the incoming cable meets the house cable system.  That external cable and/or its connectors is the cable systems Achilles heel so to speak.  It doesn't last forever, so every once in a while it has to be replaced.  You can test for this by running a ping test to the Cable Modem Termination System (CMTS).  The signal path, from modem to CMTS looks like this:

1.  Modem to external demarcation point   - via RG-6 cable

2.  External Demarcation point to local tap (on utility pole or in local pedestal)  - via RG-6 cable

3.  Local tap to neighbourhood node - via hard cable

4.  Neighbourhood node to CMTS - via fibre

So, if you have a packet loss issue, typically its in the external cable system, specifically within the RG-6 cable section.  Pinging the CMTS will show if there is any packet loss within that RG-6 cable section.  Typically the issue is normally contained to the RG-6 cables and their connectors, but, its possible for problems to extend further upstream to include the local tap (big splitter so to speak) or any other cable equipment that lies between the local tap and neighbouhood node.  The techs have to keep chasing the issue upstream until the locate the source of the problem, so, the first guess of a cable issue might not be entirely correct.  That becomes a much longer issue in that case. 

Ok, so, to look for packet loss in the external cable system:

1.  Run a trace to anywhere, google for example.  At a command prompt, enter:

Tracert -4 www.google.com

2.  The first hop address will be the modem.  The second hop address will be the CMTS.  Ping the CMTS:

Ping -n 3600 xxx.xxx.xxx.xxx    where xxx.xxx.xxx.xxx is the second hop (CMTS) address. 

That test will run for an hour and then automatically terminate.  You can run a much longer test. I typically run these for 24 hours, not looking for packet loss, looking for response times with a Wireshark capture.   You can run a faster ping test if you're using something other than the normal Windows ping test.  If so, run that using something like 400 ms intervals.  

When you run the ping test, run it without the VPN running, so you're running a normal internet path. 

When the test is done, select the bottom ping test results, use Ctrl c to copy the results and paste them into a post.  

Ok, that should do it for now.  If you can post the signal levels and ping test results, that would be a good starting point.  

Fwiw, here's an interesting discussion regarding the throughput for an MX65W:

Solved: MX65W Throughput - The Meraki Community

Going back to the question of what you're doing with your VPN, I wonder if a highly loaded 65W would suffer from packet loss?  Just thinking aloud at this point.