SonicWALL SMA Planning Manual page 21

Access control rules are displayed as an ordered list in AMC. When the appliance evaluates a connection
request, it begins at the top of the list and works its way down until it finds a match. When it finds a match, the
action required by the rule—either Permit or Deny—is applied and no further rules are evaluated.
Access to a resource can be based on several criteria. Most rules control access based on who the user is—that
is, the user's name or group membership—and the destination resource. (If you don't restrict access to a
particular user or destination resource, the word Any appears in the access control list.)
In addition, you can control access based on several other criteria such as:
• The EPC zone from which the connection request originates. Suppose you want to require users
accessing a sensitive financial application to run a browser cache cleaner after each session. If so, you
could configure a rule that allows access only to systems in a trusted zone that are running a particular
program.
In Access Control rules, access to Remote office desktops is restricted to users in the Remote group who
have device profiles that place them in the Trusted laptop zone.
• The address from which the connection request originates. You might want to control access to a
resource based on the names of any source networks you want evaluated in the rule.
• The access method used to reach the resource. You might want to enable broad access to resources
within an internal domain from the network tunnel or proxy agents, but prevent browser‐based access to
Web servers within the domain.
• The day or time of the request. For example, you might give business partners access to a particular
application on weekdays from only 9:00 A.M. to 5:00 P.M.
A connection request can be summarized as follows:
1 A user is authenticated and initiates a connection.
2 The appliance analyzes the connection request to identify its attributes (including user and group
information, the destination being requested, the source network from which the request originates, and
the day or time of the request).
3 The appliance reads the first rule in the access control list and compares it to the request criteria:
• If a match is found, the action (Permit or Deny) specified in the rule is applied and no further rules
are evaluated.
• If no match is found, the appliance evaluates the next rule in the list to see if it matches the
request.
4 If the appliance processes all of the rules without finding a match, an implicit Deny rule is applied.
Access Control for Bi‐Directional Connections
VPN connections typically involve what are called forward connections, which are initiated by a user to a
network resource. However, if you deploy network tunnel clients (Connect Tunnel or OnDemand Tunnel) to your
users, bi‐directional connections are enabled. Examples of bi‐directional connections include an FTP server that
downloads files to or uploads files from a VPN user, and remote Help Desk applications.
Within the Secure Mobile Access VPN, bi‐directional connections include the following:
• Forward connections from a VPN user to a network resource.
• Reverse connections from a network resource to a VPN user. An example of a reverse connection is an
SMS server that pushes a software update to a user's machine.
• Cross‐connections refer specifically to VoIP (Voice over IP) applications that enable one VPN user to
telephone another. This kind of connection requires a pair of access control rules: one for the forward
connection and one for the reverse connection.
SonicWall SMA Connect Tunnel 12.0 Deployment Planning Guide
21
Planning Your VPN