Today I set a VPNSERVER running Windows 2003 SP2.
Here's how it's planned:
VPNSERVER and CLIENTPC (windows XP SP2) are on the same LAN segment,
CLIENTPC connects to VPNSERVER, user "vpnuser" with password "1" is Allowed
to connect.
In reality however I can only connect using Optional encription and PAP or
SPAP, despite that the server is configured to also accept CHAP, MS-CHAP and
MS-CHAP v2.

If I try to use any of the CHAP protocols I get unknown user name or
password error. I set the user password to "1" so that cannot possibly
mistype it, but still I get this error, and after a few logon attempts the
user account gets locked out.

1. Any ideas what is going on here?
2. Is there a password length limit for SPAP? I was able to logon with a 10
char pass, but when I tried the other account that has a 50 chars pass, it
failed. I didn't get unknow user name and password thought, it showed some
other error.


PS: Since I failed to use CHAP, I enabled IPSec, just to make the SPAP
session a bit more secure ;-) SPAP+IPSec with a shared secret works
properly.


Here are a few screenshots of server's the configuration:
http://i43.tinypic.com/rvd2l1.png
http://i41.tinypic.com/2ez0n7k.png
http://i44.tinypic.com/s49rsy.png
http://i39.tinypic.com/2wew9yf.png
http://i42.tinypic.com/2h32cqx.png
http://i43.tinypic.com/5b8arm.png
http://i39.tinypic.com/2ljt7js.png
http://i40.tinypic.com/a32mbc.png


Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: vpnuser
Source Workstation:
Error Code: 0xC000006A

Logon Failure:
  Reason:  Unknown user name or bad password
  User Name: vpnuser
  Domain:  VPNSERVER
  Logon Type: 3
  Logon Process: IAS
  Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
  Workstation Name:
  Caller User Name: VPNSERVER$
  Caller Domain: WORKGROUP
  Caller Logon ID: (0x0,0x3E7)
  Caller Process ID: 832
  Transited Services: -
  Source Network Address: -
  Source Port: -


Thank You for any help!

Show quote Hide quote SPAP is Shiva's protocol. I don't think you are using a Shiva device, so I
wouldn't even imagine why you would have that set. I haven't seen one in
over 12 years.

When I setup a VPN server, I try to use the KISS method (keep it short and
simple), and only set it to just MSCHAP and MSCHAP2. If you do that, does it
work? CHAP is used by *nix devices or other non-Windows connections.

Also, another big question, does it work without IAS? Try to eliminate the
complexity to find out where it is going wrong. If it works with using RRAS
directly, then I would go to the next step and setup IAS.

Any reason why not just use DHCP? This way you get all the DHCP options
across, such as WINS, etc.

I don't remember the password length, but if your domain requirements are
set to default, meaning it must be a complex password, it should be
followed, unless you disabled that setting in the Def Domain GPO?

Show quote Hide quote Hello Ace!
I'd be happy to use MSCHAP or MSCHAP2, unfortunately they didn't work so I
tried PAP and SPAP as a fallback.


There is no IAS. That's not a corporate network, so I guess I wouldn't spend
money on IAS. I have a license for Win2003 on my home PC and I decided to
bring the PC from my other home in the same network with it. And so made use
of the VPN functionality and enabled RRAS. But I guess it didn't work with
the default confing on the server and on the XP client :-(
Any better ideas how to bring the two computers to the same LAN and share
files as a network drive?

I don't need DNS WINS or any advanced functionality. RDP and HTTPS are
already over SSL, so just needed to establish File and Printer sharing.
The server has static internet accessible IP. The ISP won't let me have
another IP, so I decided to set a VPN. I am currently on the client PC, I
established a successfull connection through a NAT router to the VPN server
using SPAP. I'll also tried MSCHAP2, but I got unknown username or bad
password again.


There is no domain, this is a stand alone home server running Windows 2003
SP2 Ent.


Thank You for the replay, Ace! George Valkov

BWT the screen-shots only work when copy-pasted in the browser.

Show quoteHide quote

I'm somewhat surprised it is not working, because XP will use MSCHAP2.
MSCHAP was designed back in the NT4 days, but graduated to MSCHAP2 with
Windows 2000 and newer.

IAS is FREE. It is part of the operating system. The error you provided was
an IAS error.


Show quoteHide quoteIf you are not using DNS, then it needs some other form of name resolution
to "find" your internal resources and because you are not using AD, then DNS
is not necessarily required internally, but in your case WINS will be needed
otherwise how will it find the internal resources by name? If you have a
mapped drive by name, such as \\servername\sharename, how is the client side
resolver to resolve the internal servername?

As far as why MSCHAP2 is not working, seems to point to a simple RRAS
misconfiguration. Believe me, I've set this up in my sleep without problems
numerous times, as an interim solution for companies until I got their Cisco
ASA in place for hardware based VPN with the Cisco client.


You are welcome.

They were somewhat difficult to open individually. Would have been nicer if
they were jpgs and all in one page so I can compare the pics side by side.


See if these articles work to help set it up.

======================================================================================================
======================================================================================================

How to setup RRAS as a VPN server

Routing and Remote Access Blog : VPN server deployment: IP
http://blogs.technet.com/rrasblog/archive/2006/09/20/457653.aspx

Microsoft Windows Server 2008: A Beginner's Guide - Google Books Resultby
Marty Matthews - 2008 - Computers - 592 pages
SET UP A VPN SERVER VPN, like RAS, has both client and server components.
http://books.google.com/books?id=Rm03A0LOOPgC&pg=PA306&lpg=PA306&dq=setup+RRAS+as+VPN+server&source=bl&ots=vlR40IdKFp&sig=R7lOKtzihKIp39paa5kW1u9KCrc&hl=en&ei=HJHySc65KcmMtgfj6fW9Dw&sa=X&oi=book_result&ct=result&resnum=8

VPN Setup - multiple links on how to setup RRAS, VPN and a client
www.chicagotech.net/vpnsetup.htm

======================================================================================================
======================================================================================================


Ace

Me too. The default configuration not working didn't match my expectation
for "logical". (when I started working on this, there was some default
configuration that didn't work). So I looked in every setting that I could
find on the server and played with it. Unless if something else is broken on
the server - It's been 3 years since I installed it, and I also use it as a
workstation (it's my only PC).

My bad, I'll try to learn about Internet Authentication Service.


Show quoteHide quoteI am using the IP address of the server. At least for now:
\\192.168.1.1\share
DNS and WINS are to make life easier, when there are many computers. For a
single computer there's the HOSTS file ;-)


It's possible that I've messes something up with the configuration, I was
very overloaded with tasks this Tuesday. I have a trial version of Windows
2008. I will try to set the VPN server there just for a test and post back
when I have results from it.

PNG format it better for screenshots and graphics. JPG files are larger and
usualy doesn't look good. But You did actually mean archived together like
this:
http://www.mediafire.com/file/manyy3dnayr/2009-05-04_VPN.7z



http://books.google.com/books?id=Rm03A0LOOPgC&pg=PA306&lpg=PA306&dq=setup+RRAS+as+VPN+server&source=bl&ots=vlR40IdKFp&sig=R7lOKtzihKIp39paa5kW1u9KCrc&hl=en&ei=HJHySc65KcmMtgfj6fW9Dw&sa=X&oi=book_result&ct=result&resnum=8
Thank You, Ace! I added them to my collection of links and I'll try to find
some free time during the weekend for reading!

George Valkov

2003 as a workstation???


It's Microsoft's implementation of RADIUS.


I hate hosts files. Rather use DNS. :-)


I'm begininning to think since it is your workstation, who knows what's
installed on it by this time, especially after 3 years of use. Firewall, ZA
formerly installed on it (known issue), antispyware, security software,
operating systems issues,.............

A little better, but I was thinking more of a bunch of thumbnail pics on the
site where you click on one and the full version opens. This eliminates
downloading them one by one to open, and you can view the thumbnails, as
long as big enough, side by side for comparison.


Cheers!

Ace

Hey guys,

In a continuing effort to try and help I did some more research.

Now that I know you are just trying to get to the VPNSERVER from XP,
you are correct, you don't need "Router" checked

Did some more reading and found this:

Preshared Keys and L2TP/IPSec - The only case in which certificates
are not required
for L2TP-based VPN connections is when BOTH the VPN client and the VPN
server are
running Windows Server 2003. In this case, you have the option to
configure computer
authentication through the use of a preshared key: .......

So to simplify the situation, I'd recommend disabling that since your
other machine is Win XP  SP2. I also found a VPN Troubleshooting
checklist that might help

Troubleshooting Remote Access VPNs

Use the following checklist to troubleshoot remote access VPN
connections:

” Verify that on the VPN server, enough ports have been configured in
the Ports
node for the relevant VPN type needed (PPTP or L2TP) and that not all
available
ports are currently being used. (You should only need one port, since
its XP to 2003)

” Verify that the Remote Access Server option is enabled on the server
properties
General tab in the Routing And Remote Access console. (We are good
here)

” Verify that the VPN connection has the appropriate permissions
through dial-in
properties of the user account and remote access policies. (This is
key! Make sure the user account you are dialing in with from XP is
configured on 2003)

” Verify that the VPN client, the remote access server, and the remote
access policy
are configured to use at least one common authentication protocol. (I
think we are good here too.)

” Verify that the VPN client, the remote access server, and the remote
access policy
are configured to use at least one common encryption strength. (I
think we are good here also.)

” Verify that the remote access server (or RADIUS server) computer is
a member of
the RAS And IAS Servers security group in the local domain. (is
VPNSERVER a member of this group? Could be a problem.)

” Verify that the settings of the remote access policy profile are not
in conflict with
properties of the remote access server.(under the Dial-In tab for the
user account on the VPNSERVER, which Remote Access Permission is set?
"Allow" or "Control Access through Remote Access Policy"? If "Control
Access through Remote Access Policy" is set, you may have a conflict.
To eliminate this being an issue, I'd recommend setting it to "Allow"
for now.)

” Verify that, if MS-CHAP v1 is being used as the authentication
protocol, the user
password does not exceed 14 characters. (I know, we already discussed
this one...)

Let Ace and I know how your doing :-)

"Matrixx333" wrote in message
In a continuing effort to try and help I did some more research.

Now that I know you are just trying to get to the VPNSERVER from XP,
you are correct, you don't need "Router" checked

Did some more reading and found this:

http://support.microsoft.com/kb/324258#appliesto

Preshared Keys and L2TP/IPSec - The only case in which certificates
are not required
for L2TP-based VPN connections is when BOTH the VPN client and the VPN
server are
running Windows Server 2003. In this case, you have the option to
configure computer
authentication through the use of a preshared key: .......

So to simplify the situation, I'd recommend disabling that since your
other machine is Win XP  SP2. I also found a VPN Troubleshooting
checklist that might help

######
I just read the article, but I'm sure it also works for Windows XP (both x86
SP2 and x64 SP2), because I successfully established a connection from those
maschines.
######


Troubleshooting Remote Access VPNs

Use the following checklist to troubleshoot remote access VPN
connections:

Verify that on the VPN server, enough ports have been configured in
the Ports
node for the relevant VPN type needed (PPTP or L2TP) and that not all
available
ports are currently being used. (You should only need one port, since
its XP to 2003)
###### CHECK: 128 PPTP; 128 L2TP


Verify that the Remote Access Server option is enabled on the server
properties
General tab in the Routing And Remote Access console. (We are good
here)
###### CHECK: enabled

Verify that the VPN connection has the appropriate permissions
through dial-in
properties of the user account and remote access policies. (This is
key! Make sure the user account you are dialing in with from XP is
configured on 2003)
###### CHECK CHECK: Allowed Yes

Verify that the VPN client, the remote access server, and the remote
access policy
are configured to use at least one common authentication protocol. (I
think we are good here too.)
###### CHECK: Yes
BTW If I misconfigure this the client indicates that the server does not
accept the authentication protocol. In my case the protocol is accepted, and
the client indicates unknown username or password.


Verify that the VPN client, the remote access server, and the remote
access policy
are configured to use at least one common encryption strength. (I
think we are good here also.)
###### CHECK: Server is configured to accept all.

Verify that the remote access server (or RADIUS server) computer is
a member of
the RAS And IAS Servers security group in the local domain. (is
VPNSERVER a member of this group? Could be a problem.)
###### NO: Because it is stand alone server in workgroup mode. There is no
domain.

Verify that the settings of the remote access policy profile are not
in conflict with
properties of the remote access server.(under the Dial-In tab for the
user account on the VPNSERVER, which Remote Access Permission is set?
"Allow" or "Control Access through Remote Access Policy"? If "Control
Access through Remote Access Policy" is set, you may have a conflict.
To eliminate this being an issue, I'd recommend setting it to "Allow"
for now.)
###### CHECK: Allow is set on user profile.

Verify that, if MS-CHAP v1 is being used as the authentication
protocol, the user
password does not exceed 14 characters. (I know, we already discussed
this one...)
###### CHECK but:MS-CHAP v1 didn't work, PAP workes properly.

Let Ace and I know how your doing :-)

Hey guys,

In a continuing effort to try and help I did some more research.

Now that I know you are just trying to get to the VPNSERVER from XP,
you are correct, you don't need "Router" checked.

Did some more reading and found this:

http://support.microsoft.com/kb/324258#appliesto

Preshared Keys and L2TP/IPSec - The only case in which certificates
are not required for L2TP-based VPN connections is when BOTH the VPN
client and the VPN server are running Windows Server 2003. In this
case, you have the option to configure computer authentication through
the use of a preshared key: .......

So to simplify the situation, I'd recommend disabling that since your
other machine is Win XP  SP2. I also found a VPN Troubleshooting
checklist that might help

Troubleshooting Remote Access VPNs

Use the following checklist to troubleshoot remote access VPN
connections:

” Verify that on the VPN server, enough ports have been configured in
the Ports node for the relevant VPN type needed (PPTP or L2TP) and
that not all available ports are currently being used. (You should
only need one port, since its XP to 2003)

” Verify that the Remote Access Server option is enabled on the server
properties General tab in the Routing And Remote Access console. (We
are good here)

” Verify that the VPN connection has the appropriate permissions
through dial-in properties of the user account and remote access
policies. (This is key! Make sure the user account you are dialing in
with from XP is configured on 2003)

” Verify that the VPN client, the remote access server, and the remote
access policy are configured to use at least one common authentication
protocol. (I think we are good here too.)

” Verify that the VPN client, the remote access server, and the remote
access policy are configured to use at least one common encryption
strength. (I think we are good here also.)

” Verify that the remote access server (or RADIUS server) computer is
a member of the RAS And IAS Servers security group in the local
domain. (is VPNSERVER a member of this group? Could be a problem.)

” Verify that the settings of the remote access policy profile are not
in conflict with properties of the remote access server.(under the
Dial-In tab for the user account on the VPNSERVER, which Remote Access
Permission is set? "Allow" or "Control Access through Remote Access
Policy"? If "Control Access through Remote Access Policy" is set, you
may have a conflict. To eliminate this being an issue, I'd recommend
setting it to "Allow" for now.)

” Verify that, if MS-CHAP v1 is being used as the authentication
protocol, the user password does not exceed 14 characters. (I know, we
already discussed this one...)

Let Ace and I know how your doing :-)

Hello Ace and Matrixx!
I made some tests on Windows 2008 and I found something interesting.

First I installed the Remote Access Service, then click Configure and Enable
Routing and Remote Access and set a VPN with default parameters and a custom
range of IP addresses to be assigned to clients. Allow Dial on the user
accounts and assign static IP address to the user. After all a default
configuration is always supposed to work ;-)

Then on the client, new VPN connection with default parameters. Well, the
good news is that it didn't work ;-) And I got exactly the same behaviour
that I have on Windows 2003: PAP works, but any flavours of CHAP doesn't.

And the moral of this is that whatever software broken my Win2003
installation has also broken the Win2008 one. To prove this I took my backup
media and found the initial installation of Win2008 - the one without any
drivers or software installed on it. I restored an image file to partition,
started it and reinstalled RRAS exactly the same way. As I already
expected - MS-CHAP v2 worked properly.

So currently I have two backup images: the old one without any software that
works properly and the new one that has a lot of software and is broken. My
next step would be to make a list of the installed software and start
installing, until I break the working installation. :-) Next I'll try to
examine what exactly was installed is causing the problem and see if I can
revert it. A 20 GB partition restore takes about 7 minutes.

Hey although I just made my first step in RRAS, I knew I couldn't be that
stupid to mess it all up. Not after all that long time playing with Win
2003.



Show quoteHide quoteIf you have a single PC, would You install a Workstation OS or a Server? Me,
I've been playing with Windows server ever since the Win 2003 RC1 came to
public. After a Microsoft day, I got lucky to receive a license for it. Win
2003 offers everything that XP does: multimedia, TV, gaming + all of the
enterprise server extras. ;-)



Did You mean to install the DNS server service?


There are no 3rd party firewall nor antivirus, nor anything like that and
there has never been such software. I prefer to relay on the security
configuration to guard the server.

Okay, there's that dynamic index.htm in the main folder, it's a web page
that I designed for viewing pictures, see the Readme.txt
Or If You prefer there're separate static index.htm files in each
sub-folder.
http://www.mediafire.com/file/mannfm2f0if/2009-05-09VPN.7z

Which way would you prefer more?

I tried to make [VPN-Win2008-broken] look the same as
[VPN-Win2008-initial-install], but it still doesn't work. I guess this
proves that some of the programs which I installed see [VPN-Win2008-broken3]
is causing the problem. I guess I'll have to restore the initial backup and
start installing programs, until I break it ;-)

Wish me Luck :-) I'll post back when I'm ready with more news...


George Valkov

Show quote Hide quote Good for you!!!! Glad you are making headway...


True, but it's overhead and some things don't work the same as a workstation
operating system. It just complicates it for the user if not familiar with
Windows Servers operating systems.



No, not necessarily, but it is my preference, however I do not want to
complicate things for you.


This looks fine. The VPN setup looks fine.

As I kind of thought when I asked about what was installed on the machine.
SOmething is conflicting with it. I would be curious to know what it is.

Good luck, and waiting to hear more!

Cheers!

Ace

Great job George!!! I'm just happy to hear that it wasn't the
configuration that was causing the problem.

I just spent all my day reinstalling all of the software and it kept on
working. Because the authentication wasn't caused by any of the installed
software. Al items with X over the icon means installed and rebooted, but
still didn't break the authentication. That's not funny ;-)
http://www.mediafire.com/file/imjiomznmz1/RRAS-resolved.7z

Ace, did you remember that setting under Local Security Policy that I
mentioned in one of my previous posts? Both of us thought it couldn't be
causing the authentication failures. Well, both of use were wrong!

Here is the solution to resolve my problem:
Under [Administrative Tools], open [Local Security Policy], expand [Local
Policies], [Security Options], locate this setting:
[Network security: LAN Manager authentication level]
If it is set to:
[Send NTLMv2 response only\refuse LM & NTLM]
then MS-CHAP v2 and all the other CHAP authentications for RRAS VPN will not
work properly, "unknown user name or password" event is logged, even when
the user name and password are valid.
To resolve the problem, change this setting to:
[Send NTLMv2 response only\refuse LM]
.... And it will work like a charm. Setting take effective immediately.

That's all Folks! :-)


George Valkov

PS: Ace and Matrixx, Thank You very much for Your time and patience!
I'll keep watching this topic, in case You have any suggestions or
questions.
Cheers!



Show quoteHide quote

Show quote Hide quote Well, well, well! See, messing around with this stuff can cause Elmer Fudd
to be hunting you down!

I do remember talking about it and you mentioning you changed something, and
without perusing back in the multitude of posts in this thread, why were
they changed?

Either way, I am very, very happy that you found the issue. Keep in mind, I
normally do not go through those settings unless I have to. Say in a DC, if
I need to allow DOS or OSx clients to communicate and access shares, etc, I
would disable SMB Signing, but honestly I wouldn't normally touch the
Lanmanger authentication level settings unless there was an app that needed
it.

Cheers!

Ace

On May 10, 7:16 pm, "Ace Fekay [Microsoft Certified Trainer]"
<ace***@mvps.RemoveThisPart.org> wrote:
Show quoteHide quotehttp://support.microsoft.com/kb/893318

CAUSE - This problem occurs because MS-CHAP is designed to be
compatible only with NTLM version 1 authentication.

Granted the article is referencing an IAS server, but essentially your
server is providing the same role an IAS server would, your server is
acting as a single point of contact to handle remote authentication
just as an IAS server would.

....and again, great work George and Ace!

On May 10, 7:16 pm, "Ace Fekay [Microsoft Certified Trainer]"
<ace***@mvps.RemoveThisPart.org> wrote:
Show quoteHide quotehttp://support.microsoft.com/kb/893318

CAUSE - This problem occurs because MS-CHAP is designed to be
compatible only with NTLM version 1 authentication.

Granted the article is referencing an IAS server, but essentially your
server is providing the same role an IAS server would, your server is
acting as a single point of contact to handle remote authentication.

....and again, great work George and Ace!

http://support.microsoft.com/kb/893318

CAUSE - This problem occurs because MS-CHAP is designed to be
compatible only with NTLM version 1 authentication.

Granted the article is referencing an IAS server, but essentially your
server is providing the same role an IAS server would, your server is
acting as a single point of contact to handle remote authentication.

....and again, great work George and Ace!

====

Thanks, Matrixx! And you're right, we overlooked that fact about MS-CHAP!!

Ace

"Matrixx333" wrote in message
On May 10, 7:16pm, "Ace Fekay [Microsoft Certified Trainer]"
<ace***@mvps.RemoveThisPart.org> wrote:
Show quoteHide quotehttp://support.microsoft.com/kb/893318

CAUSE - This problem occurs because MS-CHAP is designed to be
compatible only with NTLM version 1 authentication.

Granted the article is referencing an IAS server, but essentially your
server is providing the same role an IAS server would, your server is
acting as a single point of contact to handle remote authentication.

....and again, great work George and Ace!

On the server [Windows 2003 or Windows 2008] running RRAS:
Under Administrative tools, Local Security Policy, Local Policies, Security
Options:
change
[Network security: LAN Manager authentication level]
to
[Send NTLMv2 response only\refuse LM & NTLM]

As a result, the clients will not be able to logon using any versions of
CHAP or MS-CHAP authentication protocols - "unknown user name or password"
event is generated.

Resolution:
Then on the server, add the following information to the registry (the file
is also attached to this thread):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy]
"Enable NTLMv2 Compatibility"=dword:00000001

Restart the [Routing and Remote Access] service. Now the clients will be
able to successfully logon and join the VPN.

Ace, that hot fix is dated 2007, but it was not installed on my server,
because it had never been added to Windows Update. Being an MVP, can You
please ask Microsoft to publish the hot fix on the Windows Update web site,
so that others can benefit from our experience?

Thank You, Matixx and Ace!


ps:// now that it all works properly, I decided to try the Protected EAP
(PEAP) (encryption enabled) with a certificate to authenticate the server...
It looks really good, especially when spiced with L2TP IPSec VPN and a
shared secret.

Cheers!


George Valkov

[attached file: RemoteAccess_Policy_Enable NTLMv2 Compatibility.reg]

Show quote Hide quote Actually, I am no longer an MVP. Usually hotfixes are part of a Service Pack or rollup based on their security or performance importance.

And I am glad you got all this straightened out!!

Ace

Show quote Hide quote Why would he be hunting me down?
Oh!, that's Elmer Fudd? I didn't know the name of this character, so I
just asked Uncle Google and he gave me a picture of him. :-) By the way, I
love
Bugs Bunny! :-)



Because I wanted to prevent the usage of weaker authentication protocols.
Since most computers are running XP and Vista, one doesn't need to enable LM
or NTLM authentication. I also think that when both client and server are
configured to use NTLM v2, the session is established faster (instantly).
Otherwise they need to negotiate and it may take a while.

My ISP is poisoning the ARP cache + filtering File and Printer Sharing (as
they said: to prevent worms from spreading arround and protect customers),
so we are using static ARP, to prevent them from sniffing and blocking some
traffic. And when I have to access my home server from the Internet, I
prefer
to do it over SSL.



I agree that the default security settings mean less trouble and better
compatibility... And when maintaining the computers for some company, one
wouldn't want unnececery problems.

On the other hand I like to keep my home server secure, sometimes this
causes problems, but I usually find workarounds. :-)


Show quoteHide quote

Great cartoon!!

Ace

Thanks for the links, again! I finaly found time to read the entire content
and I learned a few new things.


George Valkov



Show quoteHide quotehttp://books.google.com/books?id=Rm03A0LOOPgC&pg=PA306&lpg=PA306&dq=setup+RRAS+as+VPN+server&source=bl&ots=vlR40IdKFp&sig=R7lOKtzihKIp39paa5kW1u9KCrc&hl=en&ei=HJHySc65KcmMtgfj6fW9Dw&sa=X&oi=book_result&ct=result&resnum=8
Show quoteHide quote

Good to hear, George! A little knowledge can go a long way!

Cheers!
Ace

Looks fine

Looks fine

Looks fine

This might be a problem. I understand you said the VPNSERVER and the
CLIENT were on the same network segment, but if your using your
VPNSERVER as a secure way to access a remote network, then "Routing"
needs to be checked to access any other remote network beyond the
VPNSERVER.

At the bottom you have "Allow custom IPSec Policy for L2TP connection"
and it looks like you have a pre-shared key typed in. If the client
doesn't also have this key configured, the connection will fail.

Looks fine

Generally, if you have a DHCP server on the network, you wouldn't want
to configure a static address pool, as Ace had mentioned. Also, is the
scope of the static address pool in the same subnet as the network you
are trying to access from the VPNSERVER? If not, you wont be able to
access anything beyond the VPNSERVER.

Not really applicable unless you were using ISDN or multiple modems to
establish the vpn connection

I know for MS-CHAP v1 the password cannot exceed 14 characters, but as
Ace had mentioned, any non-windows machine is going to use CHAP
anyways. I would also agree with Ace's advise about using the password
requirements for your domain, if you are on one.

Speaking of Domain or Workgroup, the account you are using to
establish the connection must either be in AD or configured in the
local SAM of the VPNSERVER if it is a workgroup. If you are on a
domain and have an account in AD, I would suggest looking at the
Remote Access Policies in Routing and Remote Access. Is the username a
member of a group that hasn't been configured with a Remote Access
Policy? Does the AD account have dial-in permissions? Also the client,
server, and policy all have to be configured with at least one common
authentication protocol and encryption strength.

Hope this helps.

Show quote Hide quote Good point, Matrixx! I didn't ask where the user account was created.

Ace

"Matrixx333" wrote in message
Show quoteHide quoteI think that the answer to that remark would be: Router is not needed,
because the real client computer can tunel through it's local NAT router,
travel the Intrenet, join the VPN and access the server, when this feature
is disabled.

Initialy the Router feature was enabled and I tried either sub-options...
either way, if I use CHAP I'll get unknown user name or password error. I
disabled the Router, because I didn't want to have features enabled that I
can do without.

When I wrote my first message, I decided to omit a few details - some that I
thought were less important, so that we can focus on: why I get the "unknown
user name or password" error. Here are the details:

My aim is to put the server and the client on the same LAN (VPN) so that
they can use File and Printer Sharing. The client already has internet
connectivity so the VPN server does not need to offer that to the client.
Infact initially the server did offer that functionality, but that caused a
problem with my ISP:
in short, the client decided to access the internet from the VPN interface,
the server rerouted that to the gateway of the ISP, which received a packet
from the MAC of the server, but with IP that my ISP has assigned to the
client PC. Their security system decided that the server was trying to steel
the IP address of the client and they blocked access to server's MAC. After
4 phone calls to unblock the server internet connection we finaly figured
out what exactly happens so I took measures to prevent the VPN side from
accessing anything outside it's scope. - I disabled Router and assigned
proper IP filtering.

I said that the VPNSERVER and client are on the same LAN. Sure they already
have File and Printer sharing, but that's only a laptop I had in hand for
the test. The real client computer is in another town and is behind a NAT
router, so it has to join the VPN.

Or...? Hm, would it be possible to use IPSec and create tunnel for all ports
used by File and Printer Sharing between the server and a client that is
behind a NAT router? If yes than I don't need to set a VPN.




I am aware of that, but notice that it says "Allow" and not "Force".
According to my tests, if the client does not enable ISPec it will still
connect without security. And if the client enables IPSec and enters a
correct preshared key, it will establish a secure tunnel for the VPN
connection, despite it's still using PAP or SPAP and unsecured VPN.


And than the VPN server will relay the DHCP to that DHCP server, instead of
the static pool that I configured. But I don't need additional DHCP server.
There will be only two hosts in the VPN, the VPNSERVER and the client. I was
also planning to assign a static IP on the user account's Dial-in
configuration page.



Thanks for the remark!


I think that this answers one of my questions!
Probably PAP ans SPAP are limited to 14 characters too.
I'm not panning to have non windows clients for now.
The password "1" was temporary set for testing only. By default my server
has the complex password requirements and minimum password length set to 10.

This reminds me that the password policy on the server is even more secure.
I just thought about what setting could be the cause:

Local Security Policy/ Local Policies/ Security Options/
Network security: Do not store LAN Manager hash value on next password
change
=ENABLED

Since the LM hash is not stored, it can't be attacked, and the NTLM hash is
supposed to be much harder to crack (not to mention that ackount lockout is
enabled). If some one tries to logon using a LM has, since there's no LM
hash stored, the logical result would be "unknown user name and password".

And if that is the case, would it be possible to force the use of NTLM hash
for authentication, I don't want to relay on the LM hash?

EDIT:
I created a password that has both NTLM and with LM hashes, but still get
"unknown user name or bad password".


I have also altered a few other settings to make my server even more secure
(but they are probably not related to my problem):
Network security: LAN Manager authentication level
=Send NTLMv2 response only\refuse LM & NTLM

Network security: Minimum session security for NTLM SSP based (including
secure RPC) clients
Network security: Minimum session security for NTLM SSP based (including
secure RPC) servers
=Require message integrity;
Require message confidentiality;
Require NTLMv2 session security;
Require 128-bit encryption.




Yes, it is allowed to dial-in in the SAM on the VPNSERVER.

Thank You, Matrixx333! :-)

George Valkov

Show quote Hide quote Some ISPs block inbound VPN connection capabilities. I know Comcast is one
of them, but they will allow outbound and established to come back in, but
not initial inbound. This prevents users from creating VPN and other type of
servers (mail, web, ftp, etc).


Usually this is not a problem. It is done everyday by remote users
connecting to their company networks.


This also may be affected by the router, if it is allowing or not allowin
VPN pass-through (as what LinkSys calls it). By default, I believe IPSec
tunnels are allowed through, but don't quote me on that. YOu will have to
check the router docs and settings.


VPNs are secured connections. There really is no "unsecured VPN" in the
context of your sentence. The password will dicate how the client
establishes the secured connection. If the password is weak, or using a weak
method, then it is easier for anyone to crack it and create their own
secured connection.


Relay the DHCP Request, not relay "DHCP," but I'm sure that's what you
meant.

The Password Policy on a DC would be at the domain level, wihch will affect
all user accounts. This is in the Default Domain Policy. Under
Computer-Windows Settings-Security Settings-Password Settings.

If on a local machine, it would be in the Local Security Policy
(administrative tools), or in the Local GPO (gpedit.msc).

THe setting you mentioned above is how the server will handle password and
the LanMan hashes. Changes this is usually only done to allow backward
compatibility for older legacy Windows clients, or for non-Windows clients.
So there really is no reason to change this in yoru scenario.


Show quoteHide quoteHonestly all these changes you are making are not needed to setup a simple
VPN server. I think you are looking at the whole thing as looking at an
elephant under a microscope. This is not required. Let's try to go back to
basics and get this setup and working first, then start making changes to
test your security levels.


So this is a standalone machine. Ok, that clears it up a bit, and actually
makes it easier.

By the way, did those links I provided you help in anyway?

Ace

WinXP cannot see domain
What is your favorite method to troubleshoot high-bandwidth/high latency networks?
Remote Network Monitoring
OWA Access Problem
NAT on a private network of a private network
mapping a Linux NFS share on windows 2008
Server 2003 - IIS - NLB and misc...
Allow administrator from external domain read access to my domain
DHCP Failover config
Workstation Services are not starting up on Server 2003