Solved

Cisco Client VPN not able to Access Servers on the Remote Side of LAN-LAN IPsec VPN

Posted on 2006-11-23
9
441 Views
Last Modified: 2013-11-16
Hi Guys
I have been given the task of troubleshooting a network and this is what I am facing.

There is a Lan-Lan VPN between a VPN Concentrator and PIX 506.There are users using Cisco VPN client to conect to the VPN concentrator and access the LAN.Users behind the concentrator can access servers behind the PIX--So no problems between the connectivity between Concentrator and PIX.

Problem:-

Users who dialin through the VPN client to the Concentrator are not able to access servers on the other side of the PIX.

Please let me know if anyone has any questions and I will try to explain more.
I understand that this has something to do with reverse route injection but am not very sure how to go about it.
This is really urgent and any help would be really appreciated.
0
Comment
Question by:siddharthaparti
  • 3
  • 2
  • 2
  • +1
9 Comments
 
LVL 32

Expert Comment

by:Kamran Arshad
Comment Utility
Please check if the PIX is blocking the incomming connections or the connections of the Cisco VPN Client are not rejected by any Network Firewall on the client's end.
0
 
LVL 5

Accepted Solution

by:
jeffkell earned 400 total points
Comment Utility
Sounds like a routing problem - most likely the VPN Concentrator is not advertising routes in the dialup profile to the client for the servers subnet.   If you can provide some network diagrams it would help to answer your question, but I'll try to describe the problem.  If your servers are on a private subnet inside the PIX, say 10.20.30.x, the VPN client will have to receive a route to 10.20.30.x.  Assuming these are windows clients, get a command prompt and do "route print".  If you do not see a route to your server's subnet, there is your problem.

The route must first be advertised through the PIX (or else you are doing NAT at the PIX into one of the subnets visible to the outside of the PIX) making the route visible to the concentrator (if it is running a dynamic routing protocol) or have static routes in the concentrator.

If your VPN configuration is setup for split tunnelling, you absolutely must have routes visible at the client end.  If your are not doing split tunnel, the route must be visible to the concentrator.
0
 
LVL 2

Author Comment

by:siddharthaparti
Comment Utility
hey guys
Thanks for the inputs. I will give the subnets and the interfaces of the network. jeffkell you are right..There is no routing entry when I check the stats in the VPN client.But am confused as to which route to add on the concentrator.Maybe the ip addresses and interfaces would help..

Concentrator(Site1)--->
Interface Outside(Connecting to PIX for LAN to LAN VPN)-- 61.16.157.100
Interface Inside(Inside Network of Site1)-- 192.168.1.0/24
IP Pool for Cisco VPN Clients-- 192.168.2.0-254/24
Server A--- 192.168.1.20/24

PIX(Site2)--->
Interface Outside(Connecting to Conc. for LAN to LAN VPN)-- 220.227.153.225
Interface Inside(Inside Network of Site2)-- 192.168.10.0/24
Server 1-10--- 192.168.10.5-192.168.5.15/24

What's Working............
1) Cisco VPN client are getting the ip address from 192.168.2.0/24 subnet and are able to connect to LAN side of Conc(Site1). They are able to access Server A on Concentrator inside network.
2) Hosts from inside n/w of Concentrator are able to access hosts on PIX inside interface and vice versa.

What's not Working..........
The clients who are getting the IP address of 192.168.2.0/24 subnet are not able to access servers or hosts on 192.168.10.0/24 subnet(Inside network of PIX).

Diagnosis..................

No route found on the Cisco Clients for 192.168.10.0/24 .


Solution........

Apparently add a route on the conc. for 192.168.10.0/24.

Doubt......

What would be the exit interface on the Concentrator for the network 192.168.10.0.


I hope I am clearer with the problem. More to do with my infamiliarity with VPN3K Concentrators.



0
 
LVL 5

Expert Comment

by:jeffkell
Comment Utility
If I understand correctly, your "Site1" and "Site2" are simply connected by the public internet?  Or do you have an IPSec tunnel connecting the two?

I assume that since you say you have connectivity in (2) that there is an IPSec tunnel (didn't know a VPN3K could do that?) or is that routing being done by another router?  For your hosts in (2) inside the concentrator, what does 'route print' give as their route to 192.168.10.0/24?  That route must be known to the concentrator, and advertised back to the VPN clients.  You should be able to ping the 192.168.10.0/24 hosts from the concentrator.
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 23

Assisted Solution

by:Tim Holman
Tim Holman earned 100 total points
Comment Utility
It's a general Cisco security principle that traffic can't leave the same interface from which it arrives, so would recommend you setup an internal router:

Router / Servers
|
VPN 3000
|
Internet
|
PIX
|
Servers

That way, clients will dial into the VPN 3000, see the servers as normal, but the default route on the VPN clients has to be something internal (ie an internal router), in order to be routed back out, through the site-site VPN tunnel and into the other server farm.

0
 
LVL 2

Author Comment

by:siddharthaparti
Comment Utility
jeffkell
Yes there is a IPSec tunnel between the two. I am going to get back to u with the other details.
Tim
You are right but this is possible now with Pix 7.X IOS versions and also on 4.x version of conentrator.
0
 
LVL 23

Expert Comment

by:Tim Holman
Comment Utility
Good point - I didn't realise... :)

To get client RRI working:

1)  Enable client RRI on the VPN concentrator
2)  Setup RIP or OSPF on the VPN virtual interfaces
3)  Do same on PIX

http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_example09186a0080094a6b.shtml
0
 
LVL 2

Author Comment

by:siddharthaparti
Comment Utility
Hi Guys
The Solution that worked was:-

1) Added the remote LAN networks in the route list of the concentrator.
2) Created Access lists on the PIX permitting the Client VPN subnet.

This worked!!!!!
Thanks for all your help.
0

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Ransomware continues to be a growing problem for both personal and business users alike and Antivirus companies are still struggling to find a reliable way to protect you from this dangerous threat.
Find out what Office 365 Transport Rules are, how they work and their limitations managing Office 365 signatures.
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
This tutorial demonstrates a quick way of adding group price to multiple Magento products.

763 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now