> > >Maybe I'm confused here. Let me explain what I am trying to do. I have to
> > >locations at location A I have a subnet of 192.168.1.0/24 at location B I
> > >have a subnet of 192.168.20/24. Presently I am able to ping from
> > >192.168.1.100 to 192.168.2.100, thus the IP layer is working.
> > >
> > >In addition to this I need for the Windows machines to be able to mount
> > >shares. If I understand that part of it correctly, it's a non routable (sub
> > >IP) protocol. So I need for the Non IP Ethernet frames to be bridged
> > >between the 2 locations , right?
> >
> > You might be confused. Access to Windows shares uses SMB (or more
> > recently CIFS) protcols coupled with NetBIOS name query & RPC calls,
> > all of which are routable. Otherwise you wouldn't be able to connect
> > to a file server on a different subnet than your client (common in all
> > networks except for the smallest.)
> >
> > At any rate, all of the above is most certainly IP-based.
>
> Hmm, well I have never been able to connect to a Widnows "share" on another
> subnet, even if I used the IP address. I recognixethat there are issues
> wirh Windoes equiv. of DNS (WIns etc).
Well, It Works For Me [TM]. Actually, our office network is divided into
several subnets, and the Windows fileserver is on another subnet in a remote
data centre, several IP hops away, and it all still works.
Locating a machine by name ("Network Neighbourhood") requires either a WINS
server or dynamic DNS, but you've realised that. Mount by IP address should
just work.
So if it doesn't work for you, I'd try using tcpdump and/or ethereal to see
what packets are being sent, and checking that they're being forwarded
properly.
IMO you will end up with a much better solution using routing rather than
bridging, as it will scale much better. You will avoid all those nasty
Windows NETBIOS naming broadcasts being forwarded down your VPN tunnel for a
start.
Regards,
Brian.
