If the LAN hosts don't have a route through the RRAS server to the
VPN clients, they can't respond to traffic that comes from the VPN
clients.
You have two options:
1. adjust your network routing path to include a route to the VPN
client subnet through the RRAS server
2. enter manual routes on only hose hosts that should be reachable by
the VPN clients.
Personally, I'd go with #2; it's more management, but it provides a
small measure of security since the VPN client cannot establish
connection with the LAN host that is lacking such a route.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of dubaisans dubai
Sent: Thursday, January 04, 2007 8:03 AM
To: James D. Stallard
Cc: [email protected]
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> Sent: 04 January 2007 14:48
> To: James D. Stallard
> Cc: [email protected]
> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of dubaisans dubai
> > Sent: 02 January 2007 04:17
> > To: [email protected]
> > 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
> >
> >
> >
> >
>
>
>
>
All mail to and from this domain is GFI-scanned.
