[ previous ] [ next ] [ threads ]
 
 From:  Chris Buechler <cbuechler at gmail dot com>
 Cc:  m0n0wall list <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] Dropped Traffic on IPSec VPN after switching ISPs
 Date:  Tue, 12 Apr 2011 16:57:14 -0400
On Mon, Apr 11, 2011 at 6:03 PM, Jim Spaloss <jspaloss at gmail dot com> wrote:
> Hello all,
>
> I have a m0n0wall to m0n0wall VPN IPSec VPN that worked wonderfully for
> several years. The link is between two nursing home facilities that are
> about 100 miles apart. One has an 8M/2M cable modem service (Comcast), the
> other had a 1.5M/384K DSL service (Verizon). Both sides have static IPs.
>
> I finally got the management to agree switch out the DSL for a much faster
> 30M/5M Cable Service (Optimum) on the one side. However, after switching, my
> users immediately began to complain about dropped/slow connections across
> the VPN, and "I thought this was supposed to be faster."
>
> I tried allowing fragmented IPSec traffic, but that really didn't help.
>
> I began experimenting with lowering the MTU across the tunnel, and found
> that a significant portion of my traffic was being dropped. The sweet spot
> seems to be 1418 (1419 drops some traffic). I went searching for a way
> to permanently lower the tunnel's MTU, but all I could find was a post where
> the recommendation was to lower the MTU of the WAN interface via ifconfig in
> a <shellcmd> tag. That seems to make the connection better in my initial
> testing, but I can't help but think that there is a better way.
>
> Most of my user base is in Comcast Territory so I have little experience
> with Optimum online. I've never had to change a MTU setting on Comcast
> before. Can anyone tell me if this is normal for Optimum Online? (Cisco
> Router + Cable Modem w/ 5 Static IPs)
>

That's very unusual, the opposite of what problem I would expect.
Cable has a normal 1500 MTU (or should) where DSL has the overhead of
PPPoE which can cause issues like you're seeing. So you should have
had the problem before switching, not after. :) The MTU box on WAN
enables MSS clamping so you can set the lower MTU there and that
should work around it, though I don't recall for sure offhand if that
also impacts traffic traversing IPsec. If not you may need the
<shellcmd> to actually lower the WAN interface MTU.

OpenVPN works around those issues by using MSS clamping on traffic
traversing that connection only.