MX67 concentrator hub behind Palo Alto firewall

[Cole]

Hello everyone, 

I am hoping someone can help me out here because I am coming up empty. 

I have an MX67 acting as my hub in concentrator mode behind a Palo Alto firewall. The hub is giving the unfriendly NAT error and I am trying to figure what NAT policy needs to be in place on my Palo. I have tried several configs with no luck. 

Has anyone had any experience with this that they may be able to share?

Thanks in advance.

[MerakiDave]

Hi @Cole  Check this post which might help along with the troubleshooting guide mentioned there: 

https://community.meraki.com/t5/Security-SD-WAN/NAT-Unfriendly/m-p/48968

Unless you already came across this and still coming up empty, let us know.

Also assuming all of the proper access is opened up on the Palo as per Help > Firewall Rules, including UDP/9350 for VPN Registry communications?  

[Cole]

Yes, I have read through this article still no luck. 

[Jordan1]

Hi Cole,

I have been running a HA pair MX250 in the VPN concentrator mode behind a Palo Alto firewall for a year now and it has been working fine even with the unfriendly NAT error. I think it is because the Meraki sets up the auto VPN with outbound traffic to the cloud. Support sometimes gets hung up on it, but it works. 

One thing to note is if you are using PBF rules on the Palo Alto for ISP fail over, I've found that the Palo Alto will not clear the Meraki IPsec sessions when failing to the backup ISP (or failing back to the primary). In order to get the Meraki VPN to fail over you have to either clear the Palo Alto IPsec sessions, or restart the Meraki to re-establish the IPsec tunnels. 

[François]

Hi Jordan,

I note exactly the same :

"One thing to note is if you are using PBF rules on the Palo Alto for ISP fail over, I've found that the Palo Alto will not clear the Meraki IPsec sessions when failing to the backup ISP (or failing back to the primary). In order to get the Meraki VPN to fail over you have to either clear the Palo Alto IPsec sessions, or restart the Meraki to re-establish the IPsec tunnels."

I have the same problem and I try to find a solution because it mean fail-over is not automatique. I have case open with Palo-Alto :

Here explanation from Palo-Alto :

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

From my point of view this is not acceptable solution in the article.

Did you continu to deal with this today or did you find an other solution?

Regards,

[Jordan1]

Hi Francois,

Unfortunately, I wasn't able to find a fix for the Palo Alto issue of not clearing the "long lived sessions". They gave me the same KB article. I spent hours on the phone with Palo Alto and Meraki support (even got both companies on a conference call once) but they couldn't fix it. Palo Alto said it is working as it should be for IPsec and SIP sessions, and Meraki said the Palo Alto should be clearing the sessions since it is handling the ISP fail over. 

I had hung Palo Alto sessions affecting the Meraki IPsec VPN tunnels and a SIP trunk for my SBC. Both were behind the Palo Alto. 

I ended up re-configuring my MX250's in NAT mode (instead of VPN concentrator) and bypassing the Palo Alto with a dedicated WAN interface on the MX to each of my ISP's. 

[François]

Dear Jordan,

Thanks again. In my case, I use BGP and it's concentrator only....so.

Like you, I saw this behavior with other VPN tunnel, not only Meraki. I consider this problem is on Palo Alto side and I will push on this way.

I created this post about this problem :

https://community.meraki.com/t5/Full-Stack-Network-Wide/Meraki-MX250-behind-Palo-Alto/m-p/97876#M161...

I will try to update my situation on that.

[Jordan1]

Thanks for the update Francois. I will follow the new thread in your new post.

[CN]

I would recommend changing NAT traversal from auto to manual. Put in the public IP that it will use to communicate. Then choose a port that it should use. I generally like to use ports that are easily recognizable like 31313 or 42424, you get the idea. Then on the Palo Alto create a port forward for the UDP port you've chosen to always be sent to the MX. 

When the manual NAT traversal is set, dashboard will tell all of the spokes to communicate with the hub on the IP and port. If the Palo Alto is changing the ports (and causing the unfriendly NAT) it will break the UDP hole punch and will prevent the VPN tunnel from forming. The port forward will make sure that the spokes are always able to reach the hub. 

If the tunnels still don't form then I recommend taking a packet capture of the internet interface on the hub and the spoke. Is there back and forth traffic between the two? Or is there only traffic going one way? If it's one way there is something blocking the traffic. If you have very strict firewall rules then I recommend that the rules be built around the UDP port instead of the IP of the spokes. 

An old post of mine has some KB links for more details on troubleshooting AutoVPN.