[125960] in North American Network Operators' Group
Re: VPN over Comcast
daemon@ATHENA.MIT.EDU (Jared Mauch)
Tue Apr 27 15:03:58 2010
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <h2ubd3771a61004271156od07891d5p5d64bf746903314b@mail.gmail.com>
Date: Tue, 27 Apr 2010 15:03:12 -0400
To: schilling <schilling2006@gmail.com>
Cc: Michael Malitsky <malitsky@netabn.com>, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
You can get into the SMC device yourself by going to the =
http://10.1.10.1/login.asp link on the SMC. The username/password are =
well known as cusadmin/highspeed. I also recommend against using the =
integrated services in the device if at all possible. It's also mildly =
annoying that it does not respond to traceroute either when it's your =
gateway with a pool of static ips.
I did have one case where it reverted to a mode where it ran dhcp/nat =
but that was shortlived and has not happened again.
- Jared
On Apr 27, 2010, at 2:56 PM, schilling wrote:
> =
http://ckdake.com/content/2008/disable-gateway-smart-packet-detection.html=
> showed a feature of "Gateway Smart Packet Detection" in some SMC
> cable modem.
>=20
>=20
>=20
> The current solution is to identify the affected Comcast modem, and =
ask
> Comcast engineer to turn that "IDS" feature off remotely.
>=20
> I spend several days to talk with comcast about our blackboard will
> not work sometimes in some shared business class residential building.
> Finally got hold of a Regional Engineer to confess this with my
> tcpdump proof. Local comcast engineer may not be aware of this
> feature.
>=20
>=20
> Schilling
>=20
> On Tue, Apr 27, 2010 at 2:36 PM, Owen DeLong <owen@delong.com> wrote:
>>=20
>> On Apr 27, 2010, at 10:48 AM, Kevin Day wrote:
>>=20
>>>=20
>>> On Apr 27, 2010, at 12:42 PM, Michael Malitsky wrote:
>>>=20
>>>> I will probably be laughed at, but I'll ask just in case.
>>>>=20
>>>> We are having particularly bad luck trying to run VPN tunnels over
>>>> Comcast cable in the Chicago area. The symptoms are basically =
complete
>>>> loss of connectivity (lasting minutes to sometimes hours), or =
sometimes
>>>> flapping for a period of time. More often than not, a reboot of =
the
>>>> cable modem is required. The most interesting ones involve the
>>>> following: a PIX or ASA configured as an EZvpn client, connecting =
to a
>>>> 3000 concentrator, authentication over RADIUS. When I go to look =
at the
>>>> RADIUS logs, I see connections from the same box with small =
intervals.
>>>> Timeout is 8 hours, so theoretically I should see 3 connections in =
a
>>>> 24-hr period. In some cases, I see dozens, in the most egregious =
cases,
>>>> thousands over a 24-hour period. I am taking that as an indicator =
of a
>>>> really unstable Comcast circuit. We have not had this problem with =
any
>>>> other ISP, anywhere in the country.
>>>> I am pretty much down to telling customers to find another =
provider...
>>>>=20
>>>> Any thoughts or ideas on the matter will be appreciated.
>>>>=20
>>>> PS. To be fair (?) to Comcast, this is not a ubiquitous problem. =
It
>>>> affects about 25% of the installations I get to see.
>>>>=20
>>>> Sincerely,
>>>> Michael Malitsky
>>>>=20
>>>>=20
>>>=20
>>> We experienced the same thing, and switching from UDP tunnels to TCP =
tunnels fixed it. There are two things at play here.
>>>=20
>>> 1) The SMC modem/router that they insist you use for their "Small =
Business" cable internet service seems to have trouble with very high =
rates of non-TCP traffic going through its NAT.
>>>=20
>> If you have business class service, insist that they put the =
cablemodem in BRIDGE-ONLY mode. This will resolve this issue and =
eliminate the unnecessary NAT.
>>=20
>>> 2) Comcast rate limits non-TCP traffic somewhere on their network.
>>>=20
>> Comcast rate limits traffic in general. TCP is not less rate limited =
than anything else in my
>> experience.
>>=20
>> Owen
>>=20
>>=20
>>=20
>=20
