Site to Site IPSEC Tunnel between ASA5510 and Palo Alto 820

[DamianRC]

Hello,

I have a an IPSEC tunnel between an ASA5510 and PA820. When sourcing ping from 1.1.1.1 to 10.16.40.199, there are no replies. Encapsulated packets do increment on each side of the tunnel, according to each firewall. It appears as if the ASA doesn't know how to return the traffic through the tunnel; however,  1.1.1.1 is reachable from the ASA but the traffic doesn't appear to traverse the tunnel.

I'm using ASDM. Attached are photos of the crypto map(which should instruct this traffic to use the tunnel).

Any help would be appreciated

[Sheraz.Salim]

This could seem more likely a routing issue. 

could you upload the config of asa firewall.

[DamianRC]

Thanks for jumping in.  I can't post the entire configuration, but below are all of the route statements:

!
route DMZ-2 0.0.0.0 0.0.0.0 10.16.40.2 1
route Palo_VPN 1.1.1.1 255.255.255.255 20.1.1.20 1
route DMZ-2 10.0.30.0 255.255.255.0 10.16.40.2 1
route Dmz 10.10.0.0 255.255.255.0 10.0.40.93 1
route Dmz 10.16.200.0 255.255.255.0 10.0.40.93 1
route Inside 10.16.254.0 255.255.255.0 10.0.0.113 1
route Inside 192.168.42.72 255.255.255.255 10.0.0.213 1
route Inside 192.168.42.97 255.255.255.255 10.0.0.213 1
route Inside 192.168.42.98 255.255.255.255 10.0.0.213 1

HTH

[Sheraz.Salim]

do you have a router behind the asa?

where the ip address 1.1.1.1 coming from at ASA. is there a router between the ASA and ip address 1.1.1.1?

[DamianRC]

Yes. 1.1.1.1 is a loopback address in the Palo Alto.

[bhargavdesai]

I am bit confuse that according to the diagram 1.1.1.1 is a loopback of ASA and here you are saying the it is loopback of Palo Alto. Moreover, your crypto ACL also confusing because it shows both the IPs as source and destination. So I will refer to your attached PDF and put 1.1.1.1 as ASA loopback. 

First please rectify your Crypto ACL as it should only required one entry 

Source 1.1.1.1 to destination 10.16.40.199

Second, If your IP 1.1.1.1 is loopback of ASA you do not required any ROUTE for the same.

Remove route Palo_VPN 1.1.1.1 255.255.255.255 20.1.1.20 1

Now for your problem, I hope your Phase 1 and Phase 2 are up as you are able to see traffic encrypted. Now as you told that when you source ping from 1.1.1.1 to 10.16.40.199 you are not getting response. You will see packets encrypted in ASA and Decrypted in Palo Alto. The thing is that the response from Palo is not coming back. So check if Palo Alto has the proper security rule set to allow the traffic back. 

If 1.1.1.1 is loopback of the Palo Alto then also your Crypto ACL at ASA should only required one entry which reverse to the above one. 

I would also like to point out that please check your Proxy ID settings in Palo Alto. 

I would also like to check that ICMP is inspected in Cisco ASA.

At Palo Alto monitor will show that if packets are reached at that end. 

There are details missing to properly provide you help in this scenario. 

HTH

[DamianRC]

My apologies for the confusion. I updated the drawing.

I'll run through each of your recommendations then reply with the results.

Thank you very much.

[DamianRC]

OK.

The crypto map now only has 10.16.40.199 to 1.1.1.1.

route Palo_VPN 1.1.1.1 255.255.255.255 20.1.1.20 1 is still in place because 1.1.1.1 is a loopback on the PA.

1.1.1.1 is a zone called 'cafe.' There is a policy which currently allows everthing from source zones cafe and vpn to vpn and cafe. I see the Pings hit this policy, and they are allowed.

The palo proxy id has a source of 1.1.1.1 and destination of 10.16.40.199.

ICMP inspection has been enabled on the ASA.

I'm still unable to reach host 10.16.40.199 with pings sourced from the palo alto loopback interface 1.1.1.1.

[bhargavdesai]

As far as i understand now. This is what you have. 

• Network behind ASA is 10.16.40.199/32
• Network behind Palo Alto is 1.1.1.1/32
• Tunnel is up (Phase1 and Phase2)

When ping from Palo alto with Source of 1.1.1.1 and destination of 10.16.40.199 you see packet increase as encrypted in Palo alto and in ASA decrypted. But you are not seeing packet decrypted in Palo alto and encrypted in ASA. So to say no response from 10.16.40.199.

Few things to check. 

Are you able to ping 10.16.40.199 from the ASA?

Provide packet-tracer from ASA. make appropriate changes in the command for zone. 

packet-tracer input INSIDE icmp 10.16.40.199 8 0 1.1.1.1 detailed

HTH

[DamianRC]

Your understanding is correct.

10.16.40.199 is reachable from the ASA.

PT results attached.

Wondering if this is the reason why things don't work?

[bhargavdesai]

Source and destination are revered in your output.

I think 10.16.40.199 is behind ASA. So I would say select the interface which is connected to 10.16.40.199 as a source. Select ICMP as service echo and 0, Source IP as 10.16.40.199 and Destination IP as 1.1.1.1.

Moreover just to remind you Palo Alto does require a specific route pointing towards tunnel for VPN. 

HTH

[DamianRC]

I changed the rule to permit, but now see the attached denial. The rule reported as denying the flow is set to permit, however.

[bhargavdesai]

If you allow and online i would love to troubleshoot this with you over remote session. Let me know if you are ready for it.

HTH

[DamianRC]

Unfortunately this environment doesn't allow remote session management. 

I reversed the order and now see the attached.

[bhargavdesai]

It is confusing for me to understand so sorry for asking again.

I would ask you what is the IP connected to ASA. Is it 1.1.1.1 or 10.16.40.199? 

On what port it is connected? (name)

If your answer are 10.16.40.199 and DMZ-2

It seems like access list is blocking the connection coming in to DMZ-2, Please check the ACL.

I was referring to TeamViewer when I was referring to working with you remotely. Never mind we will solve it together. 

HTH