Cannot join domain or browse network shares from different subnet

  • Thread starter Thread starter Mike
  • Start date Start date
M

Mike

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

(e-mail address removed)
 
Mike said:
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

(e-mail address removed)

Remember, Active Directory and clients need DNS to work properly.
They'll fall back to NetBIOS, but it's broadcast based (WINS does not
have an equivelant to DNS SRV records). Can you resolve the domain using
it's DNS name? I'll bet you a beer it's a DNS configuration issue.

....kurt
 
Kurt said:
Remember, Active Directory and clients need DNS to work properly.
They'll fall back to NetBIOS, but it's broadcast based (WINS does not
have an equivelant to DNS SRV records). Can you resolve the domain using
it's DNS name? I'll bet you a beer it's a DNS configuration issue.

...kurt


Kurt,

sb-ro-pc1 has it's DNS server set to 192.168.0.12 by DHCP and can
resolve sb-ho-srv1 and sb-ho-srv1.sb.local

Regards,
Mike
 
Kurt said:
Remember, Active Directory and clients need DNS to work properly.
They'll fall back to NetBIOS, but it's broadcast based (WINS does not
have an equivelant to DNS SRV records). Can you resolve the domain using
it's DNS name? I'll bet you a beer it's a DNS configuration issue.

...kurt

You were correct that it was a DNS issue. Whilst an nslookup of the A
record was working, a domain join or UNC browse caused a much larger
reply to be returned from the DNS server. This was causing the VPN end
points to drop the reply at they had incorrectly set MTUs. Dropped the
MTU down to 1400 for the IPSec interfaces on the VPN end points and it
all started working. Thanks for your reply and here is your beer.

.sssssssss.
.sssssssssssssssssss
sssssssssssssssssssssssss
ssssssssssssssssssssssssssss
@@sssssssssssssssssssssss@ss
|s@@@@sssssssssssssss@@@@s|s
_______|sssss@@@@@sssss@@@@@sssss|s
/ sssssssss@sssss@sssssssss|s
/ .------+.ssssssss@sssss@ssssssss.|
/ / |...sssssss@sss@sssssss...|
| | |.......sss@sss@ssss......|
| | |..........s@ss@sss.......|
| | |...........@ss@..........|
\ \ |............ss@..........|
\ '------+...........ss@...........|
\________ .........................|
|.........................|
/...........................\
|.............................|
|.......................|
|...............|

Mike
 
Mike said:
You were correct that it was a DNS issue. Whilst an nslookup of the A
record was working, a domain join or UNC browse caused a much larger
reply to be returned from the DNS server. This was causing the VPN end
points to drop the reply at they had incorrectly set MTUs. Dropped the
MTU down to 1400 for the IPSec interfaces on the VPN end points and it
all started working. Thanks for your reply and here is your beer.

.sssssssss.
.sssssssssssssssssss
sssssssssssssssssssssssss
ssssssssssssssssssssssssssss
@@sssssssssssssssssssssss@ss
|s@@@@sssssssssssssss@@@@s|s
_______|sssss@@@@@sssss@@@@@sssss|s
/ sssssssss@sssss@sssssssss|s
/ .------+.ssssssss@sssss@ssssssss.|
/ / |...sssssss@sss@sssssss...|
| | |.......sss@sss@ssss......|
| | |..........s@ss@sss.......|
| | |...........@ss@..........|
\ \ |............ss@..........|
\ '------+...........ss@...........|
\________ .........................|
|.........................|
/...........................\
|.............................|
|.......................|
|...............|

Mike

I don't deserve the beer. It really wasn't a DNS issue, rather an MTU
issue, but I'm glad you found the problem, very good work actually.


....kurt
 
Back
Top