[pptp-server] Name resolution and Optimization

[Cowles, Steve]

> -----Original Message-----
> From: Sean McCulloch [mailto:seanm at jflinc.com]
> Sent: Thursday, July 20, 2000 8:35 AM
> To: pptp-server at lists.schulte.org
> Subject: [pptp-server] Name resolution and Optimization
> 
> 
> Hi.  I have poptop 1.0.0 installed on a RedHat firewalling / 
> masquerading
> system.  Everything seems to be working fine except a few things.  Our
> network includes Windows NT/98/95/2000 clients on a class C 
> network which
> get logged onto the domain via an NT4.0 PDC.  Right now from 
> one of my 98
> boxes I can login to the vpn, use Find-->Computers-->(Specify the ip
> address) and the machine will be found.  As long as the 
> access control is
> set to share-level, then I can browse the shares on the 
> system, download
> files etc...  However, if user-level access control is 
> enabled, it asks me
> for a password, but because I'm not logged onto the domain it 
> doesn't accept
> the domain password I type in.  Right now my chap-secrets 
> file is NOT setup
> with the domainname\\validname notation....  If this notation 
> is used, must
> the username / password exist on my PDC?  Next problem, when 
> I'm logged into
> the vpn, I would like all the machines to show up in Network 
> Neighborhood,
> or at least be able to use find->computers..... using the 
> NetBios machine
> names and not the ip addresses.  What would be the easiest 
> way to implement
> something either on the Linux box or PDC which would 
> accomplish this task.
> Would setting up some sort of local WINS service on the PDC 
> and then include
> the ms-wins <ip address> option in my /etc/ppp/options work?  
> Not too sure
> Finally, I was testing the setup from a remote site last 
> night using a 28.8
> dial up connection and it was very very slow.  What mru 
> etc... settings
> should I have to optimize access from a dial-up connection?  
> I read in the
> ppp docs that an mru of 296 is good for a slow link.  Well, 
> that' s about it
> for now.  Any help would be appreciated.
> 
> Thanks,
> Sean

First, when you log into the PPTP server using either username or
domain/username... you have NOT logged into your PDC. All you have done is
authentaicate the VPN tunnel using the supplied username/password. If the
client workstation that created the tunnel was configured to log into an MS
domain (PDC), that will occur after the VPN tunnel is brought up. Remember,
your remote desktop does not know how to contact the PDC until the tunnel is
brought up. In short, when you first power on your remote desktop, you will
get the "No Domain Controller Found" message. This is to be expected
considering the order the TCP/IP stack is initialized vs. when the tunnel is
brought up. MS Networking will continue to try and authenticate with the PDC
in a background process. Once the PPTP tunnel is brought up, you will be
authenticated within a few minutes.

FWIW: MS Networking (by default) uses broadcasts packets to build the
browser list for network neighborhood. Since routers typically do not
"route" broadcasts packets, your remote workstation that has created the VPN
tunnel cannot generate a browse list because the broadcast packets never
make it to your local LAN. In short, your PPTP server becomes a router. It
simply routes packets from device ppp0 to eth0 for example. 

With the above in mind, you will need to run a WINS server on your local
network. This will allow all of your desktops (both local and remote) the
ability to "browse" using WINs instead of issuing a broadcast for network
neighborhood. In fact, this is exactly why MS developed a WINS server. It
solves the problems of broadcast packets not making it across a router.

In order to properly enable a WINS server, you will need to perform the
following steps:

  * Install a WINS server on one of your NT servers. BTW: The WINS server
does NOT 
    have to be installed on the PDC, but it can be. It's up to you.

  * Each desktop (W9x, NT Workstation, W2K Professional, etc.) on your local
LAN
    must be configured to use a WINS server in its TCP/IP proporties.
Also...
    all NT servers (including your PDC/BDC's) must be configured to register
    with the WINS server. This is a critical step. When the MS TCP/IP stack
    initializes, it will register the desktops NETBIOS name (and type) with
    the WINS server. PDC/BDC's will register as "type" 1bh/1ch
    record types. Once the PDC/BDc has registered with the WINs server, your

    desktops will then know what IP address to query for MS Domain 
    authentication.

  * Although not required, another important step in implemeting a WINs
server
    is to make all desktops "NBT Nodetype" of type 'hybrid', not a
'broadcast' node.
    This is easily accomplished by setting (adding) a DHCP scope
parameter...
    WINS/NBT Node Type - to 0x8 (Hybrid). This has the effect of disableing
the
    desktop (TCP/IP stack) from issuing a broadcast and querying the WINS
server
    "first" for browser requests. In fact, I have seen this one setting
eliminate
    tons of network traffic on a busy LAN thus freeing up much needed
bandwidth.
    To determine a desktops node type, use either 'winipcfg' or 'ipconfig'.
Notice
    the output from my W2K system...

    c:\> ipconfig /all | more
    Windows 2000 IP Configuration

        Host Name . . . . . . . . . . . . : enterprise
        Primary DNS Suffix  . . . . . . . :
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : mydomain.com

3) Once you have implemented a WINS server and all of your servers and
desktops have properly registered with that WINS server, add the 'ms-wins'
parameter to your /etc/ppp/options file on your PPTP server. You will set
this parameter to point to the WINS servers IP address(s). Then when you
connect remotely using PPTP, your remote desktop will eventually
authenticate with the PDC and Network Neighborhood will work as if your
desktop was on the local LAN. Only with a little slower response time.

Good luck
Steve Cowles