Yes, the .201 host needs to know how to reply. The packet is coming from a
Subnet that it does not know about, so it will send the reply off to its
(.201's) default gateway. If that gateway doesn't know how to get the packet
to 10.10.10.1 then things fall apart.
Simplest solution is to use DHCP for the RRAS dial-in users as well.
If there are only a couple servers the users need access to, then you could add
static routes to those servers (but I can almost guarantee this will get
forgotten and cause headaches in the future).
From a routing standpoint it's a little dirty, but you could add the static
route on your default gateway, pointing to the RRAS server for the 10.10.10
subnet.
You're close on this one. Let us know when you get it sorted.
-Tom Geairn
NewView Consulting, LLC
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On
Behalf Of dubaisans dubai
Sent: 01/04/2007 10:03 AM
To: James D. Stallard
Cc: focus-ms@securityfocus.com
Subject: Re: Secure Remote access - windows 2003
Looks like a routing problem to me too.
But I feel DHCP or static is NOT the issue. My static address pool is
10.10.10.1 -10.10.10.10.
On connection , Internet user is getting address 10.10.10.1 . When he
tries to ping 192.168.0.201, an internal machine - what will be the
source IP of that packet as seen by 192.168.0.201. If source IP is
10.10.10.1 then maybe I need to add a route for this 10.10.10.10
static pool on the internal host .201.
Any other suggestions?
On 1/4/07, James D. Stallard <james@leafgrove.com> wrote:
I'm not a routing expert, but I suspect you have configured your RRAS Server
to assign addresses from a pool of addresses, rather than use DHCP.
Under the Properties dialog for your server and in the IP tab you need to
check the box labelled Enable IP Routing and also the radio botton Dynamic
Host Configuration Protocol. You want to be using the existing internal DHCP
server to allocate addresses to your inbound VPN clients.
The good news is that if you decide to start from scratch it is a simple
matter to disable and re-enable RRAS and re-do your configuration with the
default settings.
Not sure why you enabled IP forwarding in the registry, the (very) basic
solution described does not require you to do so.
Cheers
James D. Stallard
-----Original Message-----
From: dubaisans dubai [mailto:dubaisans@gmail.com]
Sent: 04 January 2007 14:48
To: James D. Stallard
Cc: focus-ms@securityfocus.com
Subject: Re: Secure Remote access - windows 2003
Using the instructions I have successfully setup the L2TP/IPSEC tunnel up
till the gateway. Now if I want to access the internal network what else
should I do on the RRAS server. From Internet user machine I am able to ping
both the Internet interface and the internal interface [ 192.168.0.200] of
the RRAS server. But I cannot ping any other internal machine
[192.168.0.201].connected on the same LAN as internal network interface.
On the RRAS server I have enabled IP forwarding in the through Registry.
Address pool is configured and is getting allocated to Internet user when he
connects.
On 1/3/07, James D. Stallard <james@leafgrove.com> wrote:
You don't mention the number of users, but the budget suggests small
scale
:)
Windows 2003, SP1 and R2 provide RRAS, which will do L2TP/IPSEC, and
with WXP SP2 as your client you have 2048bit Diffie-Hellman encryption
available.
Setting up RRAS to perform this task is done in less than 20 minutes
and is easy to get through a firewall inbound (IE your firewall). The
problems you have to face are:
. If you wish to use pre-shared keys (the "cheapest" way of doing it)
you will need to configure the PSK passphrase on each client
individually - easy with a small number of clients. Otherwise, you
will need to invest in a certificate authority.
. This is only suitable for access by known machines, not for internet
café type environments.
. This solution works great for the remote home user, but is less
successful for your travelling salesmen using the client's internet
connection as they generally have the relevant ports/protocols blocked.
. The locally configured PSK may not be stored in a highly secure
manner on the client machines and could possibly become known in the
event a machine configured with it is stolen. You may find yourself
having to re-deploy a new PSK.
I wrote a quick and dirty step-by-step here:
http://www.leafgrove.com/view_article.asp?id=19&cat=16&state=plus
In case one of your configured laptops is stolen and an attempt is
made on your RRAS solution, pay attention to your account locking on
failed password settings. You want permanent locks on a small number
of attempts (say 5), thus forcing administrative intervention and
investigation in the event of an account becoming locked.
Cheers
James D. Stallard
-----Original Message-----
From: listbounce@securityfocus.com
[mailto:listbounce@securityfocus.com] On Behalf Of dubaisans dubai
Sent: 02 January 2007 04:17
To: focus-ms@securityfocus.com
Subject: Secure Remote access - windows 2003
I am planning to provide remote access from Internet to a windows 2003
domain
controller.User-ids, NTFS permissions are all configured.
The objective is file sharing and access.
Files will need to be copied. The machine has valid Internet IP
address and is
sitting behind a Firewall.
I would like to keep solution independent of Firewall.This will be
accessed by roaming users. I am thinking of something like 0penssh for
windows or maybe just GUI based Secure-FTP
Challenges I am facing
------------------------------------
Authentication should be strong. Something more than a password. [ No
budget for RSA securiD :-))) ]
Encryption for user-crentials/data access
Options considered
----------------------------------
I read W2K3 L2TP/IPSEC - looks complex. Terminal services - File copy
is not simple and also you require Application Mode license.
The number of remote users - less than 100
Cost effective , easy to implement and easy to manage solution sought
