Problems creating IPSec VPN to Cisco ASA

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problems creating IPSec VPN to Cisco ASA

L1 Bithead


I have been having difficulties trying to configure an IPSec tunnel between a PA500 and Cisco ASA.  I can get the tunnel up as it show's as green under the IPSec section however no traffic seems to flow through the tunnel and there is no connectivity.  I am essentially using the IPSec VPN to allow a GRE tunnel from a partner companies router on the remote site to a router on the internal network side of the PA500.  The basic network setup is as follows;


3x physical interfaces, one in outside zone, one in DMZ zone and one internal

1x loopback interface which I have assigned a public IP address and is used as the VPN endpoint.  This was placed in the outside zone

I have created an IKE and IPSec crypto policy which matches the requirements of the peer ASA and I have also created a IKE Gateway which uses the loopback interface, this uses PSK for authentication.  There is also the IPSec tunnel configuration which uses the local IP address of the GRE router as te local proxy address and the public IP address of the partner ASA as the remote proxy address.  The protocol uses "any"  (on the actual router itself the GRE tunnel interface has a source of which matches this local proxy address and a destination that matches the public IP address of the ASA).  I also created a static route for the public IP address of the remote ASA.  A security policy was then created to allow ike and ipsec-esp from the loopback VPN interface to the public IP of the ASA, I also created a reverse rule; these were called Outbound VPN and Inbound VPN.

The tunnel does not come up straight away however if I run the following commands it does establish.

test vpn ipsec-sa tunnel VPN_TUNNELx

Then when I go back into the IPSec tunnel under Network it show's green, so I am assuming that the IKE and IPsec polcies match and also the routing and proxy IDs...

However when I try the following command;

show vpn flow name VPN_TUNNELx

It doesnt show any packets being sent or received. 

I ran a continous ping from the internal router to the other GRE tunnel endpoint on the other side of the ASA to generate some traffic, then looked at the Traffic under the Monitor tab to see if anything was being detected and could not see anything other than the IKE traffic for the VPN tunnel...

Im at a bit of a loss as to what to look at next, I'm guessing I also need to create a rule to allow the GRE traffic from the internal zone to the outside zone and also reverse perhaps?  I was hoping to get some guidance on what area's to focus troubleshooting on as I'm very new to Palo Alto! 

Many thanks in advance!



L4 Transporter

After doing the ping run this command.

Show session all filter source [test PC IP addr]

This should return several sessions with a session ID#

Show session id xxxxx

Now look at the ingress and egress interfaces. Packets should ingress from the corresponding ethernet and they should egress out interface tunnel.x.  Also look at the packets sent and packets received. You will probably see one way traffic. 1 sent 0 received. Also see if NAT is being applied. This is usually undesirable and could be one reason the traffic is failing.

Then stop the ping and run the test again from the other direction. Use the same commands. Ingress should be tunnel.x and egress should be the correct Ethernet.

Assuming you have these zones


You may want to add the following rules to see if any packets are being discarded silently.

Src Zone WAN, Dst  Zone WAN, Any Src address, Any Dst address, Any application, allow

Src Zone LAN, Dst  Zone LAN, Any Src address, Any Dst address, Any application, allow

Src Zone VPN, Dst  Zone VPN, Any Src address, Any Dst address, Any application, allow

Src Zone ANY, Dst  Zone ANY, Any Src address, Any Dst address, Any application, deny


The "any, any, deny" rule will break VPN (IPSEC, SSL) and routing protocols without the corresponding rules to allow traffic that sourced from Zone X to terminate on Zone X.

Not applicable

You didn't mention about routing and I had a similar problem, until I noticed that I didn't route the branch office's network in the Virtual router's static routes -section to the appropriate tunnel interface. The problem was that tunnel went up bu no traffic was seen. Once I entered the missing static route of the remote proxy network address, it worked as it supposed to be.


Thanks for your response.  I took a look at what sessions were open on the fw and even when I run a continual ping I dont see anything.  I do see the following though;

23914   ipsec-esp      ACTIVE  TUNN[43696]/Internal/50  ([50022])

vsys1                                               [5217]/Outside  ([45497])

25433   ike                 ACTIVE  FLOW[500]/Outside/17  ([500])

vsys1                                               [500]/Outside  ([500])

Which would appear to be the IKE and IPSec sessions, however when I look at the stat's for those particular sessions there is 0 bytes sent/received on the IPSec session and very few packets sent on the IKE session.  For the IKE session it lists the rule I created allowing traffic, however for the IPSec it doesn't even though the same rule that allows the IKE traffic allows the ipsec-esp as well...

I will look at the access rules to see that they are allowing the required protocols through.

The routing is an interesting one as this is a GRE tunnel.  There is a route to the destination endpoint of the GRE tunnel on the fw (which is a /30 network, one IP is on the remote endpoint and one is on the Cisco router that has the GRE tunnel interface) so my "destination network" is only really a single IP address as far as I can tell?

L1 Bithead


I've been doing some additional troubleshooting on this issue and have found something that I think might be the cause of the problem but it would be useful if I could get some second thoughts!  Basically the remote IKE gateways's IP address is the same as the IP address for the GRE tunnel endpoint making me thing the GRE tunnel terminates on the peer's ASA.  My configuration had a static route for this IP address going over my internet connection and this works as the tunnel is established however no traffic goes over the tunnel.  I then discovered I needed to put a route for the remote peer network to use the tunnel interface.  I'm guessing this is the problem because the PA will have two routes for the same public IP address, one using the internet and one using the VPN tunnel interface?

I have seen that config before, and as I was reading your description I think the best solution would be to use 2 static routes - one over the VPN tunnel interface with a lower metric (say 5) and one over the Internet with a higher metric (say, 20).

The lower metric route will fail when the tunnel is down, and allow the higher metric to establish the tunnel. Once it comes up, the lower metric route will take over.

While this may not be the best method, and having separate subnets would be more of an ideal solution, it may work for you.

Hope this helps,

Greg Wesson

Hi Greg,

Thanks for your response. I have tried that but sadly it did not work.  The PA still seems to use the tunnel route regardless of it's state regardless of what metric I have used;

> test routing fib-lookup virtual-router default ip

runtime route lookup
virtual-router:   default
result:           interface tunnel.2

Makes sense, the tunnel interface is actually up. Have you tried adding a tunnel monitor profile to the interface to ping a device on the other end of the tunnel? If that fails, it should bring down the tunnel interface itself and may allow that to work. I haven't actually done this, as I generally recommend that the address inside the VPN tunnel is a different subnet to the endpoint.


L7 Applicator

I have seen situations where it was defined the destination IP as the IP on the tunnel interface, then the routing fib-lookup was saying correctly that the result was the tunnel, however, the connection ended on the tunnel interface itself (it was not encapsulating and sending traffic over the tunnel).

Make sure that is not an IP configured on the local firewall as the Tunnel Interface's IP.

If you have CLI access, ping it, if the rountrip time is close to nothing, then it's likely you've configured that IP on the Tunnel interface itself.

Also make sure to check out the following Article:

Sample IPSec Tunnel Configuration - Palo Alto Networks Firewall to Cisco ASA

cft14server wrote:

Basically the remote IKE gateways's IP address is the same as the IP address for the GRE tunnel endpoint making me thing the GRE tunnel terminates on the peer's ASA.

I'm guessing this is the problem because the PA will have two routes for the same public IP address, one using the internet and one using the VPN tunnel interface?

I don't believe you can make this work for the reason you outline.  If we route correctly for the tunnel end point then the tunnel traffic will not work and vice versa.  I've seen that checkpoint firewalls have a built in feature to allow the same address be used for both the endpoint and tunnel traffic and can manage this on the firewall.  But I am pretty sure neither the ASA or the PA will be able to do so.

Is there any chance the ASA can separate these into two addresses? 

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center
  • 9 replies
  • 101 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!