Skip to main content

 

Cisco Meraki Documentation

Restricting Client VPN access using Layer 3 firewall rules

Overview

Client VPN users may access all subnets within the network by default. In order to control or restrict access for Client VPN users, firewall rules should be implemented.

Layer 3 firewall rules are a powerful tool for permitting and denying Client VPN traffic. Although Client VPN users are considered part of the LAN, network administrators may see a need for limiting overall access. Firewall rules can be used to limit access for VPN users to specific addresses/ports or ranges of addresses. Such as allowing access to most information, but denying access to sensitive resources to VPN users.

The objective is to creat a Client VPN subnet and configure rules that will permit and deny access based a several parameters.

Configuring Client VPN subnet

The Client VPN subnet is configured via Security & SD-WAN > Configure  > Client VPN. Take note of this network address as it will be used to implement Firewall rules for controlling traffic related to that subnet. In the following scenario, our Client VPN subnet will be (172.16.1.0/24)

Screenshot from dashboard, security and SD-WAN -> Client VPN page, where the client VPN is enabled with a client VPN subnet (172.16.1.0/24) configured in the subnet field.

 

 

Configuring Addressing and VLANs subnet(s)

Subnets local to the MX are configured via Security & SD-WAN > Configure > Addressing & VLANs. Below is an example depicting an MX that has VLANs enabled. Two subnets are present: (192.168.10.0/24) and (192.168.20.0/24). Both of these subnets will be accessible by users who establish a successful Client VPN session.

Screenshot of Meraki Dashboard settings for Configuring Addressing and VLAN Subnets that will be accessible for the client VPN subnet to communicate with.

Additionally, subnets made known to the MX via Static LAN routes will also be available to the Client VPN subnet. These subnets are also configured via Security & SD-WAN > Configure > Addressing & VLANs

 

As shown below, the non-local subnet is 10.0.1.0/24, and will be pointed to a router with the address of 192.168.10.2.

Screenshot of Meraki Dashboard for configuring static routing on Addressing and VLAN page.

 

Configuring Firewall Rules

Navigating to Security & SD-WAN > Configure > Firewall, note that the default settings permit all outbound traffic. This allows all subnets to communicate, including the client VPN network. Outbound rules also apply to Inter-VLAN Routing.

 

Screenshot of Meraki Dashboard for configuring L3 firewall rules with the default rules applied.

 

Outbound rules should be implemented to control which subnets Client VPN users may access. These rules are processed numerically, like an ACL, starting with Rule #1. Once a rule is matched, no further rules will be processed. Thus, the Rule number is essential.

 

Example 1

In the following example, the entire Client VPN subnet (172.16.1.0/24) will only have access to Subnet 1 and Subnet 2. The Client VPN subnet will not have access to Non-local Subnet 1.

Only a single rule denying all traffic from the Client VPN subnet to the non-local subnet is needed since there is an implicit "Allow" rule at the end that permits all other outbound traffic.

Screenshot of Meraki Dashboard for configuring L3 firewall rules with a deny rule in place for the client VPN source subnet to the destination, 10.0.1.0/24.

Example 2

In this example, VPN clients are permitted to access HTTPS (secure web) and DNS servers on a LAN subnet, but all other access is denied.

Screenshot of Meraki Dashboard for configuring L3 firewall rules to allow traffic to 192.168.10.25/32 and 192.168.10.50/32 while blocking all other access.

There are many combinations of firewall rules available for configuration. As a general rule of thumb, configure rules that apply to a specific port/destination first, before configuring a rule that applies to the subnet as a whole. Please be sure to test and verify all firewall rules along the way to ensure proper access.

  • Was this article helpful?