Prev: Exchange System Manager failed to retrieve queues error 0x800706D9
Next: Kerberos ticket and CIFS
From: Dave Nickason [SBS MVP] on 3 Dec 2009 18:11
I agree about the site-to-site, but in the short term, how about just
connecting a machine directly to the DSL modem or whatever. You already
know it's not their PC, which seems to leave their router and the ISP -
leaving the customer's router and other network infrastructure out of the
picture will let you know which.

FWIW, we've got two local broadband providers, the telco and RoadRunner.
I've seen fairly major issues with both of them because of hardware - they
put a piece of equipment in your location and leave it there until it fails,
while at the same time constantly upgrading their own infrastructure. Your
cable or DSL router becomes more and more obsolete, and less and less
reliable, as time goes on.

Hooj, it's a wired LAN connection at the remote location, right? If any
part of it's wireless, I'd see what happens over a wired connection before
troubleshooting further.


"Cliff Galiher" <cgaliher(a)gmail.com> wrote in message
news:O1H2OkDdKHA.4780(a)TK2MSFTNGP04.phx.gbl...
>I should have been more specific, but also without knowing a lot more about
>your setup it is tough to be *too* specific.
>
> In short, VPN tunnels still keep an open encryption tunnel open, so an
> idle connection still consumes some bandwidth and resources.
>
> In particular, consumer grade routers can *really* have a problem with VPN
> tunnels and NAT. NAT devices try to do address translation, not just on
> the packet, but also at the protocol level. There is a reason you can FTP
> behind a NAT router, for example. The NAT stack on the router actually
> changes the IP on various places within the packet itself. Because of
> that deep packet inspection, encrypted packets can *easily* overwhelm a
> poorly designed consumer router...they simply weren't designed for this
> type of traffic. Depending on your infrastructure, your connection to
> your ISP may also suffer similar limitations (older Motorola SURFboard
> modems, for example, were very PPTP unfriendly.) So, back to what I said
> above, without knowing more about your infrastructure, I can't say with
> too much specificity where the problem lies.
>
> But the fact that it drops after three minutes pretty consistently does
> tell me that some device along the chain is, in fact, having issues. It
> slowly bleeds resources while the tunnel is open until it has no more
> resources left, then the connection drops. When the connection drops,
> those resources are freed, and the cycle repeats.
>
> With that in mind, I'd still recommend a site-to-site VPN. It is easier
> to manage because you don't have to troubleshoot individual connections,
> but also many site-to-site VPNs are established *at* the network edge so,
> in many cases, you are avoiding the problem of VPN traffic going through
> NAT devices that can be problematic. Obviously if your ISP device has
> issues then that will still occur, but it is one less thing to worry about
> regardless.
>
> -Cliff
>
>
> "hooj" <alexothold(a)gmail.com> wrote in message
> news:ca95a9c8-f204-4580-965b-dc6525f9d12a(a)d20g2000yqh.googlegroups.com...
>> I'm not sure how we could be saturating the link as it's only one
>> person connecting from this office, and when they connect, even if
>> they do nothing, they still get disconnected
>>

From: hooj on 7 Dec 2009 08:59
On Dec 3, 11:11 pm, "Dave Nickason [SBS MVP]"
<gwdib...(a)NOSPAM.frontiernet.net> wrote:
> I agree about the site-to-site, but in the short term, how about just
> connecting a machine directly to the DSL modem or whatever.  You already
> know it's not their PC, which seems to leave their router and the ISP -
> leaving the customer's router and other network infrastructure out of the
> picture will let you know which.
>
> FWIW, we've got two local broadband providers, the telco and RoadRunner.
> I've seen fairly major issues with both of them because of hardware - they
> put a piece of equipment in your location and leave it there until it fails,
> while at the same time constantly upgrading their own infrastructure.  Your
> cable or DSL router becomes more and more obsolete, and less and less
> reliable, as time goes on.
>
> Hooj, it's a wired LAN connection at the remote location, right?  If any
> part of it's wireless, I'd see what happens over a wired connection before
> troubleshooting further.
>
> "Cliff Galiher" <cgali...(a)gmail.com> wrote in message
>
> news:O1H2OkDdKHA.4780(a)TK2MSFTNGP04.phx.gbl...
>
> >I should have been more specific, but also without knowing a lot more about
> >your setup it is tough to be *too* specific.
>
> > In short, VPN tunnels still keep an open encryption tunnel open, so an
> > idle connection still consumes some bandwidth and resources.
>
> > In particular, consumer grade routers can *really* have a problem with VPN
> > tunnels and NAT.  NAT devices try to do address translation, not just on
> > the packet, but also at the  protocol level. There is a reason you can FTP
> > behind a NAT router, for example.  The NAT stack on the router actually
> > changes the IP on various places within the packet itself.  Because of
> > that deep packet inspection, encrypted packets can *easily* overwhelm a
> > poorly designed consumer router...they simply weren't designed for this
> > type of traffic.  Depending on your infrastructure, your connection to
> > your ISP may also suffer similar limitations (older Motorola SURFboard
> > modems, for example, were very PPTP unfriendly.)  So, back to what I said
> > above, without knowing more about your infrastructure, I can't say with
> > too much specificity where the problem lies.
>
> > But the fact that it drops after three minutes pretty consistently does
> > tell me that some device along the chain is, in fact, having issues.  It
> > slowly bleeds resources while the tunnel is open until it has no more
> > resources left, then the connection drops.  When the connection drops,
> > those resources are freed, and the cycle repeats.
>
> > With that in mind, I'd still recommend a site-to-site VPN.  It is easier
> > to manage because you don't have to troubleshoot individual connections,
> > but also many site-to-site VPNs are established *at* the network edge so,
> > in many cases, you are avoiding the problem of VPN traffic going through
> > NAT devices that can be problematic.  Obviously if your ISP device has
> > issues then that will still occur, but it is one less thing to worry about
> > regardless.
>
> > -Cliff
>
> > "hooj" <alexoth...(a)gmail.com> wrote in message
> >news:ca95a9c8-f204-4580-965b-dc6525f9d12a(a)d20g2000yqh.googlegroups.com....
> >> I'm not sure how we could be saturating the link as it's only one
> >> person connecting from this office, and when they connect, even if
> >> they do nothing, they still get disconnected

I've ordered a new router, so will give that a go next and will let
you guys know what happens.

Thanks for all your input so far
From: Leythos on 7 Dec 2009 10:36
In article <4f45bb09-911a-4a55-b1d0-
5c87d7d484fe(a)n35g2000yqm.googlegroups.com>, alexothold(a)gmail.com says...
> I've ordered a new router, so will give that a go next and will let
> you guys know what happens.
>
> Thanks for all your input so far
>

One thing - is this a DSL line by chance?

I've seen VPN solutions fail because the MTU setting was wrong for the
DSL connection, most times I've had to set the MTU value to 1430 or
somewhere in that range - the default of 1500 doesn't always play well
with VPN's - at the same time, with the failing VPN, web browsing and
email worked fine.

--
You can't trust your best friends, your five senses, only the little
voice inside you that most civilians don't even hear -- Listen to that.
Trust yourself.
spam999free(a)rrohio.com (remove 999 for proper email address)
First  |  Prev  | 
Pages: 1 2
Prev: Exchange System Manager failed to retrieve queues error 0x800706D9
Next: Kerberos ticket and CIFS