Go Premium for a chance to win a PS4. Enter to Win

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
?
451 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
8 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
Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

 
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

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

Question has a verified solution.

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

Sometimes Administrators rights are not enough. These cases call for the SYSTEM account. The process in this article outlines the steps required to execute commands using the SYSTEM account.
Ransomware - Defeated! Client opened the wrong email and was attacked by Ransomware. I was able to use file recovery utilities to find shadow copies of the encrypted files and make a complete recovery.
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…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…

783 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