Bookmark this page:
Yahoo!
Windows Live
del.icio.us
digg
Netscape
|
|
|||||||||||||
|
Posted by Howard Beale on December 6, 2005, 8:43 pm
Please log in for more thread options Has anyone heard of this actually happening? Googling it brings up a fair amount of armwaving about this topic circa 2002, but nothing recently. I have a client with this service at their remote office; their previous IPSec setup was flakey and we replaced their firewalls on both ends with new equipment, but when I installed this I've noticed that the tunnel cannot be brought up with requests from their home office -- it appears that the ISAKMP packets originating in the home office simply go nowhere. But if the tunnel is brought up with keying initiated at the remote office, it works just fine. We verified this behavior by building a second tunnel to the remote office from our office. I can only think of two explanations for this phenomena: Comcast is deliberately blocking inbound ISAKMP packets to mangle IPSec tunnels, or the cable modem itself has some filtering enabled, blocking these inbound packets. | |||||||||||||
|
Posted by Colin on December 7, 2005, 8:18 pm
Please log in for more thread options | |||||||||||||
|
Posted by Quaoar on December 9, 2005, 6:28 pm
Please log in for more thread options
> Has anyone heard of this actually happening? Googling it brings up a
> fair amount of armwaving about this topic circa 2002, but nothing > recently. > > I have a client with this service at their remote office; their > previous IPSec setup was flakey and we replaced their firewalls on > both ends with new equipment, but when I installed this I've noticed > that the tunnel cannot be brought up with requests from their home > office -- it appears that the ISAKMP packets originating in the home > office simply go nowhere. > > But if the tunnel is brought up with keying initiated at the remote > office, it works just fine. We verified this behavior by building a > second tunnel to the remote office from our office. > > I can only think of two explanations for this phenomena: Comcast is > deliberately blocking inbound ISAKMP packets to mangle IPSec tunnels, > or the cable modem itself has some filtering enabled, blocking these > inbound packets. > > > Take this to the Comcast hsi forum at www.dslreports.com . Q | |||||||||||||

Comcast "business" cable internet; blocking IPSec ISAKMP?
Yahoo!
Windows Live
del.icio.us
digg
Netscape 



> fair amount of armwaving about this topic circa 2002, but nothing
> recently.
>
> I have a client with this service at their remote office; their
> previous IPSec setup was flakey and we replaced their firewalls on
> both ends with new equipment, but when I installed this I've noticed
> that the tunnel cannot be brought up with requests from their home
> office -- it appears that the ISAKMP packets originating in the home
> office simply go nowhere.
>
> But if the tunnel is brought up with keying initiated at the remote
> office, it works just fine. We verified this behavior by building a
> second tunnel to the remote office from our office.
>
> I can only think of two explanations for this phenomena: Comcast is
> deliberately blocking inbound ISAKMP packets to mangle IPSec tunnels,
> or the cable modem itself has some filtering enabled, blocking these
> inbound packets.
>
>
>
>