Solved

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

Posted on 2006-11-23
9
448 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
  • 2
  • +1
9 Comments
 
LVL 32

Expert Comment

by:Kamran Arshad
ID: 18009118
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
ID: 18010409
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
ID: 18013278
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
Does Your Cloud Backup Use Blockchain Technology?

Blockchain technology has already revolutionized finance thanks to Bitcoin. Now it's disrupting other areas, including the realm of data protection. Learn how blockchain is now being used to authenticate backup files and keep them safe from hackers.

 
LVL 5

Expert Comment

by:jeffkell
ID: 18013338
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
 
LVL 23

Assisted Solution

by:Tim Holman
Tim Holman earned 100 total points
ID: 18014241
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
ID: 18016639
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
ID: 18018389
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
ID: 18201247
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

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Here's a look at newsworthy articles and community happenings during the last month.
This process allows computer passwords to be managed and secured without using LAPS. This is an improvement on an existing process, enhanced to store password encrypted, instead of clear-text files within SQL
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
Suggested Courses

626 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