|
||||||||
On Thu, 8 Jul 2004, Aaron Tunnell wrote: > > I set up PPTP VPN according to the directions, below is my configuration on > the Monowall box. I can connect to my monowall from work via the built in > WinXP client, but I cannot see any of my computers that are behind the > monowall in network neighborhood. Any idea why I can connect but cant see > anything? I set up the addresses as best I could figure, but I may have a > conflict on my subnets. So here is my config, any ideas? > > Gateway Lan address 192.168.50.1 > DHCP range is 192.168.50.5-192.168.50.100 > My server VPN address is 192.168.50.101 > And my Client VPN assigned address is 192.168.50.144 > > The subnet at work where I am connecting form is in the 192.168.2.x range is > this a conflict with the above? Thanks for any help! On Fri, 9 Jul 2004, Aaron Tunnell wrote: > Well I tried both suggestions. I changed my VPN config to a new subnet in > the 51 range. And I created a LMHOSTS file on the XP client that mapped > 192.168.50.100 to the server. But I still cant see anything on the remote > network after I successfully connect. Any more ideas?-Aaron > > Gateway Lan address 192.168.50.1 > DHCP range is 192.168.50.5-192.168.50.100 > My server VPN address is 192.168.51.101 > And my Client VPN assigned address is 192.168.51.144 You have to walk before you can run. :-) Don't even *think* about something as complicated as Windows networking until you have basic stuff like pings working. Fixing the subnet for the VPN is a step in the right direction, but: 1) Do all machines in question have /24 netmasks? 2) Does the VPN client either have 192.168.51.101 as its default gateway (perhaps acquired automatically via PPP/PPTP), or have a static route to 192.168.50/24 via 192.168.51.101? 3) Does each machine of interest on the LAN have 192.168.50.1 as the default gateway, or have a static route to 192.168.51/24 via 192.168.50.1? And make sure pings (at least) are allowed through the firewall. Once you have pings working, then (firewall permitting) you should be able to mount shares via the \\<IP address>\<sharename> syntax, which is ugly but usable. If the intent is just to map it to a drive letter, then that might even be adequate. For "Network Neighborhood" to work, you need *both* NetBIOS name resolution *and* browse service working. You can use the LMHOSTS approach to substitute for WINS service (broadcast name resolution obviously doesn't work across subnets), but that still doesn't give you browsing. All it does is allow you to use <computer name> instead of <IP address> above, which is really no better than DNS or hosts entries. For browsing to work, you need each subnet to have a Local Master Browser which is aware of the other and exchanges browse lists with it. With Samba this can be configured explicitly, but not AFAIK in Windows. *But*, I *think* that if each side has a name registration for the other's LMB with the proper magic suffix (0x1D) designating it as an LMB, then they'll find each other and "do the right thing". Not that I've tried this, though. In the absence of cross-subnet WINS service, this means that the LMB on each side needs an LMHOSTS entry for the other LMB. Complicating this is that LMBs aren't explicitly configured, but instead are chosen automatically by an "election" process (again, Samba provides some additional flexibility here), so this approach could turn into a maintenance nightmare. Fred Wright |