• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 312
  • Last Modified:

Problems with PIX VPN

Im having some difficulties when trying to connect VPN remote users to a PIX 501.

I use cisco VPN client to connect to the 501. Everything works fine, the clients connect and can work perfectly, no problem so far. Now i need to solve a problem i find when connecting to specific servers, i explain:

Lets say i have an internal LAN with 192.168.1.0/24 (192.168.1.254 for the PIX). I have a pool selected in the PIX for the VPN clients which is 10.0.0.10-10.0.0.20. When clients connect, they communicate with any server in the internal LAN, as long as the server has its default gateway pointing to the PIX (192.168.1.254). The problem is i have several servers that need to use another default gateway (WAN), and with these, the VPN clients cannot communicate, because the servers' replies dont go back through the PIX.

Then i thought: if i choose a pool like for example 192.168.1.10-192.168.1.20 for the VPN clients it should work. Well, it doesn't. Am i missing something? Shouldn't it work with the second pool?. Actually, i know it can work because it used to work before the PIX with an ISA server instead of it.

I know that placing static routes to the first pool in every server would solve the problem, im trying to avoid this solution, because as i said, it worked with ISA server, so i almost sure it has to work with the PIX, right?

Thanks
0
llandajuela
Asked:
llandajuela
  • 2
1 Solution
 
lrmooreCommented:
In case you haven't noticed yet, the PIX is nothing like the ISA server and does not work the same way.
You have two issues to deal with. First is that you are using 192.168.1.x . This is absolutely the single most common subnet used by home / soho users with broadband connection. Next  most common is 192.168.0.x, next is 10.0.0.0. The obvious solution to this is to use a different subnet on your company network. Something outside the common ranges, but still private, like 192.168.225.x or 172.32.x.x
Next issue is the way the PIX handles the connectivity between local lan and VPN connections. To function properly, these two need to be in separate subnets, mainly because of the nat-0 acl that you have to use. There is a workaround, however. If you divide your local LAN into maskable areas, but not true subnets, you can still cheat the PIX. For example, if you can split your network in two by assigning only addresses >.128 to your LAN, and addresses < .128 to the VPN pool, then you can use a mask in the acl, without actually changing the mask on the LAN subnet..
Demonstration:
   ip address inside 192.168.1.254 255.255.255.0
   ip local pool VPNPOOL 192.168.1.10-192.168.1.100
   access-list Nat_zero permit ip 192.168.1.128 255.255.255.128 192.168.1.0 255.255.255.128
   nat (inside) 0 access-list Nat_zero

Now, the VPN clients get assigned an IP address that "appears" to be local to the servers that do not have their gateway pointing to the PIX.

One other easy workaround is to get on the router/firewall that those servers normally point to as their default and put in a static route there pointing the 10.0.0.0 /24 subnet to the PIX 192.168.1.254. Unfortunately, if it is a firewall like another PIX, this simply won't work because the PIX won't do a redirect.
0
 
llandajuelaAuthor Commented:
Thanks lrmoore for the rapid answer.

Yes, of course i have noticed the difference, in fact, thats why i changed from ISA to the PIX. I just wrote about the ISA because it worked fine, using a VPN pool in the same subnet as the inside LAN, and i still dont understand how.
Ip addreses mentioned in my post are not the real ones, i thought it was easier than writing things like X.Y.Z.W.

Im afraid im not able to divide the inside LAN as you mentioned, Ip addreses are already asigned to the servers and the VPN pools, and the VPN pools are in the middle of the LAN range.

I liked the final idea of placing the static routes in the WAN router, it is a router and i think i will be able to do it.

But, just in case, i would like to know if there is another solution you can think of.
0
 
lrmooreCommented:
You can try this - no guarantees that it will work...

 ip local pool VPNPOOL 192.168.1.17-192.168.1.30
   access-list Nat_zero permit ip any 192.168.1.16 255.255.255.240
   nat (inside) 0 access-list Nat_zero
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now