There has to be a route back to the originating network, or ping won't even work. Your destination has to know how to get back to the originator.
Joe Heaton Employment Training Panel -----Original Message----- From: Jesse Rink [mailto:jesse-r...@wi.rr.com] Sent: Tuesday, December 16, 2008 7:46 AM To: NT System Admin Issues Subject: Re: issue with accessing \\servername Ok, a couple updates.... I found out the following. Servers in Site-A cannot be accessed at Site-B via \\servername, UNLESS the server in Site-A has a route added to it (persistent route or automatically added) for the network at Site-B. Site-A is a 10.x.x.x., Site-B is a 192.168.x.x Devices in Site-A have a gateway of 10.0.0.1. The 10.0.0.1 device (which is an ISA firewall) has a persistent route added for 192.168.x.x that points to the 10.0.0.254 site-to-site vpn router. I tested this repeatedly, and as long as a server in Site-A has a persistent route added, *OR* as long as the server in Site-A has at LEAST tried to either PING a device on the 192.168.x.x network or tried to access a device on the 192.168.x.x. network via SMB (shares, for instance) then the proper route statement automatically gets added to that servers routing table. 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". So... this makes me wonder. If Server-5 does NOT have a persistent route to 192.168.x.x at Site-B, and instead goes through it's normal gateway 10.0.0.1, a server in Site-B, CAN still ping Server-5. Yet, cannot access the \\servername share, UNLESS Server-5 either a) first pings something in Site-B, b) accesses a server share in Site-B, or c) has a persistent route added for Site-B, or d) has the default gw changed from 10.0.0.1 to 10.0.0.254. 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 will call Vigor tech (vpn routers between the 2 sites) and see what they say. 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. Not sure what that tells me though... 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. -------------------- On Mon, Dec 15, 2008 at 4:12 PM, jesse-r...@wi.rr.com <jesse-r...@wi.rr.com> wrote: > We have 2 sites/locations connected a site-to-site VPN... Try ping'ing with larger packet sizes. Try multiple sizes, such as 500, 2000, 10000, 30000, 60000, and 65500. Might be an issue with path MTU. That's not uncommon with VPNs, since you're encapsulating datagrams inside datagrams -- an already max-size datagram then won't fit without fragmentation. That wouldn't show up with the default ping of 64 bytes. Could also be a name resolution issue. I've seen name resolution issues screw-up SMB, even when you give an IP address for the server name. Along those lines: Do you have WINS server(s) configured with all computers at all sites using the same set of WINS server(s)? If you are not using WINS, do you have NetBIOS-over-TCP/IP force-disabled on all clients? Describe your DNS topology, including domains, nameservers, which sites which nameservers are at, and which nameservers which clients are configured to use. You can substitute names if you want, but be complete. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
