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.
