L2L vpn with Palo Alto Firewall

[evoight]

I am setting up a l2l tunnel with a palo alto firewall and having trouble.  It is a fairly simple setup, we are encrypting public to public traffic for sftp upload from the asa side.  Here are the relevant parts of the config and various outputs...  Remote side admin states that phase 1 passes and we experience a timeout waiting for phase 2.  Any help would be appreciated.

1.1.1.1 (customer2 destination address)
1.1.1.2 (customer2 vpn gateway)
2.2.2.0 (local public ip space)

name 1.1.1.1 CustomerVPN2 description Customer VPN2

access-list Inside_nat0_outbound extended permit ip 2.2.2.0 255.255.255.240 host CustomerVPN2
access-list Outside_4_cryptomap extended permit ip 2.2.2.0 255.255.255.240 host CustomerVPN2

crypto map Outside_map 4 match address Outside_4_cryptomap
crypto map Outside_map 4 set connection-type originate-only
crypto map Outside_map 4 set peer 1.1.1.2
crypto map Outside_map 4 set transform-set ESP-AES-256-SHA

crypto isakmp policy 50
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 86400

tunnel-group 1.1.1.2 type ipsec-l2l
tunnel-group 1.1.1.2 ipsec-attributes
pre-shared-key *

sh crypto isakmp (notice listed as type:user)

8   IKE Peer: 1.1.1.2
    Type    : user            Role    : initiator
    Rekey   : no              State   : MM_WAIT_MSG2

debug crypto ipsec (Looks like it tries all crypto maps except the relevant one)

IPSEC(crypto_map_check): crypto map Outside_map 1 does not hole match for ACL Outside_1_cryptomap.

IPSEC(crypto_map_check): crypto map Outside_map 2 does not hole match for ACL Outside_2_cryptomap.

IPSEC(crypto_map_check): crypto map Outside_map 3 does not hole match for ACL Outside_3_cryptomap.

IPSEC(crypto_map_check): crypto map Outside_map 3 does not hole match for ACL OO_temp_Outside_map3.

and finally.

Oct 03 10:39:09 [IKEv1]: IP = 1.1.1.2, Removing peer from peer table faile
d, no match!
Oct 03 10:39:09 [IKEv1]: IP = 1.1.1.2, Error: Unable to remove PeerTblEntr

[evoight]

I am also getting this

IKE Initiator unable to find policy: Intf Inside, Src: 2.2.2.2, Dst:1.1.1.1

2.2.2.2 is outside ip of asa

1.1.1.1 is vpn traffic destination.

[manish arora]

MM_WAIT_MSG2 = The phase 1 is unable to complete due to either wrong Peer information or isakmp policy mismatch between the peers. Please check the palo alto site for Peer Address and ISAKMP policy.

Phase 1 success should show MM_ACTIVE in that output.

Manish

[Lee Valentin]

I've seen this before during Phase 2, the Palo Alto is expecting hostname or key-id as the identity and not IP address.

Please check the logs from the Palo Alto.

I don't see the following line in your configs above

crypto isakmp identity <     >

[evoight]

Thanks Lee and Manish

I have no access to the palo alto logs.  I am working with the admin at the other end and this is what he said.  I used the real ip's because it was getting too confusing... 

I figured out what is wrong.  It didn’t click at first but because my firewall uses “route-based” VPNs as opposed to the “policy-based” VPNs on an ASA, I need to specify a route for your source address(es) which is 66.x.x.48/28.  The issue with that is when my gateway tries to respond to your gateway IKE packets, it is trying to send it over the route that I specified, since 66.x.x.62 is included in this network, and the firewall tries to send the IKE response packets over the tunnel that doesn’t exist.  I changed the route to be 66.x.x.48/32 and it was successful with IKE phase 1 but fails on phase 2 because it is sourcing from 66.x.x.62/32.

So long story short of what we need to do.  Either you need to NAT your internal address to a different public IP on that firewall or I can assign you a transit network IP (such as 192.168.74.55 or something) and you would NAT that internal address to that transit IP

Not sure how to translate the traffic for this vpn without changing the global nat, it looks like policy nat is the solution.

[manish arora · Accepted solution]

Hi Evo,

Is you asa public interface is same as the Public ip that you are trying to encrypt ?

I think you have to create a policy Nat which can be a private ip as well and then use it as your side of interesting traffic, as the Palo Alto Admin is right about the route based vpn.

Here's some useful links for policy based Nat & paloalto side vpn screen shots and some explainations.

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807d2874.shtml

http://www.danielelonghi.com/wp-content/uploads/2011/05/Howto-create-VPN-connection-between-Junos-and-Paloalto.pdf

http://netsecinfo.blogspot.com/2008/02/route-based-vpns-explained.html

Manish

[evoight]

Hello Manish,

You are correct.  The asa public interface is both the vpn endpoint and the global nat ip for the internal users.  Thanks for the help and suggestions.

Eric

[evoight]

Just as an FYI...  The tunnel would not connect using the policy nat until the "originate only" setting on the connection profile was turned to bi-directional.  Not sure why this would be but, that was the case.