Re: Routing and Remote Access - Authentication Failure
- From: "Ace Fekay [Microsoft Certified Trainer]" <aceman@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 7 May 2009 13:31:05 -0400
"George Valkov" <a@xxxxx> wrote in message news:uvaHtVzzJHA.4736@xxxxxxxxxxxxxxxxxxxxxxx
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.
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).
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.
Usually this is not a problem. It is done everyday by remote users connecting to their company networks.
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.
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.
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.
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.
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.
Relay the DHCP Request, not relay "DHCP," but I'm sure that's what you meant.
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
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.
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.
Honestly 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.
| 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.
Yes, it is allowed to dial-in in the SAM on the VPNSERVER.
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
.
- References:
- Routing and Remote Access - Authentication Failure
- From: George Valkov
- Re: Routing and Remote Access - Authentication Failure
- From: Matrixx333
- Re: Routing and Remote Access - Authentication Failure
- From: George Valkov
- Routing and Remote Access - Authentication Failure
- Prev by Date: Re: network disconnect problems
- Next by Date: Re: Home Network Dilemma
- Previous by thread: Re: Routing and Remote Access - Authentication Failure
- Next by thread: How max sessions per user support a windows 2003 folder share?
- Index(es):
Relevant Pages
|
