The Security Gateway examines packets and applies rules in a sequential manner. When a Security Gateway receives a packet from a connection, it examines the packet against the first rule in the Rule Base. If there is no match, it then goes on to the second rule and continues until it matches a rule. If there is no match to any of the explicit or implied rules, Security Gateway drops the packet.
In rules with Access Roles, if the source identity is unknown, and traffic is HTTP, configure the Action field to redirect traffic to the Captive Portal. This rule will redirect the user to the Captive Portal.
In rules with Access Roles, if the source identity is known, the Action in the rule (Allow, Drop, or Reject) is enforced immediately, and the user is not redirected to the Captive Portal. After the system gets the credentials from the Captive Portal, it can examine the rule for the next connection.
In rules with Access Role objects, criteria matching works like this:
If all the conditions apply, the traffic is redirected to the Captive Portal to get credentials and see if there is a match.
If not all conditions apply, there is no match, and the next rule is examined.
Note - You can only redirect HTTP traffic to the Captive Portal.
To redirect HTTP traffic to the Captive Portal:
The Action Settings window opens.
Accept (display Captive Portal)
Ask (display Captive Portal)
Inform (display Captive Portal)
Important - When you set the option to redirect HTTP traffic from unidentified IP addresses to the Captive Portal, make sure to put the rule in the correct position in the Rule Base, to avoid unwanted behavior. |
This is an example of a Firewall Rule Base that describes how matching operates:
No. |
Source |
Destination |
Service |
Action |
---|---|---|---|---|
1 |
Finance Dept |
Finance Web Server |
|
|
2 |
Admin IP Address |
|
|
|
3 |
|
|
|
|
Example 1 - If an unidentified Finance user tries to access the Finance Web Server over HTTP, a redirect to the Captive Portal occurs. After the user enters credentials, the Identity Awareness Gateway allows access to the Finance Web Server. Access is allowed based on rule number 1, which identifies the user through the Captive Portal as belonging to the Finance Access Role.
Example 2 - If an unidentified administrator tries to access the Finance Web Server over HTTP, a redirect to the Captive Portal occurs despite rule number 2. After the administrator is identified, rule number 2 matches. To let the administrator access the Finance Web Server without redirection to the Captive Portal, switch the order of rules 1 and 2 or add a network restriction to the Access Role.
When you negate a Source or Destination in a rule, it means that a given rule applies to all Sources/Destinations of the connection except for the specified Source/Destination object. When the object is an Access Role, this includes all unidentified entities as well.
When you negate an Access Role, it means that the rule is applied to all Access Roles, except for the specified Access Role and unidentified entities. For example, let us say that the below rule is positioned above the Any, Any, Any, Drop rule:
Source |
Destination |
VPN |
Services & Applications |
Action |
---|---|---|---|---|
Temp_Employees [Negated] |
Intranet_Web_Server |
|
|
|
The rule means that everyone (including unidentified users) can access the Intranet Web Server, except for temporary employees. If a temporary employee is not identified when this employee accesses the system, this employee will have access to the Intranet Web Server. Right-click the cell with the Access Role and select Negate Cell. The word [Negated] is added to the cell.
To prevent access to unidentified users, add another rule that ensures that only identified employees are allowed access:
Source |
Destination |
VPN |
Services & Applications |
Action |
---|---|---|---|---|
Temp_Employees |
Intranet_Web_Server |
|
|
|
Any_Identified_Employee |
Intranet_Web_Server |
|
|
|