Unable to restrict L2TP Client access via VPN Access List

03/26/2020 31 People found this article helpful 485,770 Views

Description

Scenario - Unable to restrict L2TP Client access via VPN Access List

Resolution

This is a scenario based article. In this scenario we have configured the SonicWall L2TP server as the primary method of deploying remote access. The network topology is as follows:

X1 (WAN)	192.168.170.51
X0 (LAN)	172.27.24.0/24
X2 (DMZ)	10.10.10.0/24
X3 (WLAN)	192.168.1.0/24

The objective is to have remote L2TP clients connect to the SonicWall L2TP server and then have selective access to selected resources on the LAN and DMZ zones. We want users to have access in the following manner:

Engineering Group	Application Server	172.27.24.69
Marketing Group	Web Server	172.27.24.66
Accounting Group	Database Server	172.27.24.68
Admin Group	All access to LAN Subnets.

We have set the WAN GroupVPN settings in Route-all (Tunnel-all) mode and have configured the SonicWall L2TP server on the VPN | L2TP Server page.

The L2TP clients are able to successfully connect to the L2TP server; are assigned IP addresses from the IP address pool configured under L2TP Server configuration; are pushed default routes (0.0.0.0/0.0.0.0) with higher priority than the default routes in the L2TP clients' host. These default routes will force all outbound traffic from an L2TP client's host over the L2TP/IPsec tunnel.

Our objective has been partially met - clients are able to connect remotely and are able to go online through the SonicWall. They are able to successfully access the resources allotted to them in the LAN and DMZ zones. However, they are also able to access resources not meant to be accessed by them. In other words, clients have complete, unrestricted access to all resources.

This is because unlike WAN GroupVPN GVC and SSL-VPN NetExtender clients, L2TP client access cannot be controlled by VPN Access List. VPN Access List dictates client access in Global VPN Client (GVC) and NetExtender SSL-VPN client connections. But in L2TP VPN connections, VPN Access List has no role to play. Instead, client access is governed by the following:

When WANGroup VPN | Client tab | Allow Connections to is set to This Gateway Only, clients are pushed default routes of 0.0.0.0/0.0.0.0 with a higher priority than the hosts' default route.
When WANGroup VPN | Client tab | Allow Connections to is set to Split-Tunnels and L2TP Server | L2TP Users tab | Local L2TP IP Pool is set with an IP addresses range, clients are pushed a route with destination as the 24 bit subnet of the virtual IP address assigned to the client.

Whether Split-Tunnels or Route-all mode, when Enable L2TP Server is checked, SonicWall auto-adds the following inbound Access Rules. In keeping with this scenario's network configuration, SonicWall creates the following Access Rules:

The above rules allow complete access to the network behind the SonicWall. Being auto-added, these rules are not deletable. Moreover, their Action, Source or Destination fields cannot be edited. The editable fields are Source Port (SonicOS 5.9 only), Service, Users Included, Users Excluded (SonicOS 5.9 only) and Schedule. Therefore, our primary goal must be to render these rules ineffective by setting some of its fields with objects unlikely to be used effectively. We do this in the following manner:

Change Service to Ping 8.
Change Users Excluded to Everyone (only available in 5.9 firmware)
For pre-5.9 firmware, change Users to SonicWall Read-Only Admins.

Note: Shown here is the VPN to LAN auto-added rule. Make the same change to other Access Rules in VPN to other zones.

In addition, we also create deny rules and ensure their priority is above the auto-added rules.

Note: Before creating the deny rules, it is important to first make the changes described above without which SonicWall will not admit creating the following rule (an Allow and a Deny rule with identical parameters is not permitted):

In the Add Rule window, set Action to Deny
Select VPN under From and LAN under To
Set Source Port as Any
Set Service as Any
Set Source as L2TP IP Pool
Set Destination as Any
Set Users Included as All
Set Users Excluded as None
Set Schedule as Always

Note: Shown here is a VPN to LAN deny rule. Perform the same steps to other Access Rules in VPN to other zones.

Shown below is the layout of the rules. Notice how the deny rule is above the allow rule with a higher priority ('higher' here denotes the one with a lower value). Rules can be re-prioritized by clicking on the red/green Arrows icon (see screenshot). A rule's priority value is shown as a number alongside the Arrows icon. Clicking on the Arrows icon, the user would be prompted to enter a number between 1-10. A value of 1 has the highest priority and 0 is for auto-priority.
Note: For Admin Group to have full access, it must be member of other groups (Engg Group, Marketg Group etc)

Note: In the rule for Admin Group, we have selected Destination as LAN Subnets instead of Any. Selecting Any would give an error, "Error: Action: Rule overlap, rule not added". This is because two rules cannot be created with identical parameters with only the user groups different.

Shown below are the Access Rules we created/modified. Notice how the auto-added rule is at the bottom and other rules above it. With these rules in place users will be able to access their designated resource and nothing else.

Not Finding Your Answers?

ASK THE COMMUNITY

Was This Article Helpful?

YES NO

Unable to restrict L2TP Client access via VPN Access List

Description

Resolution

Related Articles

Categories

Not Finding Your Answers?

Was This Article Helpful?

Article Helpful Form

Article Not Helpful Form

Follow Us

Subscribe to newsletter

Stay In Touch