I have finally tracked down the source of an annoying packet loss issue that plagues my VPN links between Bangkok and London and between Bangkok and Singapore.

The L2TP/PPTP/OpenVPN (all show same issue) tunnels are set up to service these VPNs using MTU sizes of 1460 and an MRRU value of 1600 so that a tunnel MTU size of 1500 is completely supported. Testing between the two physical IP tunnel endpoint addresses with 1500 byte packets shows no packet loss whilst testing across the tunnels shows a random packet loss component, usually less than 2-3 percent, but sometimes (randomly) much higher. The same test with 1400 byte packets shows no loss or a loss level equal to that between the two physical endpoints.

Testing across EoIP tunnels configured at 1500 bytes MTU show no loss or a loss level equal to that between the two physical endpoints.

Apparently the reassembly algorithm for EoIP can handle out-of-order packets well whilst the algorithm used by MLPPP is unable to cope with the level it is seeing.

I've seen other posts in the past that describe what appears to be the same issue...

Tim McKe

Ok, I implemented a workaround that functions.

Since EoIP handles this properly, I set up a 1700 byte MTU EoIP tunnel between the two physical endpoints, then I set up an L2TP tunnel *across the EoIP tunnel* with MTU and MRU set to 1500 bytes. This setup is testing out just fine.

If you do this the setup for the L2TP is touchy, make sure that the Status page of the tunnel on both ends shows MTU and MRU at 1500 when the tunnel establishes.

Hi Trm3,

To clarify, you were using L2TP/PPTP/OpenVPN -> MLPPP, and now you're using L2TP/PPTP/OpenVPN -> EoIP -> MLPPP, or did I miss something?

How many connections were you bonding with MLPPP and what type (ie. DSL?). Was the MLPPP connection itself showing around 2 to 3% packet loss due to I assume out of order packets?

I ask because we've had weird packet loss as well at certain times using VPN over MLPPP and would like a working solution. It sounds like you've found a good workaround that I'd like to clarify before implementing!

Thanks in advance...

Originally I was using OpenVPN and L2TP with MRRU set to 1600 bytes (that sets the tunnel to use MLPPP automatically). The two tunnel endpoints were the public IP addresses of the two Mikrotik boxes.

The fix is to set up an EoIP tunnel between the two public IP addresses with an MTU of 1700 on each end. Assign addresses from a /30 network to both ends of the EoIP link. You then set up the OpenVPN/L2TP/PPTP tunnel with the two endpoints set to the EoIP device addresses. You must set the MTU and MRU of the OpenVPN/L2TP/PPTP server to 1500 bytes *and* set them to 1500 bytes in the client interface configuration. When the tunnel sets up double click on the interface and look at that Status tab to insure that it is *really* running 1500 byte MTU and MRU.

Thanks again trm3,

I think I'm getting it now. Your setup is a little different from ours. We're using MLPPP to our ISP, and then VPN to our centrally hosted MikroTik. I believe what you're describing is that you were using MLPPP to a centrally hosted MikroTik, and have now opted for EoIP.

If I'm right, this might actually be a choice for us that I hadn't considered!

Thanks again...

Using an EoIP tunnel as a carrier for one of the PPP type tunnels works great, but only so long as an EoIP tunnel is viable... This means that it can't be used for dynamic endpoints. We really need to have Mikrotik address this issue.

Do you recall if you also saw random packet loss on smaller ping packets?

Kind Regards