URGENT: MX67 Non-Meraki-VPN limit encryption domains

[Halil]

Hello,

we have got many Non-Meraki-VPN connections. We have got many subnets in our local network and want to share specific subnets to specific Non-Meraki-Peers. If the target gets configured only for the subnet, that we want to share, than the connection breaks up almost every 30 Minutes. Is there a way to specify, which subnets to share with which Peer? I contacted Meraki Support and got the following answer:

In the scenario where you would like to keep VPN participation on because you are using both AutoVPN and Non-Meraki VPN and you do not want the traffic destined for AutoVPN to be propagated across Non-Meraki VPN what you can do are the following: 1) Set the interesting traffic coming from the other side to only the subnets that you are interested in and not include the others in the interesting traffic. The Meraki site, because it has VPN participation enabled on all subnets, on each subnet it would indeed try to establish a Non-Meraki VPN connection with the peer advertised in the Site to Site VPN but because only the interesting traffic (a specific subnet on our Meraki end) is being advertised from the other side, the other subnets would fail to establish a VPN connection and the traffic should be dropped 2) If you believe that the transform-set established during Phase1&Phase2 negotiations included other subnets (on the Meraki side) and you are able to reach other subnets although they are not defined in the interesting traffic scope and traffic is leaking through I would recommend then to configure Site to Site VPN Outbound firewall rules and block the traffic on our side going through the Non-Meraki VPN tunnel and from the other side please set outbound firewall rules to block any incoming traffic from our side

The second time I contacted the support, I got following answer:

1) Define the public IP address & Private subnet on the Meraki side (expected from the other side) 2) Define the public IP address & Private subnet on the other side (expected from the Meraki Side (our public IP address and the VLAN/subnet defined locally on our site that you want the traffic to be sent across) 3) The other subnets/VLANs on our side, although they have VPN participation on them, should not form any VPN connection with the other side because their subnet is not expected from the other side 4) If for any reason you are able to ping other subnets (although you should not be able to) please configure S2S VPN firewall rules. S2S VPN firewall rules are always defined in mind based on the local information sent (which is ours). Basically you are blocking your subnets (on the Meraki Side) to even communicate over VPN with the particular subnet defined in the destination. The rules are locally defined to the outbound traffic. The analogy its like an Extended ACL for Cisco which you defined as close to the source as possible. 5) Another option would be on S2S VPN firewall rules to only allow the ones that you want to go through the VPN and use a Deny any statement afterwards

I trusted this answer and built a VPN-Connection to a Peer but I am having the same problem.

Does anyone have a suggestion?

Thanks in Regards

[BrechtSchamp]

To me the connection breaking every x minutes is likely not related to the IP addressing configured on both sides of the tunnel I'd expect it to be related to the lifetimes and related settings configured in both phases of the IPsec tunnel. Are your phase settings identical on both sides?

Have you found anything interesting in the logs on either side of the tunnel? It may provide hints as to why the connection was broken.

[Halil]

Hello BrechtSchamp,

thank you for your answer.

Our settings are identical on both sides. We checked it several times. We have got other connection with the similar settings but all subnets listed on both sides and dont have any connection issues.

Here are some log entries while the connection broke up:

msg: initiate new phase 1 negotiation: XXX.XXX.XXX.XXX[YYY]<=>XXX.XXX.XXX.XXX[YYY]

msg: notification INVALID-SPI received in informational exchange.

msg: failed to get sainfo.

msg: failed to pre-process ph2 packet (side: 1, status: 1).

The issue with the connection-break-up is that it lasts several minutes to regenerate and my co-workers aren´t able to work until the tunnel is up again.

[BrechtSchamp]

Hmm okay, according to the docs these messages hint towards wrong subnets:

msg: failed to get sainfo.

msg: failed to pre-process ph2 packet (side: 1, status: 1)

Source:

https://documentation.meraki.com/MX/Site-to-site_VPN/Troubleshooting_Non-Meraki_Site-to-site_VPN_Pee...

But I don't see why they would initially come up and function for half an hour. I think maybe those errors may have been there in the first place because the remote end is trying to establish multiple second phases.

That INVALID-SPI seems more like a reason for an existing connection to break. I found a similar problem here:

https://www.reddit.com/r/networking/comments/776rab/ipsec_tunnel_instability/

Check the comments by admiralspark. The NTP thing may be something to give a try.

Does the 30 minutes frequency correspond to one of the lifetimes of your phases? You could try playing with the lifetimes to see if has any influence on the frequency.

Meraki support should also be able to tell you what settings should be on the other end regarding keepalive and DPD as those are not configurable on the Meraki end afaik.

[Halil]

Hello BrechtSchamp,

thank you very much for your answer. The connection doesn´t break up periodically every 30 minutes but at the latest in 30 minutes. I will try to contact Meraki support for DPD. But do you think, that the problem is really, that meraki tries to share all its VPN-Subnets to every VPN-Peer?

[PhilipDAth]

Is one end of the connection behind NAT?

[Halil]

On my side, it is not behind NAT. But I don´t have any info about the other side

[Nash]

May be a long shot, but I have had a couple of constantly dropping tunnels where I knew that:

1. Phase 1 info matched

2. Phase 2 info matched

3. Subnets were shared appropriately, with outbound fw setup in an attempt to control leakage

4. PSK matched

5. Neither side was behind NAT.

But the tunnel kept failing p1 randomly and without warning. Sometimes it'd run fine for a while but with short lifetimes on p1, then other times it would fail for hours at a time.

The solution ended up being asking support to disable NAT-T on those specific tunnels. It was a per-tunnel setting when I had to do this ~4 months ago.

[Halil]

Hello Nash,

but if we disable NAT Traversal we will need to set up Port-Forwarding to our Applience, true?

Because I could disable NAT Traversal for the VPN Tunnels but I don´t because of this comment on the Dashboard:

"Remote peers contact the security appliance using a public IP and port that you specify.

Use this if your security appliance is behind another NAT and "Automatic" traversal does not work."

[Nash]

---

@Halil wrote:

Hello Nash,

but if we disable NAT Traversal we will need to set up Port-Forwarding to our Applience, true?

Because I could disable NAT Traversal for the VPN Tunnels but I don´t because of this comment on the Dashboard:

"Remote peers contact the security appliance using a public IP and port that you specify.

Use this if your security appliance is behind another NAT and "Automatic" traversal does not work."

---

You can disable NAT-T freely when your device is at the edge of your network, wearing the public IP on its outside/WAN interface. If you had e.g. a router between your FW and the public IP, you'd already need to forward traffic on 500/4500 from that router to your fw. Otherwise your router would deny the incoming traffic.

[Halil]

I called the Meraki Support Hotline many times and every Support-Engineer told me, that there is no possibility to limit Subnets shared to selected Peers.Today I will take support form an external company, which had the same issue before and could find a solution. I will report when I have a solution.