site-to-site VPN between Meraki and Palo Alto

Phi1001
Here to help

site-to-site VPN between Meraki and Palo Alto

VPN between our palo alto and client's meraki is up. but only one subnet of the client out of 4 is reachable. Subnets are added on both sides of the VPN. What could be the issue?

Really need your help here

24 Replies 24
alemabrahao
Kind of a big deal
Kind of a big deal

Knowing Palo Alto is probably missing some firewall rule.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Phi1001
Here to help

I don't think so

CoreyDavoll1
Getting noticed

Could also be a missing route in either of the route tables 

Phi1001
Here to help

Hello Corey,

 

We have policy-based VPNs and not route-based. We have one default route for all the VPNs.

Blue_Bird
Getting noticed

Phi1001
Here to help

FYI, Meraki has dual WAN. And I have configured Palo Alto to accept dynamic Peers with remote Ike ID being their FQDN.

If it makes any difference

alemabrahao
Kind of a big deal
Kind of a big deal

 

You can simply do a packet capture on Palo Alto or check if you are experiencing any drops on Monitor.

 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClTJCA0

 

https://kb.wisc.edu/security/page.php?id=90826

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
cmr
Kind of a big deal
Kind of a big deal

Are you using IKEv2 and is only one SA establishing?  If so try IKEv1, but as you have dynamic peers you may already be using IKEv1...

If my answer solves your problem please click Accept as Solution so others can benefit from it.
Phi1001
Here to help

Thank you for your response, Sir. I tried using ikev1 but apparently, Palo Alto doesn't support peers using FQDN in Ikev1 .

alemabrahao
Kind of a big deal
Kind of a big deal

If you'd like, you can share the Ike gateway and VPN tunnel settings. I'm familiar with Palo Alto and might be able to help.

But just in case, is NAT traversal enabled on the Ike gateway? If not, try enabling it.

 

alemabrahao_0-1752254541296.png

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Phi1001
Here to help

Sure, I will share the ike configuration in a bit ..

I don't have nat traversal on since the client said that they didn't have any nating device between their isp modem and meraki. However he has nat traversal as auto on his side. 

I have made my side,palo alto, passive since I read in an article that said if we have to configure our side as passive if the peer is using dynamic wan ip address.

Phi1001
Here to help

Phi1001_0-1752588047617.pngPhi1001_1-1752588063598.png

 

GIdenJoe
Kind of a big deal
Kind of a big deal

It does happen in IKEv2 that two vendors do not agree how to settle the child SA's.
Going back to IKEv1 is the option but you would have to let go of the IKE ID via FQDN and go back to interface IP instead.

Phi1001
Here to help

Ok.. 

So, they have multiple tunnels. I fixed one of them.

They have 3 subnets - 10.2.1.0/24, 10.2.19.0/24, 10.2.71.0/24.

But, I used 10.2.0.0/16 as the remote subnet which encompasses all of them.. Apparently, that fixed the issue and they can reach our server now from all the VLANs.

I am not sure if it is a permanent fix.

And, I should use their FQDN since they have dual WAN connections and they can only carry out the VPN failover if we configure their FQDN

GIdenJoe
Kind of a big deal
Kind of a big deal

Aggregating the remote subnets is the best solution you have as long as you don't have any overlaps locally.

So in this case you were lucky that you could aggregate them in a nice block.

However there is a limitation with the Meraki way of configuring VPN tunnels in that you can't do the same for your own subnets.  So you can't just choose any local aggregate but you have to select the local subnets to send over the VPN.

 

So yes your solution should werk perfectly.

Phi1001
Here to help

For one of their VPNs, I have to configure 192.168.67.0/24, 10.67.41.0/24. I am not sure how to club them ..

 

cmr
Kind of a big deal
Kind of a big deal

Use a club with nails sticking out of it and pour aftershave on the nails before you use it.  😈🤔

If my answer solves your problem please click Accept as Solution so others can benefit from it.
Phi1001
Here to help

Damn..😂😂😂...sorry for my wrong choice of words. I'll keep your advice in mind though. It will helpful in a different ball game

Phi1001
Here to help

please help

GIdenJoe
Kind of a big deal
Kind of a big deal

You can't aggregate those subnets.
So in that case the aggration of those subnets is not on the table and you are back to the first only working solution.  Use IKEv1 and just use IP as IKE ID's.

cmr
Kind of a big deal
Kind of a big deal

Unfortunately @GIdenJoe is right.  The only other option is if either end has more than one internet connection, you could set up the IPSEC for one subnet to use internet connection A and the other to use internet connection B.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
Phi1001
Here to help

Okay. A part of the problem is fixed.

I can reach both the subnets when I switched over to ikev1.

Now, I have to configure VPN failover on Palo Alto.

I have created two tunnels to each of their WANs.

Does Meraki need to configure two separate tunnels from each of their WAN connections?

Phi1001
Here to help

Sir, I switched to ikev1 and I could communicate with all of their VLANs.

But, when I changed the peer id from its primary IP address to their FQDN. It isn't working anymore.

Please help

GIdenJoe
Kind of a big deal
Kind of a big deal

You are supposed to use the WAN IP peer ID, not the FQDN.
You told us before that FQDN support was not there on the Palo on IKEv1 so just stick to the WAN IP instead.

Get notified when there are additional replies to this discussion.