Cannot join domain or browse network shares from different..

Greetings All,

I am having some problems trying to connect a PC on a different subnet
to a SBS 2003 server across a VPN. To summarise the setup.

Head Office
-----------
Subnet: 192.168.0.0/24
NetBIOS domain name: SMALLBIZ
SBS Server Host Name: sb-ho-srv1
DNS suffix: sb.local
SBS Server IP: 192.168.0.12
Windows firewall: disabled
Default gateway: 192.168.0.1

Remote Office
-------------
Subnet: 192.168.1.0/24
PC Client name: sb-ro-pc1
PC client OS: XP SP2
DNS suffix: sb.local
PC Client IP (DHCP): 192.168.1.100
Windows firewall: disabled
DHCP Assigned DNS server: 192.168.0.12
DHCP Assigned WINS server: 192.168.0.12
Default gateway: 192.168.1.1

VPN
---
IPSec VPN between 2 Smoothwall boxes.
Smoothwall IP address at Head Office: 192.168.0.1
Smoothwall IP address at Remote Office: 192.168.1.1
IP connectivity between the two subnets appears to the OK using ping,
SSH, RDP, DNS and VNC.


The Problem
-----------

Scenario 1:
If sb-ro-pc1 is connected to the 192.168.0.0/24 subnet for testing, it
will join the domain and connect to network shares OK.

Scenario 2:
If sb-ro-pc1 is connected to the 192.168.1.0/24 across a Smoothwall VPN -
1. When trying to join the SMALLBIZ domain, I get this error "The
following error occurred attempting to join the domain 'SMALLBIZ": The
specified network name is no longer available"
2. If sb-ro-pc1 is joined to the domain successfully inside
192.168.0.0/24 and then taken to 192.168.1.0/24 on the other side of the
VPN, network names like \\sb-ho-srv1\home$\test cannot be mapped,
however using a UNC like \\192.168.0.12\home$\test works OK.
3. Both sb-ho-srv1 and sb-ro-pc1 can ping each other by name and IP
across the VPN.
4. Running "nbtstat -RR" on sb-ro-pc1 successfully updates it's record
on the WINS server running on sb-ho-srv1


Solutions Investigated
----------------------
1. Searches of Google and Technet tend to point toward making sure that
the WINS setup is correct. The fact that the nbtstat command is
successfully refreshing the client record on the WINS server would
suggest that this is correct.
2. Firewall is blocking traffic from outside the subnet. Disabled
Windows Firewall on server and client. The fact that
\\192.168.0.12\home$\test style UNCs are working would suggest that I
have not missed another software firewall that has been installed.



Thoughts - Advice Requested
---------------------------
1. This still looks like a name resolution problem, but I cannot put my
finger on it. DNS works. WINS appears to be working. Broadcasts? Is
that not was setting a WINS server is for?
2. MTU. It is possible that the VPN overhead is messing around with
the Windows MTU parameter causing packet loss? Has anybody experience
with this?
3. Any advice would be greatly appreciated.


Thanks,
Mike

service.dropthisbitspam.DeleteThis@redterra.net

It's all DNS. The client will need to point towards the
DNS server on the remote machine. If you have a DNS
server in each location you could make one a secondary
of the other to resolve your issue.

"Mike" <none RemoveThis @email.com> wrote in message
news:45762ae9@news1.homechoice.co.uk...
> Greetings All,
>
> I am having some problems trying to connect a PC on a different subnet to
> a SBS 2003 server across a VPN. To summarise the setup.
>
> Head Office
> -----------
> Subnet: 192.168.0.0/24
> NetBIOS domain name: SMALLBIZ
> SBS Server Host Name: sb-ho-srv1
> DNS suffix: sb.local
> SBS Server IP: 192.168.0.12
> Windows firewall: disabled
> Default gateway: 192.168.0.1
>
> Remote Office
> -------------
> Subnet: 192.168.1.0/24
> PC Client name: sb-ro-pc1
> PC client OS: XP SP2
> DNS suffix: sb.local
> PC Client IP (DHCP): 192.168.1.100
> Windows firewall: disabled
> DHCP Assigned DNS server: 192.168.0.12
> DHCP Assigned WINS server: 192.168.0.12
> Default gateway: 192.168.1.1
>
> VPN
> ---
> IPSec VPN between 2 Smoothwall boxes.
> Smoothwall IP address at Head Office: 192.168.0.1
> Smoothwall IP address at Remote Office: 192.168.1.1
> IP connectivity between the two subnets appears to the OK using ping, SSH,
> RDP, DNS and VNC.
>
>
> The Problem
> -----------
>
> Scenario 1:
> If sb-ro-pc1 is connected to the 192.168.0.0/24 subnet for testing, it
> will join the domain and connect to network shares OK.
>
> Scenario 2:
> If sb-ro-pc1 is connected to the 192.168.1.0/24 across a Smoothwall VPN -
> 1. When trying to join the SMALLBIZ domain, I get this error "The
> following error occurred attempting to join the domain 'SMALLBIZ": The
> specified network name is no longer available"
> 2. If sb-ro-pc1 is joined to the domain successfully inside
> 192.168.0.0/24 and then taken to 192.168.1.0/24 on the other side of the
> VPN, network names like \\sb-ho-srv1\home$\test cannot be mapped, however
> using a UNC like \\192.168.0.12\home$\test works OK.
> 3. Both sb-ho-srv1 and sb-ro-pc1 can ping each other by name and IP
> across the VPN.
> 4. Running "nbtstat -RR" on sb-ro-pc1 successfully updates it's record on
> the WINS server running on sb-ho-srv1
>
>
> Solutions Investigated
> ----------------------
> 1. Searches of Google and Technet tend to point toward making sure that
> the WINS setup is correct. The fact that the nbtstat command is
> successfully refreshing the client record on the WINS server would suggest
> that this is correct.
> 2. Firewall is blocking traffic from outside the subnet. Disabled
> Windows Firewall on server and client. The fact that
> \\192.168.0.12\home$\test style UNCs are working would suggest that I have
> not missed another software firewall that has been installed.
>
>
>
> Thoughts - Advice Requested
> ---------------------------
> 1. This still looks like a name resolution problem, but I cannot put my
> finger on it. DNS works. WINS appears to be working. Broadcasts? Is
> that not was setting a WINS server is for?
> 2. MTU. It is possible that the VPN overhead is messing around with the
> Windows MTU parameter causing packet loss? Has anybody experience with
> this?
> 3. Any advice would be greatly appreciated.
>
>
> Thanks,
> Mike
>
> service.dropthisbitspam RemoveThis @redterra.net
>
>
>