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 Removed)

Mike wrote:
> 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 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 wrote:
> Mike wrote:
>> 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 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,

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 wrote:
> Mike wrote:
>> 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 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

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 wrote:
> Kurt wrote:
>> Mike wrote:
>>> 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 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
>
> 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