I configured a static Site-to-Site IPsec VPN tunnel between the Cisco ASA firewall and the Palo Alto next-generation firewall. If the same phase 1 & 2 parameters are used and the correct Proxy IDs are entered, the VPN works without any problems though the ASA uses a policy-based VPN while the PA implements a route-based VPN.
I made a few screenshots from the VPN configuration of both firewalls which I will show here. I am also listing a few more hints corresponding to these two firewalls.
My test laboratory looks like that:
The tested Palo Alto PAN-OS version was 6.0.0, while the Cisco ASA version was 9.1(4).
Note that I am not showing the creation of the phase 1 & 2 parameters since I named them accordingly to their types. I am always using AES-256, SHA-1, DH-5, and a lifetime of 28800 seconds for IKE and 3600 seconds for IPsec. The IPsec protocol is ESP.
Also, note that there is no way to establish the VPN tunnel by the firewalls themselves. The Cisco ASA has no option to ping the other side in general, while the Palo Alto tunnel monitor only supports numbered tunnel interfaces. But since the Cisco ASA only works with unnumbered tunnel interfaces, this option on the PA cannot be used as well.
The creation of the route-based VPN involves the following steps: tunnel interface, IKE gateway, IPsec tunnel with proxy IDs, and static route through tunnel interface. The following screenshots show these steps. Note the additional descriptions under each screenshot:
Finally, remember that the Palo Alto needs a permit policy entry on the untrust zone in order to allow incoming/outgoing packets for ike (500) and ipsec-esp. That is, “from untrust to untrust”. Refer to the traffic log and search for deny statements if the VPN does not establish.
The creation of the policy-based Site-to-Site VPN on the ASA contains the following steps: Group Policy and Connection Profile. These two steps will create the complete Crypto Map entry as well, which I will show for the sake of completeness, too:
Monitoring the VPN Sessions
If the VPN creation was successful, the Palo Alto has two sessions in its Session Browser. One for ike and on for ipsec-esp:
Furthermore, the green bubbles on the IPsec Tunnels pane turn into green:
However, I noticed that the connection was *sometimes* recognized as “ciscovpn” and then denied by my cleanup rule. Note that the port “500” is always the same, while the application changes:
Therefore, I modified the untrust-untrust policy to also allow “ciscovpn”. (Which one more time produced these annoying dependency warnings which are not useful in this case!):
On the Cisco ASA, the VPN sessions monitor shows the established VPN with the appropriate parameters:
28 thoughts on “IPsec Site-to-Site VPN Palo Alto <-> Cisco ASA”
Nice article. Am I able to create a site to site VPN if I only have one layer 3 interface? Mine is 18.104.22.168/28 so how do I know which IP address to use and does it render it useless for everything else?
Hey Phillip. Sorry, I did not fully understand your question.
Both firewalls must have an “untrust/outside” layer 3 interface that is able to reach the one from the other firewall.
Furthermore, both firewall should have a “trust/inside” layer 3 interface for the private traffic that should flow through the VPN tunnel. It should look very similar to my lab.
Can you please send me migration tool link. Actually i want migration from ASA firewall to Paloalto if you have any link send me.
One thing more you know Checkpoint Firewall policy if you any documents. Please send in mentioned email id
sorry, I do not have any links to migration tools or the like. Please ask your Palo Alto SE (or Google ;)) for that.
Thanks for a super article, it’s helped me as my Cisco knowledge is weak. Here’s another tip for anyone else who struggles like me – use a Cisco VPN configuration generator to start off your config, and then tweak it from there. Here’s a good one I use – http://www.whyaws.com/tools/cisco_gen.htm
Not accurate about the ASA not having the ability to ping through the tunnel:
“ping inside dst_ip” should bring the tunnel up normally.”
Palo also has the ability to do this from the CLI using the “test vpn” command subset. You can manually bring up P1 and P2 this way.
Yes, that is correct for a “manual” ping command. What I was searching for is an “automatic” ping that is issued every x seconds in order to have the tunnel up everytime. Normally, I want to look at the VPN tunnel section and want to see if everything is fine by just looking at the “up up up” counts. ;)
You can do that with IP SLA on the ASA, but the source interface will be “Outside” instead of “Inside” with a destination internal address on the opposite side of the tunnel. The pings will fail, but the tunnel will stay up.
I am trying to create site to site VPN between Palo Alto firewall and cisco ASA.
The tunnel is up but the traffice doesn’t go through. Any idea for this issue?
The software version on Cisco ASA (8.0.4) and Palo Alto 6.1.15. Are these devices compatible with each other for the Site to Site VPN? The fast response is appreciated. Thank you.
are both phases completed? What can you see in the ASA VPN monitor? There are counters for “Tx” and “Rx”. Are both zero? Or only one of them?
Have you double checked the tunneled networks (Proxy-IDs?) on both devices? They must match exactly!
Have you added the route on the Palo Alto to the tunneled networks?
Thank for you fast response. Both Phases are completed. Can see green light in IP Sec Tunnel.
I can only see zero in Rx . I do check the Proxy-IDs. The ip address(Local IP address) are match exactly in both side.
For adding route in palo alto, in Destination – Cisco ASA Ip address and in next hop – WAN link IP address (Because I want to use secondary WAN link for site to site vpn)
No, that’s wrong. Please refer to my screenshots: The static route has a destination interface of the tunnel-interface from the VPN tunnel! The ip address can be set to “None”.
You must route the VPN traffic to the tunnel-interface! This has nothing to do with your “real” path to the Cisco ASA, which might go through your secondary WAN link. That is: The tunnel (phase 1, phase 2, encapsulated traffic) goes through your routing table through your secondary WAN interface. However, the tunneled packets (that are INSIDE the VPN) must go through the tunnel-interface.
So that’s mean I should choose ‘None’ in ‘Next Hop’, rt?
May i test and update you tmw.
Thanks again :)
Hi I already changed. But still can’t go through
Have you reviewed your policies? Please have a look at the Traffic Log and search for your traffic. Maybe it is simply blocked? (This will only be shown there if you have an explicit “deny any any” with “log” enabled.)
I am ISP IT Manager and i see the same problem in our network.
We have wired and wireless network with OSPF and if its a problem with some connections OSPF route all traffic from a different direction , all connection goto the same datacenter and go out from the same BGP server.
Sometimes when route change CISCO ASA leave IPSEC UP but look like it present Himself with private ip…
We have all Mikrotik router in front at CISCO and in many cases Customers have Mikrotik routers too attached to same connections and all VPN work also after route changed…
Someone have same experience ?
One factor I found in setting up a L2L tunnel between a Cisco ASA And the Palo Alto is that the Palo Alto does not accept FQDN (which the ASA sends by default, I found out later). I have multiple L2L tunnels setup with varying devices (Cisco/non-Cisco). Thought no problem with the PA. Configured my tunnel and started testing. Error MSG6 kept coming back (relates to password authentication/mismatch). The PA admin saw the message and found a link on PA website. Basically said the PA does not respond to FQDN and will not form a tunnel with such a device. the resolution was to run the command “isakmp identity address” on the ASA which has the ASA send the IP address of the device. Once applied the tunnel came up and has been solid.
I had this error as well. Found when connecting to a PA that I had to issue the “isakmp identity address” command to get Phase 1 to complete.
Are you speaking specifically of Phase 1 Main Mode identifiers? If so, the ASA uses source IP address by default, not FQDN. You have to specify FQDN in your config for it to function as you suggested. “isakmp identity address” is the default on the ASA and has been as long as I’ve been working on them (since they were PIX firewalls). I would ask whoever manages your ASA to take a look at their config and set it back to default. Palo Alto also does support FQDN as of the latest releases:
Great post. solved my problem.
does anyone have steps to configure palo-alto vm series deployment on AWS cloud and create a ipsec vpn with palo alto on-premise
sorry, I have not yet worked with the AWS cloud. But as far as I know there should be no difference in configuring anything on a Palo VM compared with an on-prem firewall. Isn’t the GUI exactly the same?
thank you for this great job
we have configure the site to site and the the tunnel is up in both side Cisco and palo alto but there is no traffic inside the tunnel the Rx and Tx showing 0 (we did check the access-list and add static route fro the ASA to the Palo Alto network (server) and also
note: we try the same method between palo alto and Cisco router the problem hear is the ping reply is intermittent (one reply one time out ) we change the mtu and tcp MSS a lot of time with no lock also )
the senior is we have one server behind the router want to reach privet server behind palo alto on deffrent compny ) can i get any help from you to sort this issue out
I am sorry, but it’s kind of impossible to troubleshoot such issues without having access to the devices. Please verify that both phases (phase 1 and 2) are running. If everything is up, check the proper routing. And NAT. You shouldn’t do NAT when routing between private IPv4 addresses (unless you have overlapping segments).
When you have something like “one reply one time out” then it’s possible not an MTU/MSS problem but a routing load-balancing problem in which every second packet is routed something elsewhere.
thank you for your support and great job
the problem was solved and yes it was routing problen from out isp the issue was a route loop issue in our isp provider when we do tracing the path is clearly shown that
This is Anwer, actuallu we just formed the ipsec tunnel between Palo Alto and Cisco ASA Firewall, however when ipsec is getting down, the re-connection time between both is 3-4 mins, to make the ipsec tunnel up.
Do you have any idea what can we check/change to resolve this long period.
sorry, I don’t have a quick idea for your problem. You have to check the logs on both sides. Why is the VPN even going down? What is the exact time between your reconnects? Maybe a timeout? Is there any middlebox in between the peers?
Would you kindly supply the CLI version of the ASA configuration, please?
I am sorry, but I don’t have this setup anymore. ;(
But I am sure you will find someone with some kind of ASA firewall and a running ASDM.