How to control incoming traffic on site-site VPN with non-Merai peer

[Dunky]

I have a site-site VPN established with a non-Meraki peer.

I need to be able to only permit specific traffic into the MX site from the remote end.

I cannot see a way to achieve this is it bypasses the L3 rules and the rules applied on the site-site VPN are only outbound.

Example:

Remote subnet 10.1.1.0/24

Local (on MX) device 10.2.2.2/32

I want to permit incoming traffic from 10.1.1.0/24 to 10.2.2.2/32 on port 80 and deny all other traffic.

How do I achieve this?

[ww]

I dont think its possible.

Maybe you can work something out with the use of a group policy(is stateless) assigned to a vlan or that /32 client. But i doubt it.

[AlexP]

For what it's worth, the site-to-site VPN is stateless, so it will block the return traffic if you set up two outbound rules on the MX that only permit what you want to that host, and then deny all else.

E.g. something like permit TCP 10.2.2.2/32:80 10.1.1.0/24:any and deny any 10.2.2.2/32:any any:any should do what your example asks for

[Dunky]

Hi Alex,

Thank you for taking the time to reply.

That is not the case - I have a rule that permits the return traffic outbound, followed by a deny any any from the local subnet to the remote subnet but incoming traffic on any port is still reaching the local subnet.

Here is what I have (10.223.104.32/27 is the remote (non-Meraki peer) subnet and 10.222.109.9 is a host on a local VLAN):

The rules should prevent incoming traffic to port 80 on 10.222.109.9, but they don't - I think its only checking the rules on outbound initiated connections, and not return traffic for already established inbound connections.

So, in the above config, how do I permit the inbound traffic I want whilst denying all other inbound?

[Bruce]

@AlexP, I have to agree with @Dunky in that I thought the Outbound Site-to-Site VPN firewall was a stateful firewall. After reading @Dunky‘s post I thought I’d try it in my lab…

So I have Pi-A on 172.17.10.10/24 on site A, and another Pi, Pi-B on 172.18.10.10/24 on Site B. The two are connected via a hub and spoke Auto VPN, the hub being site H.

With no Site-to-Site VPN firewall rules I can successfully ping from 172.17.10.10 to 172.18.10.10, and also from 172.18.10.10 to 172.17.10.10 (the reverse).

I then put in place a deny rule on the Site-to-Site VPN firewall, Deny ICMPv4 from source 172.17.10.10 to destination 172.18.10.10. 

I then ran the ping test again. The ping from 172.17.10.10 to 172.18.10.10 failed, as expected. However, the ping from 172.18.10.10 to 172.17.10.10 was successful, which makes me believe the Site-to-Site VPN firewall is stateful. As the first ICMP message to 172.17.10.10 was seen in the inbound direction it stored the state and allowed the return (outbound) message from 172.17.10.10 toward 172.18.10.10, even though the firewall rule should deny it if it was stateless. Therefore I believe the Site-to-Site VPN firewall is stateful.

It would be great to get confirmation of this, or if there are any flaws in my testing (other than it just being for ICMP).

@Dunky, if as per above, the Site-to-Site VPN firewall is stateful then there is no solution to your problem as the inbound connection will always establish state, and thus be permitted in the outbound direction. As @ww stated, you may be able to achieve something with a Group Policy applied to the destination client (the ACLs in them are stateless), or alternatively put a third party firewall into the solution that can apply inbound firewall rules to the VPN, which will terminate the non-Meraki VPN peer (and may also provide for other flexibility for the non-Meraki peer too).

[Dunky]

Thanks @Bruce 

Its nice to have confirmation that someone else sees the exact same issue 🙂

This is a bit of a show stopper for us.

If the non-Meraki peer (Azure) had a vMX, could I apply L3 outbound rules there to prevent the traffic arriving at the onsite MX in the first place?

[Bruce · Accepted solution]

@Dunky, yep if you had a vMX in Azure then you could put in a Site-to-site VPN firewall rule and it would work, since the traffic will be Outbound at the vMX (and so hit the firewall). That would be another solution - nice idea.