PIX 515 VPN triggering problem

alexodin · ‎02-08-2010

Hi guys,

I have PIX-515 Cisco PIX Firewall Version 6.3(5). I configured new VPN tunnel however it is not starting. I can see that hit count is increasing for VPN crypto access list (and all other access lists, see configuration bellow) . I monitored outside interface - no IKE traffic was captured. Debug crypto isakmp or ipsec does not show any activity related to VPN creation. Do you have ideas why VPN tunnel creation is not triggered even if there is traffic that has to be encrypted?

VPNs to other partners are working.

Here is configuration (I have changed actual IP addresses):

object-group network PARTNER-HOSTS
network-object host 192.168.1.135
network-object host 192.168.1.136

object-group network INTERNAL-NET
network-object 172.16.1.0 255.255.255.0

access-list From-Partnet-Net-DMZ permit tcp object-group INTERNAL-NET object-group PARTNER-HOSTS eq 7130
access-list Policy-NAT permit ip object-group INTERNAL-NET object-group PARTNER-HOSTS
access-list cryptomap-to-PARTNER permit ip host 1.1.1.11 object-group PARTNER-HOSTS

access-group From-Partnet-Net-DMZ in interface PARTNER-NET-DMZ

global (outside) 3 1.1.1.11
nat (PARTNER-NET-DMZ) 3 access-list Policy-NAT 0 0

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map PartnerVPNs 320 ipsec-isakmp
crypto map PartnerVPNs 320 match address cryptomap-to-PARTNER
crypto map PartnerVPNs 320 set pfs group2
crypto map PartnerVPNs 320 set peer 2.2.2.1
crypto map PartnerVPNs 320 set transform-set ESP-3DES-SHA
crypto map PartnerVPNs 320 set security-association lifetime seconds 3600 kilobytes 4608000
crypto map PartnerVPNs interface outside
isakmp enable outside

isakmp key ******** address 2.2.2.1 netmask 255.255.255.255

isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash md5
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400

Farrukh Haroon · ‎02-08-2010

You ACLs are obviously wrong.

access-list Policy-NAT permit ip object-group INTERNAL-NET object-group PARTNER-HOSTS
access-list cryptomap-to-PARTNER permit ip host 1.1.1.11 object-group PARTNER-HOSTS

Both of these ACLs should be same. What is 1.1.1.11? The crypto ACL is supposed to mention your LOCAL LAN in the source IP, and not your VPN endpoint/gateway IP (Router).

Also the third ACL, why is it only allowing port 7130 traffic?

access-list From-Partnet-Net-DMZ permit tcp object-group INTERNAL-NET object-group PARTNER-HOSTS eq 7130

Regards

Farrukh

alexodin · ‎02-08-2010

Hi Farrukh,

Thank you for your reply. Here are my answers:

1. Internal private IP addresses (172.16.1.0/24) are translated to public IP address 1.1.1.11 according to Policy-NAT access list and other NAT configuration. 1.1.1.11 is not IP address of my VPN peer IP. It is source IP address of traffic going through the VPN tunnel to our partner network.

2. I would not like to allow all TCP traffic to go through the VPN. Therefore I allowed only traffic to destination TCP port 7130

Regards,

Alexey

Farrukh Haroon · ‎02-09-2010

1) You don't reallly need to NAT your 'INTERNAL-NET' when going out to the Partner. Is this a business requirement? Do you wan't to hide the 172.16... network from the Partner? This network will remain hidden in the VPN tunnel anyway (as you are using tunnel mode) from all devices in Transit. If NAT is not a requirement, remove the NAT for the Internal >> Partner net communication, and modify your crypto ACL to be as the same as the Policy NAT ACL.

Even IF you require NAT, then also try modifying the ACL as above. It could be that you hitting an 'order of operation' related issue (NAT and crypto functions). I will check the exact order and get back to you.

I would also recommend to post the output of the packet-tracer command, it would tell you what exactly is going wrong.

packet tracer input PARTNER-NET-DMZ tcp 172.16.1.1 1025 192.168.1.135 7130 detailed

2) I would recommend to at least enable ICMP traffic in the ACL till you troubleshoot this issue.

Regards

Farrukh

alexodin · ‎02-09-2010

Hi Farrukh

We have many VPN tunnels to our partners where connection is initiated on our side (we are client, they are server). I would like to hide internal IP address space by doing NAT to public IP address. This will give us flexibility to change our internal IPs without need to reconfigure crypto access lists for all VPNs. Also from security perspective we do not fully trust our partners. Therefore we have restrictive access lists for traffic going to and from our partners.

I cleaned all SAs on firewall. After that new VPN tunnels came up. So it is not problem in the configuration itself. Is it possible that somehow firewall gets into the status where new VPNs could not be initiated? I am wondering if somebody else had this problem. How can I troubleshoot if firewall is in some corrupted status? I checked CPU usage and syslog, nothing unusual.

I cannot clean SAs on production firewall for every new VPN. It causes downtime for all other services.

Thanks for help,

Alexey

Farrukh Haroon · ‎02-09-2010

Thats a perfectly valid reason then.

Just enable IKE/NAT-T keep alives. As the SAs could timeout due to idle sessions/NAT timeout issues.

http://cisco.biz/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml#solution01

Regards

Farrukh