On Tue, Dec 16, 2008 at 10:46 AM, Jesse Rink <[email protected]> wrote:
> So in other words, even if it doesn't HAVE a persisntent route to 192.168.x.x
> via 10.0.0.254, it CAN
> get one by pinging or accessing a server share in the 192.168.x.x. network
> and KEEPS that
> route until the server is rebooted, loses network connection, or the route
> "expires".
That almost sounds like an ICMP redirect to me. Your ISA server is
getting packets from Server-5 with a destination address in
192.168.0.0/24. ISA knows 10.0.0.254 is the gateway for that net.
But it also knows that Server-5's packet came from 10.0.0.0/24, and
should be able to reach 10.0.0.254 directly. So it sends an ICMP
redirect message to Server-5, saying "You can get to 192.168.0.0/24
via 10.0.0.254, and save yourself some time". As I recall, whether or
not a router also forwards the packet when it sends a redirect is
implementation-dependent. Some routers will do it anyway ("This isn't
the most efficient route, but I'll do it anyway"), some will drop the
packet ("This is dumb, use the more direct route").
ICMP redirects are widely regarded as a security exposure, usually
not enabled, and many implementations don't even support them, but I
can't say I've looked up or tested what Windows does in this scenario.
> It almost seems like the 10.0.0.1 router is NOT doing it's job, but in a way,
> it seems to be, since pinging works between the sites.
I'm guessing now, but maybe ISA's firewall rules are preventing it
from forwarding some/all datagrams. So maybe ping is allowed, and
thus it makes it through, triggering the redirect and subsequent
routing table improvement. Or maybe ping isn't allowed, but it will
result in an ICMP redirect being sent anyway. In any event, I'd check
ISA real thoroughly.
If you really want to know, put a packet sniffer at the interesting
points on your network, and see what traffic goes by.
> I did some ping tests also, and found that trying to ping with packets larger
> than 30000 over the VPN fail everytime.
> 29000 they work fine... 29500 they fail 50% of the time.
That's probably a bad sign, especially the intermittent failures.
If it was MTU or similar, it should be a hard limit, all-or-nothing.
You might have a bad network link somewhere.
You might have a path MTU problem. Maybe something along the
network path from A to B cannot accept packets larger than some size,
but it can't fragment the packets for whatever reason. Or can't do so
consistently. If so, tuning the MTU on a working gateway at either
end would be a workaround.
> I will call Vigor tech (vpn routers between the 2 sites) and see what they
> say.
Given that things *work* when your servers have routes that directly
specify the VPN gateway, and *don't* work when they go through ISA,
I'm thinking the problem is more likely with ISA than the VPN gateway.
But then you've got that ping issue. Hmmm. Perhaps you have
multiple network problems.
Possibly relevant horror story: I once had a frame-relay circuit
which had a data-dependent problem. It worked fine most of the time,
but a particular bit pattern would cause massive frame loss. That
particular bit pattern happened to corespond to "AAAAAA" (repeated
capital letter A). Occasionally, some file attachment would contain
that in whitespace, and kablooie, sending an email kills the feed. It
took me *weeks* to figure that one out. It took almost as long to
convince the provider that it was a real problem.
> I'm considering just changing things arounds so that the default gw at site-A
> is 10.0.0.254 instead of 10.0.0.1...
> and changing the route statements on the vigor site-to-site vpn route to
> forward all 192.168.x.x traffic over the vpn,
> an the rest of it to 10.0.0.1 (the isa firewall). I'm thinking that SHOULD
> fix the issue.
If you really want to be proper, toss another NIC in the ISA box,
and put the Vigor box on that, on a subnet of its own, and configure
the ISA to route traffic appropriately. Doubled-back routes are ugly,
inefficient, and make diagnostics more difficult. Your network
topology should be a tree, not a bush. :)
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
