IPSEC site-to-site; passing ICMP only.. no other protocol (TCP/UDP)

[mpgioia]

I have an IPSEC-to-SITE.

IKE Phase 1 and Phase 2 are good/live.

Tunnel interface in right zone.  Routes fines.

Policy defined (app: any, service: any).

I can see the policy being hit when I generate icmp/pings.  And can get to the proxy id's/subnets on other side.

I can't get anything other than ICMP through though.. No other TCP/UDP layer traffic.. no logs generated from the same policy (which should be evoked because of the source/destination condition match's that work for ICMP) that should get hit... very strange... ?

[Remo]

Hi,

Are you using AES256GCM in phase 2 or could you share your settings? IKEv1 or v2?

You could also check if you have encryption/decryption errors. This can be done on the CLI with the following command:
show vpn flow tunnel-id <number>

This tunnel-id should be shown in the webui or with the command:
show vpn ipsec-sa tunnel <IPSEC-TUNNEL-NAME(:PROXY-ID-NAME)>

The question about AES256GCM I was asking becaus with that I was expeciencing exactly the same issue, just hadn't had enough time to dig deeper. I then simply changed to AES256CBC and everything was working.

Regards,

Remo

[mpgioia]

Great thing to check ! Thankyou !

But alas, no.. no errors, and i'm using CBC not GCM for AES256 Phase 2 cipher set.

IKEv1 by the way.

Any other thoughts ?

[Remo]

Could you share all the IKE/IPSec parameters?

What gateway-vendor/gateway-typ is on the other side?

[mpgioia]

PAN to Cisco ASA

Phase 1

IKEv1 only

Exchange mode = auto

IKE crypto = aes256cbc, SHA1, DH group2

Phase 2

Type = Autokey

Proxy IDs are set.

Near: 192.168.74.0/24, Far: 172.29.17.128/25

Near: 192.168.75.0/24, Far: 172.29.17.128/25

Near: 192.168.76.0/24, Far: 172.29.17.128/25

IPSEC crypto = ESP, aes256cbc, SHA, DH group2

Tied to tunnel.1, trust zone, route set to reach 172.29.17.128/25

Policy set to allow

NAT rule in place to exempt NAT for this specific source and destination (otherwise it hits the bottom-most source NAT dynamic ip and port for internet access for the near side networks)

All the IKE/IPSEC stuff and policy is fine because ping gets there.

I can disable the tunnel and ping stops.  And monitor shows my policy I designed for this being hit with the icmp.  But can't get any L4 traffic over there.  Show session shows nothing also..

Need anything else ?

[ChrisRussell]

I'd try to source the ping as something other than an interface, and then check static routes to the subnets on the other side. It sounds like the traffic doesn't know how to get across perhaps. I'd recheck the ASA's interesting traffic/subnets from the Palo are set right. 

[mpgioia]

I agree....Traffic logging only appears when session established.

So any furfy of not seeing at least my TCP SYN's/my side of the traffic getting over I shouldn't get hung up on.. because the session is not established.. that's why I'm not seeing any traffic. ( I originally.. .erroneously .. was getting hung up on why I couldn't see at my TCP leg making it's way over in the traffic logs.. but no session.. that's why )

I've gone through my config on near side to death.. I think it is the other side.

But then... ICMP gets there and back.. so if it was fundamental routing.. even ICMP wouldn't get there ?

[Remo]

You could also enable "Session Start" log so you will also see logs for not established sessions.

But as you describe this setup, and when you don't see any encryption/decryption errors I would also definately check the other side (make someone check the other side). Maybe the other side has access-lists in place which only allow icmp?

What you could still check is the system log, if the ASA tries to setup a new phase 2 tunnel for tcp traffic while sending only icmp to the existing one. Not really likely but a while ago I had a cisco-router admin who somhow managed to configure his router to setup different phase 2 tunnels for every source/destination/port constellation.

With the routing I think you're absolutely right. If there is a routing problem also icmp would fail.

[ChrisRussell]

Yeah, thats why i recommended sourcing pings from something other than whatever interface its pinging from now.

ping source <pick an IP on palo side subnet> host <pick an IP on ASA side subnet>

If pings throughtout the local subnet are reachable on the remote subnet then it has to be some sort of policy/services issue I'd think. I just always start at routing and work from there. 

[mpgioia]

---

@AXI_IIEN_Remo wrote:

You could also enable "Session Start" log so you will also see logs for not established sessions.

But as you describe this setup, and when you don't see any encryption/decryption errors I would also definately check the other side (make someone check the other side). Maybe the other side has access-lists in place which only allow icmp?

What you could still check is the system log, if the ASA tries to setup a new phase 2 tunnel for tcp traffic while sending only icmp to the existing one. Not really likely but a while ago I had a cisco-router admin who somhow managed to configure his router to setup different phase 2 tunnels for every source/destination/port constellation.

With the routing I think you're absolutely right. If there is a routing problem also icmp would fail.

---

Yeh am logging at Session Start and End.

Don't see nothing..

I'll check the other side.. Thanks guys.

[mpgioia]

---

@chris.russell wrote:

Yeah, thats why i recommended sourcing pings from something other than whatever interface its pinging from now.

Educate me here. ... what do you mean by this ? 🙂

Right now, I'm on a near end proxy-id/policy source address.. (like an actual machine in this subnet.. remotely) pinging to proxy-id/policy destination address (this I'm not on remotely.. but have been told in confidence by far end representative it's there and live.. obviously..)

See.. now i'm stressing again that it's my side again if 'Session Start' is ticked in logging on my policy and I don't see my traffic-half/side on the way to the far end.. when I technicaly should right ?

[TranceforLife]

Hi,

l do like this article:

https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Troubleshoot-IPSec-VPN-connectivity-...

Especially this part:

 

exp:

If you don't see the session logs in the monitoring tab to me it is a local issue (assumimng that the log is enabled for the policy, even for the default deny). If the Palo receives the traffic and correctly encapsulation and putting it into the tunnel interface you should see the traffic logs and something like "incomplete" in application tab and "aged-out" in the session end reason (assuming the traffic is not coming back. Very strange that the ping is working)) did you try to run a PCAP on the firewall ? Create a filter for the other end destination ip and get PCAP. Check if any traffic is dropped by the firewall. 

[mpgioia]

This is ridiculous.. and appreciate the pipe in @TranceforLife.

Yes, incrementing enc/dec packets.

And check this out.. when I run a PCAP,  and filter right down to a source of a /32 and a destination of a /32 (near and far end), all 4 stages of what it can pcap.. I literally get no files created when I try to, like, http/https browse.  Nothing.

I start my ping off to the dest.. bang files created.. 😕

If it helps, at least on the far end/Cisco side I get a repeating,

----------------------------------------------------------------------------------------------------------------------------------------------------------

IPSEC: The decapsulated inner packet doesn't match the negotiated policy in the SA.  
The packet specifies its destination as pkt_daddr its source as pkt_saddr, and its protocol as pkt_prot.
The SA specifies its local proxy as id_daddr/id_dmask/id_dprot/id_dport and its remote proxy as id_saddr/id_smask/id_sprot/id_sport.

----------------------------------------------------------------------------------------------------------------------------------------------------------

[mpgioia]

Infact I just posted template Syslog output (or should I say.. all I received was the template syslog output from the rep on the other side..) i'll get the actual output/log line to see what the translated inner packet is.

[mpgioia]

omg..

I think the 'decapsulated inner packet' is coming through on Cisco ASA as IPv6 ?!

Look at the log line at the end.. truncated off..  But the first parameter appears to be in IPv6 format ?