DNS and NetBIOS names not resolving over a PPTP VPN using RRAS

Short question: How does one enable the resolution of DNS and NetBIOS
names on a remote network from a client over a PPTP VPN?

Backstory:

I have a PPTP VPN facilitated by a Windows Server 2003 machine with
RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
NetBIOS and DNS names other than the server's are not being resolved
even though they once were. In other words, the command 'net view
[RRAS server name]' will respond, however 'net view [any other
computer name on the VPN's network]' will not respond. I get the error
message "System error 53 has occurred. The network path was not
found." Virtually the same thing happens with DNS. 'ping [RRAS
server]' resolves nicely, but pinging anything else gets "Ping request
could not find host accounting. Please check the name and try again."

As I said, there was a time in the recent past that DNS and NetBIOS
resolved over the VPN connection. I’m not aware of any changes that
have been made that would affect this. I've tried setting the remote
gateway as the default gateway and even setting the DNS server on the
VPN's network as my primary DNS server and still can't get any DNS
names to resolve. However, using nslookup with the remote location's
DNS server will get each name in question to resolve. Hmmmm.

Oddly enough, I have an entirely different PPTP VPN connection (this
time the VPN facilitator is an ISA 2004 server) that behaves the way
that I want it to. DNS and NetBIOS names resolve with or without the
remote gateway being my default gateway and without the remote DNS
servers being on the list of my LAN interface’s DNS servers and with
the option to register my connection’s addresses in DNS left
unchecked. There is no discernable difference between the connectoids
for the two VPN connections.

Again, how does one get remote NetBIOS and DNS names to resolve
through a VPN connection? I thought I knew, but apparently I
don't. :-|

On May 26, 9:49 pm, [email protected] wrote:
> Short question: How does one enable the resolution of DNS and NetBIOS
> names on a remote network from a client over a PPTP VPN?
>
> Backstory:
>
> I have a PPTP VPN facilitated by a Windows Server 2003 machine with
> RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
> NetBIOS and DNS names other than the server's are not being resolved
> even though they once were. In other words, the command 'net view
> [RRAS server name]' will respond, however 'net view [any other
> computer name on the VPN's network]' will not respond. I get the error
> message "System error 53 has occurred. The network path was not
> found." Virtually the same thing happens with DNS. 'ping [RRAS
> server]' resolves nicely, but pinging anything else gets "Ping request
> could not find host accounting. Please check the name and try again."
>
> As I said, there was a time in the recent past that DNS and NetBIOS
> resolved over the VPN connection. I’m not aware of any changes that
> have been made that would affect this. I've tried setting the remote
> gateway as the default gateway and even setting the DNS server on the
> VPN's network as my primary DNS server and still can't get any DNS
> names to resolve. However, using nslookup with the remote location's
> DNS server will get each name in question to resolve. Hmmmm.
>
> Oddly enough, I have an entirely different PPTP VPN connection (this
> time the VPN facilitator is an ISA 2004 server) that behaves the way
> that I want it to. DNS and NetBIOS names resolve with or without the
> remote gateway being my default gateway and without the remote DNS
> servers being on the list of my LAN interface’s DNS servers and with
> the option to register my connection’s addresses in DNS left
> unchecked. There is no discernable difference between the connectoids
> for the two VPN connections.
>
> Again, how does one get remote NetBIOS and DNS names to resolve
> through a VPN connection? I thought I knew, but apparently I
> don't. :-|

I forgot to mention that using \\IP_Address\ from the VPN client to an
IP address on the remote netework is successful. That may have been
obvious, but I figured I'd say it anyway.

The RRAS with correct DNS and WINS settings should assign DNS and WINS to
VPN client. These search result may help.
Name resolution on VPN
Name resolution is big issue in VPN access. If your VPN server doesn't
setup correctly or the VPN client can't receive the VPN DNS and WINS
settings, ...
www.chicagotech.net/nameresolutionpnvpn.htm - Similar pages

VPN name resolution and browsing
Q: VPN name resolution and browsing. After I successfully connect to
the VPN Server remotely, I cannot browse the network, and see other
computers and ...
www.chicagotech.net/Q&A/vpn1.htm


--
Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on
http://www.HowToNetworking.com
<[email protected]> wrote in message
news:b5c38d07-9d87-4b1a-b38a-95ade2040ad7@z66g2000hsc.googlegroups.com...
Short question: How does one enable the resolution of DNS and NetBIOS
names on a remote network from a client over a PPTP VPN?

Backstory:

I have a PPTP VPN facilitated by a Windows Server 2003 machine with
RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
NetBIOS and DNS names other than the server's are not being resolved
even though they once were. In other words, the command 'net view
[RRAS server name]' will respond, however 'net view [any other
computer name on the VPN's network]' will not respond. I get the error
message "System error 53 has occurred. The network path was not
found." Virtually the same thing happens with DNS. 'ping [RRAS
server]' resolves nicely, but pinging anything else gets "Ping request
could not find host accounting. Please check the name and try again."

As I said, there was a time in the recent past that DNS and NetBIOS
resolved over the VPN connection. I’m not aware of any changes that
have been made that would affect this. I've tried setting the remote
gateway as the default gateway and even setting the DNS server on the
VPN's network as my primary DNS server and still can't get any DNS
names to resolve. However, using nslookup with the remote location's
DNS server will get each name in question to resolve. Hmmmm.

Oddly enough, I have an entirely different PPTP VPN connection (this
time the VPN facilitator is an ISA 2004 server) that behaves the way
that I want it to. DNS and NetBIOS names resolve with or without the
remote gateway being my default gateway and without the remote DNS
servers being on the list of my LAN interface’s DNS servers and with
the option to register my connection’s addresses in DNS left
unchecked. There is no discernable difference between the connectoids
for the two VPN connections.

Again, how does one get remote NetBIOS and DNS names to resolve
through a VPN connection? I thought I knew, but apparently I
don't. :-|

Also this one.
How to enable name resolution
For a VPN client to can resolve full computer name and NetBIOS name of
computers on a remote network automatically, you can enable broadcast name
resolution ...
http://www.howtonetworking.com/VPN/v...esolution1.htm


--
Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on
http://www.HowToNetworking.com
<[email protected]> wrote in message
news:[email protected]...
On May 26, 9:49 pm, [email protected] wrote:
> Short question: How does one enable the resolution of DNS and NetBIOS
> names on a remote network from a client over a PPTP VPN?
>
> Backstory:
>
> I have a PPTP VPN facilitated by a Windows Server 2003 machine with
> RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
> NetBIOS and DNS names other than the server's are not being resolved
> even though they once were. In other words, the command 'net view
> [RRAS server name]' will respond, however 'net view [any other
> computer name on the VPN's network]' will not respond. I get the error
> message "System error 53 has occurred. The network path was not
> found." Virtually the same thing happens with DNS. 'ping [RRAS
> server]' resolves nicely, but pinging anything else gets "Ping request
> could not find host accounting. Please check the name and try again."
>
> As I said, there was a time in the recent past that DNS and NetBIOS
> resolved over the VPN connection. I’m not aware of any changes that
> have been made that would affect this. I've tried setting the remote
> gateway as the default gateway and even setting the DNS server on the
> VPN's network as my primary DNS server and still can't get any DNS
> names to resolve. However, using nslookup with the remote location's
> DNS server will get each name in question to resolve. Hmmmm.
>
> Oddly enough, I have an entirely different PPTP VPN connection (this
> time the VPN facilitator is an ISA 2004 server) that behaves the way
> that I want it to. DNS and NetBIOS names resolve with or without the
> remote gateway being my default gateway and without the remote DNS
> servers being on the list of my LAN interface’s DNS servers and with
> the option to register my connection’s addresses in DNS left
> unchecked. There is no discernable difference between the connectoids
> for the two VPN connections.
>
> Again, how does one get remote NetBIOS and DNS names to resolve
> through a VPN connection? I thought I knew, but apparently I
> don't. :-|

I forgot to mention that using \\IP_Address\ from the VPN client to an
IP address on the remote netework is successful. That may have been
obvious, but I figured I'd say it anyway.

On May 27, 9:21 am, "Robert L. \(MS-MVP\)" <[email protected]>
wrote:
> Also this one.
> How to enable name resolution
> For a VPN client to can resolve full computer name and NetBIOSname of
> computers on a remote network automatically, you can enable broadcast name
> resolution ...
> http://www.howtonetworking.com/VPN/v...esolution1.htm
>
> --
> Bob Lin, MS-MVP, MCSE & CNE
> Networking, Internet, Routing, VPN Troubleshooting onhttp://www.ChicagoTech.net
> How to Setup Windows, Network, VPN & Remote Access onhttp://www.HowToNetworking.com<[email protected]> wrote in message
>
> news:[email protected]...
> On May 26, 9:49 pm, [email protected] wrote:
>
>
>
> > Short question: How does one enable the resolution of DNS and NetBIOS
> > names on a remote network from a client over a PPTP VPN?
>
> > Backstory:
>
> > I have a PPTP VPN facilitated by a Windows Server 2003 machine with
> > RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
> > NetBIOS and DNS names other than the server's are not being resolved
> > even though they once were. In other words, the command 'net view
> > [RRAS server name]' will respond, however 'net view [any other
> > computer name on the VPN's network]' will not respond. I get the error
> > message "System error 53 has occurred. The network path was not
> > found." Virtually the same thing happens with DNS. 'ping [RRAS
> > server]' resolves nicely, but pinging anything else gets "Ping request
> > could not find host accounting. Please check the name and try again."
>
> > As I said, there was a time in the recent past that DNS and NetBIOS
> > resolved over the VPN connection. I’m not aware of any changes that
> > have been made that would affect this. I've tried setting the remote
> > gateway as the default gateway and even setting the DNS server on the
> > VPN's network as my primary DNS server and still can't get any DNS
> > names to resolve. However, using nslookup with the remote location's
> > DNS server will get each name in question to resolve. Hmmmm.
>
> > Oddly enough, I have an entirely different PPTP VPN connection (this
> > time the VPN facilitator is an ISA 2004 server) that behaves the way
> > that I want it to. DNS and NetBIOS names resolve with or without the
> > remote gateway being my default gateway and without the remote DNS
> > servers being on the list of my LAN interface’s DNS servers and with
> > the option to register my connection’s addresses in DNS left
> > unchecked. There is no discernable difference between the connectoids
> > for the two VPN connections.
>
> > Again, how does one get remote NetBIOS and DNS names to resolve
> > through a VPN connection? I thought I knew, but apparently I
> > don't. :-|
>
> I forgot to mention that using \\IP_Address\ from the VPN client to an
> IP address on the remote netework is successful. That may have been
> obvious, but I figured I'd say it anyway.

On May 27, 9:21 am, "Robert L. \(MS-MVP\)" <[email protected]>
wrote:
> Also this one.
> How to enable name resolution
> For a VPN client to can resolve full computer name and NetBIOSname of
> computers on a remote network automatically, you can enable broadcast name
> resolution ...
> http://www.howtonetworking.com/VPN/v...esolution1.htm
>
> --
> Bob Lin, MS-MVP, MCSE & CNE
> Networking, Internet, Routing, VPN Troubleshooting onhttp://www.ChicagoTech.net
> How to Setup Windows, Network, VPN & Remote Access onhttp://www.HowToNetworking.com<[email protected]> wrote in message
>
> news:[email protected]...
> On May 26, 9:49 pm, [email protected] wrote:
>
>
>
> > Short question: How does one enable the resolution of DNS and NetBIOS
> > names on a remote network from a client over a PPTP VPN?
>
> > Backstory:
>
> > I have a PPTP VPN facilitated by a Windows Server 2003 machine with
> > RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
> > NetBIOS and DNS names other than the server's are not being resolved
> > even though they once were. In other words, the command 'net view
> > [RRAS server name]' will respond, however 'net view [any other
> > computer name on the VPN's network]' will not respond. I get the error
> > message "System error 53 has occurred. The network path was not
> > found." Virtually the same thing happens with DNS. 'ping [RRAS
> > server]' resolves nicely, but pinging anything else gets "Ping request
> > could not find host accounting. Please check the name and try again."
>
> > As I said, there was a time in the recent past that DNS and NetBIOS
> > resolved over the VPN connection. I’m not aware of any changes that
> > have been made that would affect this. I've tried setting the remote
> > gateway as the default gateway and even setting the DNS server on the
> > VPN's network as my primary DNS server and still can't get any DNS
> > names to resolve. However, using nslookup with the remote location's
> > DNS server will get each name in question to resolve. Hmmmm.
>
> > Oddly enough, I have an entirely different PPTP VPN connection (this
> > time the VPN facilitator is an ISA 2004 server) that behaves the way
> > that I want it to. DNS and NetBIOS names resolve with or without the
> > remote gateway being my default gateway and without the remote DNS
> > servers being on the list of my LAN interface’s DNS servers and with
> > the option to register my connection’s addresses in DNS left
> > unchecked. There is no discernable difference between the connectoids
> > for the two VPN connections.
>
> > Again, how does one get remote NetBIOS and DNS names to resolve
> > through a VPN connection? I thought I knew, but apparently I
> > don't. :-|
>
> I forgot to mention that using \\IP_Address\ from the VPN client to an
> IP address on the remote netework is successful. That may have been
> obvious, but I figured I'd say it anyway.

Thanks for your time,

Let me see if I understand the situation correctly. Supposedly,
whatever DNS and WINS wettings are on the VPN server will be inherited
by all VPN clients. What if the VPN server has more than one network
card? Which interface will the information be inherited from? As one
article on ChicagoTech.net said "If name resolution does not work from
the VPN server, it will not work for VPN clients." However, in my
situation, the RRAS server is functioning perfectly in every other
way.

Also, when I attempted to manually set the DNS server properties in
the VPN connection, I noticed that they were not there since the
connectoid is a CMAK creation. I'm quickly becoming less and less
enchanted with CMAK. Moving on... I created a new VPN connection the
old-fashined way and manually set the DNS server settings with no
success.

Here's what puzzles me. I have a separate DHCP server on the remote
network. I set up RRAS with the relay agent turned on. My DHCP server
shows that the RRAS server likes to grab 9 DHCP leases at a time. That
is in-line with my understanding of RRAS; it's supposed to do that,
right? However, when I look at the status of the VPN connection on a
client machine to see what IP address it is connecting to, it shows an
IP address that is definitely NOT my VPN server. The IP address is
acually one of the 9 that RRAS server too from DHCP. I double-checked
to make sure that my eyes were not deceiving me.

That made me think that maybe there was some mistake in how I set up
the DHCP relay agent. I checked and noticed two interfaces in the
relay agent console; "Local Area Connection" and "Internal". Not
knowing exactly what Internal did, I disabled it (yeah, bad
troubleshooting practice. I know, I know...). An ipconfig /all reveals
that the server has two interfaces, one is the LAN connection and the
second is a "PPP adapter RAS Server (Dial in) Interface" and it seems
to be using one of the 9 DHCP addresses that it got from the DHCP
server. Okay, so should that interface have DNS/WINS info put in it?
It's not in my network connections folder nor can I tweak it in netsh
because netsh doesn't show it.

Flustered, I turned off the DHCP relay agent, made a static pool of
addresses and retried. Same symptoms. The PPP adapter uses the first
IP in the static pool, client machines grab up the rest and no DNS or
NetBIOS is resolving over the VPN. Argh. Should I install DNS and WINS
on the VPN server? Why did this work at one point in the past but not
now? Stray Alpha particles?

I'm stonewalled. Anyone have any ideas? <X_x>

<[email protected]> wrote in message
news:c2fd66e1-4161-449b-b2c5-13172b3958e6@l28g2000prd.googlegroups.com...
Let me see if I understand the situation correctly. Supposedly,
whatever DNS and WINS wettings are on the VPN server will be inherited
by all VPN clients.

[Phil] No.

What if the VPN server has more than one network
card?

[Phil] Not relevant

Which interface will the information be inherited from?

[Phil] It is not "inherited". The client get its config from DHCP combined
with the DHCP Relay Agent.

connectoid is a CMAK creation. I'm quickly becoming less and less
enchanted with CMAK. Moving on... I created a new VPN connection the

[Phil] Never used CMAK, was never interested in it,..so I can't help you
with that.

Here's what puzzles me. I have a separate DHCP server on the remote
network. I set up RRAS with the relay agent turned on. My DHCP server
shows that the RRAS server likes to grab 9 DHCP leases at a time.

[Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4 L2TP)
plus one for the RRAS "internal" interface which gives you 9.

IP address that is definitely NOT my VPN server.

[Phil] Not supposed to be

The IP address is acually one of the 9 that RRAS server too from DHCP.

[Phil] Supposed to be

the DHCP relay agent. I checked and noticed two interfaces in the
relay agent console; "Local Area Connection" and "Internal".

[Phil] Supposed to be that way. This is probably the Root of all your
trouble. I think for the DHCP Relay Agent to work correctly it needs to be
set to Local Area Connection because that is the interface that "faces" the
DHCP Server that the agent needs to do all of its "agent-ing" with. But I
could be wrong,...try that first, if it doesn't work set it to "internal".

second is a "PPP adapter RAS Server (Dial in) Interface" and it seems
to be using one of the 9 DHCP addresses that it got from the DHCP
server. Okay, so should that interface have DNS/WINS info put in it?

[Phil] No. Supposed to be *left alone*

Flustered, I turned off the DHCP relay agent,

[Phil] Turn it back on

made a static pool of
addresses and retried. Same symptoms. The PPP adapter uses the first
IP in the static pool, client machines grab up the rest and no DNS or
NetBIOS is resolving over the VPN. Argh.

[Phil] Get rid of the Pool

Should I install DNS and WINS on the VPN server?

[Phil] No. I believe the Root of your problem was the interface that the
DHCP Relay Agent was associated with. It is really fairly
simple,...correctly configure the DHCP Relay Agent,...and the Clients get
the same IP Config from the same DHCP Scope as all the other machines on the
same IP segment on the LAN,...that's it,..it's that simple,...so the more
complex your "solution", the less likely it is the correct solution.

The DHCP Relay Agent is not required the get an IP#,...you can get that
without the Agent. But you need the Agent to get DHCP Options (like WINS,
DNS, etc). Without the Agent all you get is the IP#.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

On May 27, 4:45 pm, "Phillip Windell" <[email protected]> wrote:
> <[email protected]> wrote in message
>
> news:c2fd66e1-4161-449b-b2c5-13172b3958e6@l28g2000prd.googlegroups.com...
> Let me see if I understand the situation correctly. Supposedly,
> whatever DNS and WINS wettings are on the VPN server will be inherited
> by all VPN clients.
>
> [Phil] No.
>
> What if the VPN server has more than one network
> card?
>
> [Phil] Not relevant
>
> Which interface will the information be inherited from?
>
> [Phil] It is not "inherited". The client get its config from DHCP combined
> with the DHCP Relay Agent.
>
> connectoid is a CMAK creation. I'm quickly becoming less and less
> enchanted with CMAK. Moving on... I created a new VPN connection the
>
> [Phil] Never used CMAK, was never interested in it,..so I can't help you
> with that.
>
> Here's what puzzles me. I have a separate DHCP server on the remote
> network. I set up RRAS with the relay agent turned on. My DHCP server
> shows that the RRAS server likes to grab 9 DHCP leases at a time.
>
> [Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4 L2TP)
> plus one for the RRAS "internal" interface which gives you 9.
>
> IP address that is definitely NOT my VPN server.
>
> [Phil] Not supposed to be
>
> The IP address is acually one of the 9 that RRAS server too from DHCP.
>
> [Phil] Supposed to be
>
> the DHCP relay agent. I checked and noticed two interfaces in the
> relay agent console; "Local Area Connection" and "Internal".
>
> [Phil] Supposed to be that way. This is probably the Root of all your
> trouble. I think for the DHCP Relay Agent to work correctly it needs tobe
> set to Local Area Connection because that is the interface that "faces" the
> DHCP Server that the agent needs to do all of its "agent-ing" with. ButI
> could be wrong,...try that first, if it doesn't work set it to "internal".
>
> second is a "PPP adapter RAS Server (Dial in) Interface" and it seems
> to be using one of the 9 DHCP addresses that it got from the DHCP
> server. Okay, so should that interface have DNS/WINS info put in it?
>
> [Phil] No. Supposed to be *left alone*
>
> Flustered, I turned off the DHCP relay agent,
>
> [Phil] Turn it back on
>
> made a static pool of
> addresses and retried. Same symptoms. The PPP adapter uses the first
> IP in the static pool, client machines grab up the rest and no DNS or
> NetBIOS is resolving over the VPN. Argh.
>
> [Phil] Get rid of the Pool
>
> Should I install DNS and WINS on the VPN server?
>
> [Phil] No. I believe the Root of your problem was the interface that the
> DHCP Relay Agent was associated with. It is really fairly
> simple,...correctly configure the DHCP Relay Agent,...and the Clients get
> the same IP Config from the same DHCP Scope as all the other machines on the
> same IP segment on the LAN,...that's it,..it's that simple,...so the more
> complex your "solution", the less likely it is the correct solution.
>
> The DHCP Relay Agent is not required the get an IP#,...you can get that
> without the Agent. But you need the Agent to get DHCP Options (like WINS,
> DNS, etc). Without the Agent all you get is the IP#.
>
> --
> Phillip Windellwww.wandtv.com
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------



>> [Phil] It is not "inherited". The client get its config from DHCP combined
with the DHCP Relay Agent. <<

That would make sense. I was a bit confused by the following
however...

Quoth ChicagoTech.net:
"
Name resolution Issue in a VPN client

To assign the DNS and WINS to a VPN client for name resolution, you
should configure VPN server with the IP addresses of the appropriate
DNS and WINS servers. The VPN client inherits the DNS and WINS
configured on the VPN server. If name resolution does not work from
the VPN server, it will not work for VPN clients.
"

Does that mean that DNS/WINS information is inherited only when the
VPN client gets a static IP from the RRAS server? On the surface,
there seems to be a contradiction in what I'm hearing.


>> [Phil] Never used CMAK, was never interested in it,..so I can't help you
with that. <<

How do you deploy VPN connectoids to clients? Or maybe that's
something that you don't have to do in your situation.


>>[Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4 L2TP)
plus one for the RRAS "internal" interface which gives you 9.<<

Oddly enough, I've got 1 WAN Miniport (PPPOE), 128 PPTP ports, 128
L2TP ports, and 1 Direct Parallel port.


>> the DHCP relay agent. I checked and noticed two interfaces in the
relay agent console; "Local Area Connection" and "Internal".

[Phil] Supposed to be that way. This is probably the Root of all
your
trouble. I think for the DHCP Relay Agent to work correctly it needs
to be
set to Local Area Connection because that is the interface that
"faces" the
DHCP Server that the agent needs to do all of its "agent-ing" with.
But I
could be wrong,...try that first, if it doesn't work set it to
"internal". <<

Just to make sure that we're on the same page; I see "Local Area
Connection" and "Internal" when I select the "DHCP Relay Agent"
heading under "IP Routing" in the RRAS console. Both were set to
"Relay mode: Enabled". For giggles, I disabled "Internal" but that
didn't change anything.

There's a second setting that affects DHCP. If you right-click >>
properties the RRAS server in the RRAS console and then select the
"IP" tab you'll see at the bottom a place where you can select the
interface that is used for getting DHCP for clients. The local area
connection on the LAN is the selected interface. "Internal" is not a
choice here; Only the local area connection and then a 1394 adapter
(Firewire card).


>> Flustered, I turned off the DHCP relay agent,

[Phil] Turn it back on <<

I turned it back on and am successfully getting DHCP to VPN clients.



>> [Phil] Get rid of the Pool <<

Done.


>> [Phil] No. I believe the Root of your problem was the interface that the
DHCP Relay Agent was associated with. It is really fairly
simple,...correctly configure the DHCP Relay Agent,...and the Clients
get
the same IP Config from the same DHCP Scope as all the other machines
on the
same IP segment on the LAN,...that's it,..it's that simple,...so the
more
complex your "solution", the less likely it is the correct solution.<<

Okay, so the only configuration change from my original options is
that under "DHCP Relay Agent" the interface named "Internal" has been
disabled. In the "IP" tab of the RRAS server, the local area
connection is selected as the DHCP interface, but it was selected all
along anyway. That hasn't changed.

I agree about how it should be simple. It just seems that everything
gets more complex than it is. :)



>> The DHCP Relay Agent is not required the get an IP#,...you can get that
without the Agent. But you need the Agent to get DHCP Options (like
WINS,
DNS, etc). Without the Agent all you get is the IP#. <<

I wasn't aware of that.

Could this be a problem with my DHCP server? It's just a LinkSys RV082
that acts as the Gateway, DNS, DHCP, and space heater. That would be
curious since all clients on the LAN get DHCP with options just fine.

Any and all help from anyone and their extended family would be
appreciated. :)


Thanks,

On May 27, 8:59 pm, [email protected] wrote:
> On May 27, 4:45 pm, "Phillip Windell" <[email protected]> wrote:
>
>
>
> > <[email protected]> wrote in message
>
> >news:c2fd66e1-4161-449b-b2c5-13172b3958e6@l28g2000prd.googlegroups.com...
> > Let me see if I understand the situation correctly. Supposedly,
> > whatever DNS and WINS wettings are on the VPN server will be inherited
> > by all VPN clients.
>
> > [Phil] No.
>
> > What if the VPN server has more than one network
> > card?
>
> > [Phil] Not relevant
>
> > Which interface will the information be inherited from?
>
> > [Phil] It is not "inherited". The client get its config from DHCP combined
> > with the DHCP Relay Agent.
>
> > connectoid is a CMAK creation. I'm quickly becoming less and less
> > enchanted with CMAK. Moving on... I created a new VPN connection the
>
> > [Phil] Never used CMAK, was never interested in it,..so I can't help you
> > with that.
>
> > Here's what puzzles me. I have a separate DHCP server on the remote
> > network. I set up RRAS with the relay agent turned on. My DHCP server
> > shows that the RRAS server likes to grab 9 DHCP leases at a time.
>
> > [Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4L2TP)
> > plus one for the RRAS "internal" interface which gives you 9.
>
> > IP address that is definitely NOT my VPN server.
>
> > [Phil] Not supposed to be
>
> > The IP address is acually one of the 9 that RRAS server too from DHCP.
>
> > [Phil] Supposed to be
>
> > the DHCP relay agent. I checked and noticed two interfaces in the
> > relay agent console; "Local Area Connection" and "Internal".
>
> > [Phil] Supposed to be that way. This is probably the Root of all your
> > trouble. I think for the DHCP Relay Agent to work correctly it needs to be
> > set to Local Area Connection because that is the interface that "faces" the
> > DHCP Server that the agent needs to do all of its "agent-ing" with. But I
> > could be wrong,...try that first, if it doesn't work set it to "internal".
>
> > second is a "PPP adapter RAS Server (Dial in) Interface" and it seems
> > to be using one of the 9 DHCP addresses that it got from the DHCP
> > server. Okay, so should that interface have DNS/WINS info put in it?
>
> > [Phil] No. Supposed to be *left alone*
>
> > Flustered, I turned off the DHCP relay agent,
>
> > [Phil] Turn it back on
>
> > made a static pool of
> > addresses and retried. Same symptoms. The PPP adapter uses the first
> > IP in the static pool, client machines grab up the rest and no DNS or
> > NetBIOS is resolving over the VPN. Argh.
>
> > [Phil] Get rid of the Pool
>
> > Should I install DNS and WINS on the VPN server?
>
> > [Phil] No. I believe the Root of your problem was the interface that the
> > DHCP Relay Agent was associated with. It is really fairly
> > simple,...correctly configure the DHCP Relay Agent,...and the Clients get
> > the same IP Config from the same DHCP Scope as all the other machines onthe
> > same IP segment on the LAN,...that's it,..it's that simple,...so the more
> > complex your "solution", the less likely it is the correct solution.
>
> > The DHCP Relay Agent is not required the get an IP#,...you can get that
> > without the Agent. But you need the Agent to get DHCP Options (like WINS,
> > DNS, etc). Without the Agent all you get is the IP#.
>
> > --
> > Phillip Windellwww.wandtv.com
>
> > The views expressed, are my own and not those of my employer, or Microsoft,
> > or anyone else associated with me, including my cats.
> > -----------------------------------------------------
> >> [Phil] It is not "inherited". The client get its config from DHCP combined
>
> with the DHCP Relay Agent. <<
>
> That would make sense. I was a bit confused by the following
> however...
>
> Quoth ChicagoTech.net:
> "
> Name resolution Issue in a VPN client
>
> To assign the DNS and WINS to a VPN client for name resolution, you
> should configure VPN server with the IP addresses of the appropriate
> DNS and WINS servers. The VPN client inherits the DNS and WINS
> configured on the VPN server. If name resolution does not work from
> the VPN server, it will not work for VPN clients.
> "
>
> Does that mean that DNS/WINS information is inherited only when the
> VPN client gets a static IP from the RRAS server? On the surface,
> there seems to be a contradiction in what I'm hearing.
>
> >> [Phil] Never used CMAK, was never interested in it,..so I can't help you
>
> with that. <<
>
> How do you deploy VPN connectoids to clients? Or maybe that's
> something that you don't have to do in your situation.
>
> >>[Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4L2TP)
>
> plus one for the RRAS "internal" interface which gives you 9.<<
>
> Oddly enough, I've got 1 WAN Miniport (PPPOE), 128 PPTP ports, 128
> L2TP ports, and 1 Direct Parallel port.
>
> >> the DHCP relay agent. I checked and noticed two interfaces in the
>
> relay agent console; "Local Area Connection" and "Internal".
>
> [Phil] Supposed to be that way. This is probably the Root of all
> your
> trouble. I think for the DHCP Relay Agent to work correctly it needs
> to be
> set to Local Area Connection because that is the interface that
> "faces" the
> DHCP Server that the agent needs to do all of its "agent-ing" with.
> But I
> could be wrong,...try that first, if it doesn't work set it to
> "internal". <<
>
> Just to make sure that we're on the same page; I see "Local Area
> Connection" and "Internal" when I select the "DHCP Relay Agent"
> heading under "IP Routing" in the RRAS console. Both were set to
> "Relay mode: Enabled". For giggles, I disabled "Internal" but that
> didn't change anything.
>
> There's a second setting that affects DHCP. If you right-click >>
> properties the RRAS server in the RRAS console and then select the
> "IP" tab you'll see at the bottom a place where you can select the
> interface that is used for getting DHCP for clients. The local area
> connection on the LAN is the selected interface. "Internal" is not a
> choice here; Only the local area connection and then a 1394 adapter
> (Firewire card).
>
> >> Flustered, I turned off the DHCP relay agent,
>
> [Phil] Turn it back on <<
>
> I turned it back on and am successfully getting DHCP to VPN clients.
>
> >> [Phil] Get rid of the Pool <<
>
> Done.
>
> >> [Phil] No. I believe the Root of your problem was the interface thatthe
>
> DHCP Relay Agent was associated with. It is really fairly
> simple,...correctly configure the DHCP Relay Agent,...and the Clients
> get
> the same IP Config from the same DHCP Scope as all the other machines
> on the
> same IP segment on the LAN,...that's it,..it's that simple,...so the
> more
> complex your "solution", the less likely it is the correct solution.<<
>
> Okay, so the only configuration change from my original options is
> that under "DHCP Relay Agent" the interface named "Internal" has been
> disabled. In the "IP" tab of the RRAS server, the local area
> connection is selected as the DHCP interface, but it was selected all
> along anyway. That hasn't changed.
>
> I agree about how it should be simple. It just seems that everything
> gets more complex than it is. :)
>
> >> The DHCP Relay Agent is not required the get an IP#,...you can get that
>
> without the Agent. But you need the Agent to get DHCP Options (like
> WINS,
> DNS, etc). Without the Agent all you get is the IP#. <<
>
> I wasn't aware of that.
>
> Could this be a problem with my DHCP server? It's just a LinkSys RV082
> that acts as the Gateway, DNS, DHCP, and space heater. That would be
> curious since all clients on the LAN get DHCP with options just fine.
>
> Any and all help from anyone and their extended family would be
> appreciated. :)
>
> Thanks,

Ack! I forgot to mention that when I "ipconfig /all" on a VPN client
machine, it correctly shows that I have the remote network's DNS
server as that VPN tunnel's primary DNS server. The options are
arriving, but could the packets be stripped out over the VPN?

<[email protected]> wrote in message
news:81e008a3-f81c-4b4c-acf9-<[email protected]...

<Could this be a problem with my DHCP server? It's just a LinkSys RV082
<that acts as the Gateway, DNS, DHCP, and space heater. That would be
<curious since all clients on the LAN get DHCP with options just fine.

<Any and all help from anyone and their extended family would be
<appreciated. :)

The fact that you are running your LAN using a Linksys for DNS and DHCP
sets of alarm bells. Are you also running a domain controller? If you are
you should not be using the Linksys for DNS or DHCP.

Netbios name resolution does not usually work on a WAN link without
WINS. This is because LAN broadcasts do not cross the WAN link, and Netbios
on the LAN uses broadcasts by default.

DNS name resolution usually does work because the remote will get the IP
address of the DNS server when it connects. However this assumes that you
are running a DNS server on your LAN, not just a DNS relay through a NAT
device (such as your Linksys).

On May 27, 9:27 pm, "Bill Grant" <not.available@online> wrote:
> <[email protected]> wrote in message
>
> news:81e008a3-f81c-4b4c-acf9-...
>
> <Could this be a problem with my DHCP server? It's just a LinkSys RV082
> <that acts as the Gateway, DNS, DHCP, and space heater. That would be
> <curious since all clients on the LAN get DHCP with options just fine.
>
> <Any and all help from anyone and their extended family would be
> <appreciated. :)
>
> The fact that you are running your LAN using a Linksys for DNS and DHCP
> sets of alarm bells. Are you also running a domain controller? If you are
> you should not be using the Linksys for DNS or DHCP.
>
> Netbios name resolution does not usually work on a WAN link without
> WINS. This is because LAN broadcasts do not cross the WAN link, and Netbios
> on the LAN uses broadcasts by default.
>
> DNS name resolution usually does work because the remote will get the IP
> address of the DNS server when it connects. However this assumes that you
> are running a DNS server on your LAN, not just a DNS relay through a NAT
> device (such as your Linksys). Reply Reply to author Forward Rate this post:var rh_cc4ac4a6bf232192 =new RAT_RatingHolder('cc4ac4a6bf232192', '0', ''); //-->Text for clearing space
>
> Cancel
>
>
>
>
>
> Send Discard
>
>
>
>
>
> From:[email protected]:
>
> Cc:Followup To:Add Cc|Add Followup-to|Edit SubjectSubject:
>
> Validation:
>
> For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon.Send Discard
>
>
>
>
>
>
>
>
>
>
>
> You mustSign inbefore you can post messages.
>
> To post a message you must firstjoin this group.
>
> Please update your nickname on thesubscription settingspage before posting..
>
> You do not have the permission required to post.
>
> var msg = G2_cardManager._getMessage("cc4ac4a6bf232192"); msg._init("cc4ac4a6bf232192", "#[email protected]", true, "over", true,false, "", 1); msg._setPrev(G2_cardManager._getCard("msg_ea2909e3704de6e5"), 1); msg._addPreLoadHook(function() { this._setPostNeedsCaptcha(true); this.._setIsUsenet(true); this._setBottomPosting(true); }); //-->

This is just a workgroup environment for a small office. (Side Note: a
budget has been set aside for a domain controller for next year.
Yay! )

>> Netbios name resolution does not usually work on a WAN link without
WINS. This is because LAN broadcasts do not cross the WAN link, and
Netbios
on the LAN uses broadcasts by default. <<

What I'm used to is that 'net view' will not bring back netbios names
on a remote network, but 'net view [machineName]' will behave as
expected. It behaves that way on another connection.


>> DNS name resolution usually does work because the remote will get the IP
address of the DNS server when it connects. However this assumes that
you
are running a DNS server on your LAN, not just a DNS relay through a
NAT
device (such as your Linksys). <<

The LinkSys is acting as a DNS server. I'm assuming its just a caching
server that sends recursive queries when it has no cached rseponse. It
also has what is essentially an A record for the RRAS server. No, I'm
not happy about the LinkSys's DNS offerings, but I know that this
worked at some point in the recent past. I remember because I was
deleriously happy that I could resolve DNS and NetBIOS over the link
and was planning out the next task that I would tackle. Then I noticed
that all was not behaving as I had wished. >_<

Remember, nslookup works fine... most of the time. I say 'most of the
time' because on occasion not even nslookup resolves names across the
VPN. ::bangs head on desk:: I'm not sure why. This whole setup seems
flaky.

Net view depends on the computer browser service, which in turn depends
on LAN broadcasts. You could try enabling LAN broadcasts in RRAS if it is
running on W2k3. I have never used it but it reportedly works. The remote
then looks just like another machine on the LAN and name resolution and net
view should work.

If that doesn't work I would say that you are stuck until you get a
domain set up.

If you are only running a workgroup and no local DNS I doubt that you
will ever get DNS to work properly from the remote. The remote need to have
the IP address of the DNS server and also the correct domain suffix. And the
DNS needs to actually have a record pointing to the client's IP address.

Similarly I doubt that you would ever get browsing to work properly with
only a workgroup, even with WINS. The problem is the way that the client
tries to find a browse list without broadcasts. It sends a message to WINS
looking for the domain master browser. If you don't have a domain, you don't
have one of those!

On May 28, 12:24 am, "Bill Grant" <not.available@online> wrote:
>> Net view depends on the computer browser service, which in turn
depends
on LAN broadcasts. You could try enabling LAN broadcasts in RRAS if it
is
running on W2k3. I have never used it but it reportedly works. The
remote
then looks just like another machine on the LAN and name resolution
and net
view should work. <<

Broadcasting is enabled on the RRAS server. Recall my symptoms: A "net
view" from a VPN'd client only shows the Windows machines on the
client's LAN (that's fine). I can't even do a "net view
[computerName]" across the VPN **except** for the RRAS machine that
I'm VPN'd into. "Net view [IPAddress]" works for all machines on the
remote LAN. I'd like a VPN client to be able to go to the the run
command and use a UNC path with the remote computer's name to get to
that machine's shares.

>> If that doesn't work I would say that you are stuck until you
get a
domain set up. <<

Alot of what I'm doing for this office seems like I'm just hacking it
together until I can get the domain set up. =)

>> If you are only running a workgroup and no local DNS I doubt that you
will ever get DNS to work properly from the remote. The remote need to
have
the IP address of the DNS server and also the correct domain suffix.
And the
DNS needs to actually have a record pointing to the client's IP
address. <<

I think that the RV082 is a DNS server. Client machines on the LAN can
and do register their names in the LinkSys. Remember, nslookup using
the RV082 as it's name server will correctly resolve DNS names. Also
recall that in the past I have had success at this. I just can't seem
to repeat it or figure out what (if anything) was different about the
circumstances surrounding the success.

>> Similarly I doubt that you would ever get browsing to work properly with
only a workgroup, even with WINS. The problem is the way that the
client
tries to find a browse list without broadcasts. It sends a message to
WINS
looking for the domain master browser. If you don't have a domain, you
don't
have one of those! <<

But if I put a WINS server in DHCP optino 44, I would still be able to
reliably UNC to specific machines. In theory anyway. I'd be happy with
that until next year. At least I could use scripts that rely on
NetBIOS names.


More and more I'm beginning to suspect that the LinkSys is flaky. Over
the past months, LinkSys products have lost my favor. Shame on Cisco
for not bringing their subsidiary's quality up.

Unless someone can offer some more insight, I might just install DNS /
WINS. It can't hurt anything... (famous last words).

<[email protected]> wrote in message
news:81e008a3-f81c-4b4c-acf9-ef0c9e9550dc@u12g2000prd.googlegroups.com...
On May 27, 4:45 pm, "Phillip Windell" <[email protected]> wrote:

>> [Phil] It is not "inherited". The client get its config from DHCP
>> combined
with the DHCP Relay Agent. <<

>That would make sense. I was a bit confused by the following
>however...
>Quoth ChicagoTech.net:

I don't know. I never use RRAS that way. I use it with DHCP (the real DHCP)
and the Relay Agent.

>> [Phil] Never used CMAK, was never interested in it,..so I can't help you
with that. <<
>How do you deploy VPN connectoids to clients?

I don't "deploy" connectiods. They are too simple and too few of them to
bother.

>> the DHCP relay agent. I checked and noticed two interfaces in the
relay agent console; "Local Area Connection" and "Internal".

[Phil] Supposed to be that way. This is probably the Root of all
your
trouble. I think for the DHCP Relay Agent to work correctly it needs
to be
set to Local Area Connection because that is the interface that
"faces" the
DHCP Server that the agent needs to do all of its "agent-ing" with.
But I
could be wrong,...try that first, if it doesn't work set it to
"internal". <<

Just to make sure that we're on the same page; I see "Local Area
Connection" and "Internal" when I select the "DHCP Relay Agent"
heading under "IP Routing" in the RRAS console. Both were set to
"Relay mode: Enabled". For giggles, I disabled "Internal" but that
didn't change anything.

There's a second setting that affects DHCP. If you right-click >>
properties the RRAS server in the RRAS console and then select the
"IP" tab you'll see at the bottom a place where you can select the
interface that is used for getting DHCP for clients. The local area
connection on the LAN is the selected interface. "Internal" is not a
choice here; Only the local area connection and then a 1394 adapter
(Firewire card).

>> Flustered, I turned off the DHCP relay agent,

[Phil] Turn it back on <<

I turned it back on and am successfully getting DHCP to VPN clients.

>> [Phil] Get rid of the Pool <<

Done.

> Could this be a problem with my DHCP server? It's just a LinkSys RV082
> that acts as the Gateway, DNS, DHCP, and space heater. That would be
> curious since all clients on the LAN get DHCP with options just fine.

You should:
1. Throw out the Linksys box. (optional)
2. Let the RRAS box *be* the Router (optional)
3. Run DHCP, DNS, WINS on the Domain Controller
4. Do not make the RRAS box the Domain Controller.
5. All hosts on the LAN use the DC for the DNS
6. The DC/DNS then uses the ISP's DNS in the Forwarders List within the DNS
Service Config


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

>> You should:
1. Throw out the Linksys box. (optional) <<

Or at least remove all vital systems from it and keep it as the
router, an extra switch (it has VLANs, which I use), emergency VPN
entrypoint, and of course a space heater.


>> 2. Let the RRAS box *be* the Router (optional) <<

I can't do that in this scenario. At least not yet. Maybe next year.


>> 3. Run DHCP, DNS, WINS on the Domain Controller <<

Remember that this is a workgroup, not a domain. But I can put DHCP,
DNS, and WINS on the RRAS server.


>> 4. Do not make the RRAS box the Domain Controller. <<

Not applicable, but I'm curious to know why RRAS and DCs don't mix
well.


>> 5. All hosts on the LAN use the DC for the DNS <<

Or, in my scenario, I could translate that to "All hosts on the LAN
use the workgroup server for DNS"



>> 6. The DC/DNS then uses the ISP's DNS in the Forwarders List within the DNS
Service Config <<

Sounds relatively simple. As long as no-one objects to piling DHCP,
DNS, WINS, and RRAS on the same box I say it's a go.

Does everyone seem to agree that the LinkSys is a strong suspect in
this debacle or does something else smell fishy?

I still can't figure out why at some times in the past this worked.
>_<

<[email protected]> wrote in message
news:719ac353-80cd-4778-878f-0a1b33178a77@p39g2000prm.googlegroups.com...
>>> 3. Run DHCP, DNS, WINS on the Domain Controller <<
>
> Remember that this is a workgroup, not a domain. But I can put DHCP,
> DNS, and WINS on the RRAS server.

That is going to be your biggest hinderance to anything you want to do.
Domain Controllers are "free" as long as you have the machine and OS to do
it.

>>> 4. Do not make the RRAS box the Domain Controller. <<
>
> Not applicable, but I'm curious to know why RRAS and DCs don't mix
> well.

RRAS boxes, almost by definition, are multi-homed. DCs should never be
multhomed (except SBS scenarios).

272294 - Active Directory Communication Fails on Multihomed Domain
Controllers
http://support.microsoft.com/default...b;en-us;272294

191611 - Symptoms of Multihomed Browsers
http://support.microsoft.com/default...b;EN-US;191611

> Does everyone seem to agree that the LinkSys is a strong suspect in
> this debacle or does something else smell fishy?

If you have a less-than optimal infrastructure and have "issues",...then the
issues may not be worth fighting with until you correct to a better
infrastructure (like getting rid of a workgroup in favor of a AD Domain).
Often when the infrastructure is improved the "issues" just simply "go
away". That is why many of my posts almost seem to ignore the original
question and go straight for what I consider to be the more important
"flaw",...and if the flaw is corrected, sometimes the orginal question
become irrelevant.

> Sounds relatively simple. As long as no-one objects to piling DHCP,
> DNS, WINS, and RRAS on the same box I say it's a go.

They all have a low foot print. Running DHCP, DNS, and WINS on the DC is a
very common practice. Do not use RRAS on the DC box. It does hurt if RRAS
is installed,..just don't use it for anything,...that is back to the
multihoming issue again.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------