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),
>> > 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
>> > 30M/5M Cable Service (Optimum) on the one side. However, after
>> switching, my
>> > users immediately began to complain about dropped/slow connections
>> > 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
>> > 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
>> > 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.
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.