RRAS and FQDN ('connection-specific dns suffix' is blank)

I setup a RRAS server yesterday and tested it at home last night. It worked
great except that in order to ping a host on the corporate network, I had to
use the fully qualified domain name instead of just the name. When doing an
ipconfig /all, I noticed that the 'connection-specific dns suffix' is blank.

How do I get the RRAS server to supply the dns suffix so I don't have to use
a very long FQDN when connecting to machines on the network after I vpn into
the network? I've looked all over the RRAS settings and can't seem to find a
place.

I'm using Server 2008 Standard.

TIA,

Jim
--

 

Well, if I change some settings with the connection itself, I can add the
domain within the DNS tab of TCP/IP properties so that names are resolved
properly but this doesn't solve the issue with the server not being able to
hand out the domain suffix to the vpn client when the clien logs in.
Normally, this would be done via DHCP but I'm using a static set of IP
addresses for vpn clients. I can't seem to find a location in RRAS to add a
specific suffix that can be handed out to clients so that clients don't have
to go deep into their connections settings and add it themselves. What a
pain!

 

As you said, normally with DHCP Option 015, you can specify the suffix.
Otherwise, if using static entries, the other config options should be
mirrored from what server's own config, such as if the server has a Primary
DNS Suffix, DNS addresses, etc, they should be provided automatically to the
static RRAS clients.

So how is the server setup?

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer


For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right
things." - Peter F. Drucker
http://twitter.com/acefekay

 

Jim,

I would have thought that what you see is the expected behavior. The
client does not get its network config directly from DHCP even if you use
the DHCP option. I would expect to set the DNS suffix manually in the
client. If you have a lot of them you can use CMAK.

A remote client gets its network config from the RRAS server (it is part
of the PPP negotiation to set up the connection). It has to, because the
network config is only valid for the duration of the connection, not for the
DHCP lease period. The only difference between a static pool and DHCP is
that the server leases a batch of IPs from DHCP to use as its address pool.

Having said that, the client can send a DHCP discover after it has
connected to get extra info from the DHCP server. I'm not sure exactly what
parameters it can pick up that way.

 

Jim,

Bill,

When I've set up RRAS in the past I've always used a DHCP server for the
configuration (usually a seperate server on the LAN and used DHCP relay on
the RRAS server). The client would always (if I remember correctly anyway)
get the appropritea DNS suffix for use on the network they connected to.

This is the first time I've set up a RRAS server with a static pool of
addresses. There was no place in RRAS to specify a DNS suffix to hand out to
the clients.

As Ace Fekay noted above your post, "config options should be
mirrored from what server's own config", I've taken a closer look at the
server's info by doing ipconfig /all and the first bit of info to show is
the "Windows IP Configuration" which shows general, none connection specific
information. In that, it does show it has a dns suffix for the domain it's a
part of (its a member server of the windows domain). However, the connection
specific (two NICs, one called LAN, one called WAN) information does not
show a DNS suffix. I just now appended the suffix (ie: corp.mydomain.com) to
both adapters directly by going into the tcp/ip properties/advanced/dns tab
and adding it there. I then created a new vpn connection on a client and
dialed in and still no dns suffix was added to the client. Of course, i'm
testing from within the domain network itself routing out a seperate public
IP from that that's used on the RRAS server's WAN interface. I'll test from
home again tonight but I think the result will be the same.

It would appear that as long as I'm not using a DHCP server, I'm going to
have to tell the employees to add the dns suffix directly into the
properties of their VPN connection settings on their computers at home,
which I've already made and distrubuted a quite detailed set of instructions
to do so.

I am intersted in what you said about the client still querying the DHCP
server on the LAN to get additional info, even though it's given a static IP
from the RRAS. I've never heard of that before and wouldn't know how to make
it happen. Do you know how this takes place or know of an article that
explains it?

 

Ace,

The server has two NICs, one labeled LAN the other WAN. The WAN has a public
IP, gateway, and its two DNS fields are filled out, the first being the IP
of the domain controller (and dns server) on the internal LAN, the second
being the IP of a public DNS server.

The LAN nic has an internal IP/mask, has its DNS fields set the same as the
WANS, but no default gateway. We are running a VPNed WAN connection between
two other locations with IPs of 192.168.3.0 and 2.0. I've added static,
persistant routes via the command line to properly route to those other
locations out through a different router on the LAN.

RRAS is set up with NAT, so that clients who VPN into the server can route
back out for internet access so they don't have to uncheck that box that
says "use default gateway on remote network", which is checked by default

The RRAS server is set to hand out static IPs to clients who connection; 10
IPs are reserved in the range that the DHCP server on the network, which IS
NOT a windows machines (its a linksys router, of all things; not my design)
is not set to hand out so there's no conflicts.

As I said, the RRAS server has no options to give out a DNS specific suffix
to clients connecting to the service so I've had to instruct the employees
to add this suffix directly into the VPN connection settings on their
computers at home. This actually works just fine but is a somewhat complex
(for them) process to setup initially, even though I've made detailed, easy
to follow instructions, with a few dozen screen shots showing every step of
the way.

I was hoping to find another way so that the employees would not have to
take all the extra steps to add the DNS suffix but I don't believe there is
another way. I do not know if the DHCP service on the linksys router would
work properly with RRAS service. It would be an interesting test, I suppose.

I added more info on this subject under Bill Grant's message below yours.

Thanks for your help.

 

Both interfaces must use the internal DNS ONLY, never any public, ISP, etc,
DNS addresses. In DNS console, properties of the DNS servername, Forwarder
tab, configure a forwarder to your ISP's DNS. This is a defacto rule that
should be followed.

I wouldn't advise using a Linksys router as part of a corporate
infrastructure design (no matter how small). Use a Windows machine for DHCP.
Then set Option 015 as the suffix you want all DHCP clients to get.

The RRAS server should be giving out it's Primary DNS suffix to the clients,
not the connection specific (used for DNS registration) or search suffix
(used for resolution), for the clients. To give the macihne a Primary DNS
Suffix, right click My Computer, properties, go into its name properties and
set it in there.

Ace

 

Ace,

Can you give me some specific reasons as to why you'd want to use a windows
DHCP instead of, say, a linksys machine handing them out?

I agree with you whole heartedly but someone else asked me that question
after I read them your note and they noted "but he didn't say why" and
started to bash 'windows people'.

Can you help me out?

Thanks.

 

Hi Jim,

Sure...

This subject has been brought up a few times in the past. Simply put, a
router's DHCP service is provided as a convenience for home and small,
non-corporate networks. If you are running Active Directory, a router (no
matter what brand) does not support the numerous DHCP options and DNS Secure
(Kerberos based) Dynamic updates interoperability.

Linksys, and many other non-Windows DHCP services do not support Dynamic
DNS, which is Option 081. And if they do, they do not support secure
updates, nor are confgurable on how to handle whether to support the forward
updates by a client, reverse update of a machine, or both. Some routers also
support WINS options, however there are no provisions to set Node Type
(which is important in some cases to set the NetBIOS resolution method).
Microsoft DHCP supports all of this especially because the DHCP APIs work
hand in hand with Windows DNS' security APIs to use Kerberos for secure
updates. This is extremely important if you are using Active Directory. Take
a look at the options in DHCP. Also look at DHCP properties, DNS tab. This
tab controls Option 081.

Windows DHCP is an enterprise class DHCP service, Linksys, Netgears, etc,
are for simple home networks.

I hope that helps.

Ace