[pptp-server] problems with win2k client

Cowles, Steve Steve at SteveCowles.com
Wed Dec 12 00:28:44 CST 2001


> -----Original Message-----
> From: alan premselaar [mailto:alien at 12inch.com]
> Sent: Tuesday, December 11, 2001 8:16 PM
> To: pptp-server at lists.schulte.org
> Subject: [pptp-server] problems with win2k client
> 
> 
> I'm running a redhat linux 6.2 installation with the 2.2.19 kernel 
> (downloaded and compiled from source) i've installed pptpd-1.1.2
> and pppd 2.3.11 (with the mppe and ms-chapv2 patches)
> 
> i've got 3 ethernet cards installed in the machine, 1 setup on the
> DMZ, 1 on the local internal network (192.168.0.x), and 1 configured
> as a completely different (192.168.254.x) network for testing purposes.
> 
> I've setup a PC running win2k pro on the 192.168.254.x network as a
> test connection machine.

For purposes of testing in your lab environment, I would make sure your W2K
client on the .254 network does NOT have a default route set. This is just
to ensure that your TCP/IP stack does not route packets to your .0 network
through the default gateway. 

This very problem bit me when I setup a test lab environment similar to
yours. I was misled into thinking that netbios resolution was going across
the tunnel, when in fact it was using the ethernet interface prior to me
establishing the tunnel.

> 
> i have a couple of seperate problems, i think.
> 
> Firstly, In all the documentation i've read, and the mail on 
> this list, people keep making reference to setting "localip <ip>"
> and "remoteip <ip>" in the options.pptp file (or /etc/ppp/options
> file) ...  whenever I do that, PPP barfs saying that it's an invalid
> option.  i'm a little confused by that, but it's not my main problem.

localip and remoteip are set in your pptp.conf file. 

I usually set the localip to the same ip address as the ethernet interface
of the PPTP server on the local network. The remoteip needs to be set to an
unused ip range within that local LAN. i.e. In your case -- your .0 network.
The key here is to ensure that the ethernet interface of your PPTP server
can act as a proxyarp for all PPTP clients.

> 
> 
> the main problem i'm having is this:
> 
> I can connect via the test vpn from my win2k client.  I can 
> connect to my exchange server no problem.  when I open the
> network neighborhood (or whatever it's called in w2k) i can
> see my domain(s) and all the computers in the domain show up
> when i double-click the domain name... (so far so good) ...
> however, when i double-click any of the computers I can't connect.

Based on the above, your LAN must have a WINS server installed because you
seem to be getting netbios name resolution across your VPN tunnel (which is
good!), but based on your other post to george where you listed the error
message in japanese when trying to access a host within the MS domain, the
error message number translates to...

C:\>net helpmsg 1311

There are currently no logon servers available to service the logon request.

The above message can almost always be resolved by creating a workstation
account for your W2K box on your domain controller. i.e. Using Server
Manager -or- if you have admin privileges, you can join the domain from your
W2K system.

> 
> for the purpose of the testing, i have my password in the 
> chap-secrets file set identically to my domain-login password,
> and my username set identically to my domain-username.

Maybe your already aware of this, but don't confuse the username/password in
chap-secrets as what is used for authenticating against an MS domain
controller. The two have nothing to do with each other. The entries in
chap-secrets are only used to authenticate the VPN tunnel. That's it!!! The
username/password you entered when you turned on your PC is what is used by
Microsoft Networking to authenticate with the PDC. Furthermore, if your W2K
system has properly joined (has a workstation account) with your Domain
Controller prior to establishing your PPTP tunnel, it is already trying to
authenticate to your Domain Controller in the background. 

<Pet Peeve Mode ON>!!!

Here in lies the typical problem with MS Networking and PPTP/PPP vs. IPSEC.
Especially with laptops using dialup accounts and W9x. Example:

1) You turn on your Laptop
2) You log in with your username/password and domain
3) Because your laptop does not yet have a functional TCP/IP stack (just
localhost) -and- you have not yet established your PPTP tunnel into your LAN
where the domain controller exists, your laptop (really MS Networking)
cannot authenticate with your domain controller and register with the WINS
server. So it keeps trying in the background.
4) Now you dialup into your ISP account.
5) Now that you have a functional TCP/IP stack, you can finally establish
your PPTP tunnel into your LAN.
6) Finally (after a few minutes) MS Networking can authenticate with the
Domain Controller and register with the WINS server for Netbios Name
Resolution.

In your test lab environment where you already have a LAN and a functional
TCP/IP stack (and when using DSL/Cable) the above process can be somewhat
simplified. Especially if your using W2k or NT.

1) You turn on your PC
2) You enter your username/password and domain at the login prompt, but with
W2K and NT, you can check the "use dialup networking" and select the PPTP
tunnel profile before selecting the login screens "OK' button.
3) Now (if prompted) enter your username/password for authenticating the
tunnel.
4) Now before your W2K/NT system tries to authenticate to your PDC, it will
*first* establish the tunnel, then authenticate to your PDC using the
credentials specified at the login prompt and eventually register with the
WINS server.

Much smoother process all together.

</Pet Peeve Mode OFF>

FWIW: With Microsoft's implementation of IPSEC... the ipsec tunnel is
brought up after the tcp/ip stack is initialized at bootup. i.e. Before you
receive the login prompt. This is really nice if your on a LAN or using
DSL/Cable from a remote location. 

> also, for the time being, I have my firewall disabled on this
> machine (i can worry about firewalling once I've gotten the
> configuration working)

That's what I do. Eliminate the bottlenecks until you get the underlying
network layers working first.

> 
> this seems to be the case regardless of whether or not I've got samba 
> running on the linux machine.  (I've tried both ways)

Running Samba shouldn't matter unless your using it as

1) A domain controller
2) A WINS server
3) You are needing to access this server using netbios.

> 
> also note that I have added the following rules in my ipchains:
> 
> ipchains -I forward 1 -s 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT
> ipchains -I forward 2 -s 192.168.0.0/24 -j MASQ

The above rule is fine for LAN-to-LAN tunnels such as your test environment,
but not for your road warriors. That's a separate issue.

> 
> 
> *EVERYTHING* (as far as i can tell) aside from the network 
> browsing is working properly thru the vpn.
> 
> any advice, assistance, ritual dance recommendation, etc. are greatly 
> appreciated.

Hopefully my ritual dance/pet peeve :-) stuff about Microsoft Networking
with regards to VPN's was not an overkill and will help you achieve your
goal. Based on your post, seems like your real close.

Good Luck
Steve Cowles



More information about the pptp-server mailing list