[pptp-server] problems with win2k client

Wed Dec 12 01:15:28 CST 2001

Steve,

  Thanks for the reply.  I guess my dis-advantage (hasn't been a problem 
until now) is that I'm not all that familiar with windows as i've been 
fairly successful in sheltering myself from it for all these years.. (heh)

so, i'll intersperse my responses within your reply:

At 12:28午前 -0600 12.12.01, Cowles, Steve wrote:
> > -----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've tried this and get the same results as before.  Also, I was attatching 
from my 192.168.254.x network to my DMZ interface to try to simulate a 
remote ISP IP address connecting to the outside IP of the machine.  Since 
your response, i've also changed it to connect to the 192.168.254.x 
interface in the linux machine. made sure i had no default route before 
bringing up the vpn and get the same results.

> >
> > 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.

apparently I was smoking something bad for breakfast... after getting the 
first response to this, i checked my files and realized that I had already 
resolved this problem. (heh)

I don't seem to haven any problems with the connection/authentication 
between the client and the pptp server.

> >
> >
> > 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...

true, there is a WINS server (as far as i'm told) ...

>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.

<insert a fair amount of windows naivety here>  we're running a w2k active 
directory setup here... i don't exactly know how that differs from having a 
PDC/BDC/WINS server setup from the NT4 era...

so, honestly, i'm not entirely sure what it means to "create a workstation 
account on the domain controller"
is that as opposed to a "domain account" or something?

> >
> > 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.

yeah, i'm already aware of the differences, I just made them the same in an 
attempt to keep things simple (to start with)
having read a number of documents and howto's and what-not... I've found 
the information to be more confusing and contradicting than actually 
helpful, so i decided keeping things simple to start would keep me from 
losing any more hair (unintentionally)

><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.

yeah, i noticed this option and played with it a few times... what happens 
is, it establishes the vpn link, and then it says "loading user settings" 
(or whatever the appropriate english translation is) and just kinda 
chatters on the network for a *REALLY REALLY LONG TIME*   (this current 
pass has been over 3 minutes already)

></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.

again, i had gotten conflicting information with regards to this... i'd 
ultimately prefer NOT to have to run samba on the VPN gateway.

> >
> > 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.

hmm, any of our "road warriors" are going to have access thru an ISP, not 
direct dialup, so assuming that once this thing is working, it'll have 2 
ethernet adapters in it. 1 on the local net and 1 in the DMZ, i would think 
this would still be applicable.

> >
> >
> > *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.

it was definitely informative (which can only help at this point) ... but 
unfortunately hasn't gotten me any closer to solving my problem =(

i do appreciate the effort however

>Good Luck
>Steve Cowles
>_______________________________________________
>pptp-server maillist  -  pptp-server at lists.schulte.org
>http://lists.schulte.org/mailman/listinfo/pptp-server
>--- To unsubscribe, go to the url just above this line. --

alan

----
  there's nothing like the undying sense of reliability provided by modern 
technology.
----
alan premselaar
alien at 12inch.com
www.12inch.com