Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

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

Posted on 2006-11-23
9
Medium Priority
?
450 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 1200 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
Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

 
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 300 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

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

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

IF you are either unfamiliar with rootkits, or want to know more about them, read on ....
What we learned in Webroot's webinar on multi-vector protection.
Email security requires an ever evolving service that stays up to date with counter-evolving threats. The Email Laundry perform Research and Development to ensure their email security service evolves faster than cyber criminals. We apply our Threat…
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 …

715 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