[ previous ] [ next ] [ threads ]
 From:  Kimmo Jaskari <kimmo dot jaskari at gmail dot com>
 To:  m0n0wall list <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] Dropped Traffic on IPSec VPN after switching ISPs
 Date:  Thu, 21 Apr 2011 09:45:50 +0300
On Wed, Apr 13, 2011 at 16:54, Jim Spaloss <jspaloss at gmail dot com> wrote:
> On Tue, Apr 12, 2011 at 6:26 PM, Jim Spaloss <jspaloss at gmail dot com> wrote:
>> On Tue, Apr 12, 2011 at 4:57 PM, Chris Buechler <cbuechler at gmail dot com>wrote:
>>> 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.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>>> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>>> That was my thought as well, although I thought that PPPoE didn't apply to
>> DSL w/ static IP (it it's still there, I couldn't see it).
>> I did end up lowering the MTU on the WAN to 1400 by <shellcmd> and
>> initially it seemed to be better, but the next day, the users were
>> complaining again.
>> I guess I'll try calling the ISP first, but I may have to take a trip up
>> there to make the switch to PFSense, if OpenVPN is my best option.
>> Thanks,
>> Jim
> No luck this morning. Clients are still dropping out. I set up one of them
> to bypass the tunnel and RDP directly into the remote server. Just to make
> sure the tunnel is my problem.

Coming in late on this one... but isn't it so that cable connections
by default share bandwidth with a number of hookups on that cable?

Ie, DSL goes from the ISP to the consumer and any contention for
resources on it should be on the ISP end or further along - ie, you
don't share bandwidth up to the ISP - but cable capacity is shared out
among a number of connections - and we all know that ISP's don't
exactly over-build their networks if they can avoid it, especially in
the consumer space (profit above all in our wacky broken societies),
thus the agreements for consumer-class Internet say "up to" whatever
speed they offer. "Up to" translated, of course, to "ha ha, yeah

So you could conceivably have "mr super bittorrent downloader guy"
hooked up via his cable connection burning it up downloading the
latest Blu-ray movie rip or whatever while your cable connection gets
starved of bandwidth periodically, I'd think. Unless of course this is
some corporate type hookup that you pay a fair bit for and have
guaranteed bandwidth; since I'm not in America I'm not at all up to
speed on what businesses get from their various ISP's (my place of
work in Finland has a 100/100 fiber hookup.)

-{ Kimmo Jaskari }--{ kimmo dot jaskari at gmail dot com }--