topic Re: IPSEC site-to-site; passing ICMP only.. no other protocol (TCP/UDP) in General Topics

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

mpgioia — Tue, 02 May 2017 07:03:56 GMT

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... ?

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

Remo — Fri, 05 May 2017 13:58:17 GMT

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

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

mpgioia — Fri, 05 May 2017 14:04:12 GMT

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 ?

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

Remo — Fri, 05 May 2017 14:18:29 GMT

Could you share all the IKE/IPSec parameters?

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

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

mpgioia — Fri, 05 May 2017 14:29:52 GMT

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 ?

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

ChrisRussell — Fri, 05 May 2017 14:43:27 GMT

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.

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

mpgioia — Fri, 05 May 2017 14:48:17 GMT

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 ?

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

Remo — Fri, 05 May 2017 15:25:50 GMT

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.

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

ChrisRussell — Fri, 05 May 2017 15:34:12 GMT

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.

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

mpgioia — Fri, 05 May 2017 15:49:12 GMT

@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.

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

mpgioia — Fri, 05 May 2017 15:56:50 GMT

@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 ?

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

TranceforLife — Mon, 08 May 2017 14:10:31 GMT

Hi,

l do like this article:

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

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.

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

mpgioia — Mon, 08 May 2017 14:38:52 GMT

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.

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

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

mpgioia — Mon, 08 May 2017 14:42:48 GMT

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.

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

mpgioia — Mon, 08 May 2017 14:51:43 GMT

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 ?

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

TranceforLife — Mon, 08 May 2017 15:41:17 GMT

Can you please post the magnified traffic log output from the successful ping requests.

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

mpgioia — Mon, 08 May 2017 15:48:00 GMT

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

TranceforLife — Mon, 08 May 2017 16:02:47 GMT

How to you forward the traffic with a static route or PBF? Traceroute output

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

mpgioia — Mon, 08 May 2017 16:15:28 GMT

Static. default vr. to tunnel interface.

From the 192.168.75.15 host (near end) below.

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

Remo — Mon, 08 May 2017 16:51:41 GMT

So a little recap: you can ping the host on the other side but you are not able to transfer tcp traffic over the tunnel, right? And the paloalto firewall is on your own side where you start the ping/tcp sessions? And in addition you don't see any traffic logs for tcp traffic?

Did you try a flow basic to do a low level check whats happening on your side or if the traffic even arrives at your firewall?
https://live.paloaltonetworks.com/t5/Featured-Articles/Getting-Started-Flow-Basic/ta-p/72556