Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

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

Cisco Pix 501 to Cisco ASA 5510 Site to Site VPN Private IP Network Issues

Our company has recently given the go ahead for a new server farm to be build and designed by myself and hosted out of a carrier collocate in SLC, UT.  I have finished building the new servers and implementing the new network devices.  I decided to setup a test site to site vpn tunnel to my home where I am using a Cisco PIX 501 while the web farm is using a Cisco ASA 5510.  After configuring the IKE parameters, NAT 0, Access-lists, transform-sets, and crypto-maps I was up going.  The Cisco Pix is running OS 6.3(5) and the ASA is running 7.1(1).  Now let me give some detail on the networks behind the ASA.  I have two networks off of the ASA, one network is 172.x.10.x and the second network is 172.x.20.x  Now the 172.x.20.x network hosts our app servers and database server while the 172.x.10.x network hosts our web servers along with a F5 Big-IP 2000 loadbalancer.  The Loadbalancer has a private ip address of 172.x.10.50.  The two web servers that we have uplink directly into the loadbalancer.  There is a seperate internal vlan off of the loadbalancer that the web servers run on.  That network is 172.x.60.x  The IP address of the first web server is 172.x.60.5 and the second web server is 172.x.60.7.  The loadbalancer uses NAT to convert the 172.x.10.x network to the appropriate 172.x.60.x nodes.  For example, the web server according to the ASA is 172.x.10.5 while the loadbalancer NATs the address to 172.x.60.5.  We have a static NAT setup on the ASA to translate a public IP to a loadbalanced 172.x.10.70 address to be balanced between the two web servers.  If I ping the 172.x.10.5 web server from the ASA i receive replies back, but for some reason when I am connected from home using the VPN tunnel I can't communicate with the 172.x.10.x network.  Both the 172.x.20.x and the 172.x.10.x networks have been allowed on the access-lists so I can't figure it out.  Especially since the ASA can get replies, but my VPN connection can't.  What am I doing wrong??  I can talk to everything perfectly on the 172.x.20.x network using the VPN tunnel, but nothing on the 172.x.10.x network.  Do I need to add to the access-list a permit statement to network 172.x.60.x??
1 Solution
>Do I need to add to the access-list a permit statement to network 172.x.60.x?
  No, not if the 172.x.60.x network is being NAT'd by the loadbalancer & the web servers are connected directly to it exclusively. That means the ASA has no knowledge of the 172.x.60.x subnet, & doesn't need to anyway since it's being NAT'd by the F5.
  Are there any ACLs applied to the ASA's 172.x.10.x interface that may be preventing return traffic to the VPN tunnel?
  Do you have separate ACLs for 'nat 0' & another for matching the site-to-site VPN traffic? You should have some entries similar to the following on the ASA, & complementary entries on the 501 (only the most pertinent parameters are cited below):

  [ don't use 'permit ip any...' in your 'nat 0' or site-to-site ACLs, you must be specific ]:
access-list nonat_acl permit ip 172.x.10.x <PIX 501 LAN> <mask>
access-list nonat_acl permit ip <other optional subnets on ASA side to go over VPN tunnel>  <PIX 501 LAN>...
access-list site_matching_acl permit ip 172.x.10.x <PIX 501 LAN> <mask>
access-list site_matching_acl permit ip <other optional subnets on ASA side to go over VPN tunnel>  <PIX 501 LAN>...
nat (inside) 0 access-list nonat_acl
crypto map mymap 1 match address site_matching_acl
crypto map lynmap 1 set peer <PIX 501 public IP>

If you need further help, people here would really need to see complete sanitized configs for both ASA & PIX 501 (passwords removed, public IPs masked like so: x.x.x.39, but *don't* mask out private IPs such as: 192.168.x.x, 10.x.x.x, or 172.16.x.x-172.31.x.x).


Featured Post

The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

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