Appendix

Infranet Enforcer Policies Overview

After you set up user roles, authentication servers, realms and sign-in policies, you deploy the Infranet Enforcer in front of servers and resources that you want to protect. You control access through a number of different security policies that you configure on Pulse Policy Secure.

All policy options are supported on the ScreenOS Enforcer.

Resource access policy-Specifies which users are allowed or denied access to a set of protected resources. You specify which users you want to allow or deny by choosing roles for each resource access policy.

Source IP policy-This is an infranet auth policy the on ScreenOS Enforcer or a security policy on the Junos Enforcer that contains a source and destination that permits the Infranet Enforcer to route clear text traffic between source and destination zones. You can set up a source IP policy on Pulse Policy Secure and push the policy to the Infranet Enforcer, or you can set up the policy using ScreenOS Web UI or the command line.

Auth table mapping policy-Specifies which Infranet Enforcer device an endpoint must use to access resources when the endpoint is using source IP enforcement. If you are using either a ScreenOS Enforcer with Release 6.1 or later or the Junos Enforcer, you do not need to configure auth table mapping policies. Instead, you can use dynamic auth table provisioning.

You can use a username with spaces, a username with quotation marks, a username with UTF-8 characters, or a username with a backslash (\). Each of these conventions is accepted by the firewall with a valid corresponding auth table entry.

Figure demonstrates how policies on the Infranet Enforcer and Pulse Policy Secure interact when a user has an auth table entry on the Infranet Enforcer.

The Infranet Enforcer detects a flow to a specific resource and compares the source IP of the packet with IP addresses in the auth tables. The IP address is associated with a set of roles in the auth table. The destination IP of the packet is matched with the destination IP of a resource access policy to which a set of roles has been assigned. The Infranet Enforcer parses the roles in the resource access policy to determine whether or not the role can access the resource.

Understanding Infranet Enforcer Source IP Security Policies

This topic provides an overview of Infranet Enforcer source IP security policies. It includes the following information:

•Source IP Security Policy Overview

•ScreenOS Infranet Enforcer Configuration Summary

•Junos Infranet Enforcer Configuration Summary

Source IP Security Policy Overview

Source IP enforcement permits users to access resources that are protected by the Infranet Enforcer. IPsec provides an encrypted tunnel for bidirectional traffic, while source IP enforcement allows unencrypted (clear text) traffic between endpoints and the Infranet Enforcer. You can use source IP enforcement alone on the Infranet Enforcer to protect resources alone, or with IPsec on the ScreenOS Enforcer.

To use source IP enforcement, you configure Pulse Policy Secure policies. On a ScreenOS Enforcer, a Pulse Policy Secure policy is an infranet auth policy (a policy that includes an infranet-auth statement). On a Junos Enforcer, a Pulse Policy Secure policy is a Pulse Policy Secure -policy security policy (a security policy that includes an application-services Pulse Policy Secure-policy statement, and may or may not also include a match source-identity statement for user-role firewall functionality).

Pulse Policy Secure policies control which zones use Infranet Enforcer resource access policies to allow or deny traffic. By default, traffic is denied through the Infranet Enforcer. With Pulse Policy Secure policies, you control the traffic that is permitted to pass.

When you first set up the Infranet Enforcer and Policy Secure, you bind zones to interfaces. Pulse Policy Secure policies control the traffic flow between zones. For example, you can configure a Pulse Policy Secure policy on the ScreenOS Enforcer to enforce traffic from the Untrust zone to the Trust zone. Then, you configure resource access policies and specify resources that are within the Trust zone. The roles that you assign to the resource access policy are permitted to access the specified resources.

Source IP enforcement does not work if there is a NAT device between the endpoint and Pulse Policy Secure.

In a case where the endpoint is behind a NAT device and Pulse Policy Secure and the Infranet Enforcer are both on the other side of the NAT device, only one configuration is supported. Source IP enforcement works only with agentless access, and only if it is "one-to-one" NAT, since Pulse Policy Secure and the Infranet Enforcer both see the external (translated) address, and there will be only one user session per IP address.

Source IP enforcement with agentless access might appear to work, but does not operate properly, if an endpoint is behind a NAT device performing is "many-to-one" NAT. The first user that authenticates from behind the NAT external IP address will get access, but only as long as they are the only authenticated user. If a second user authenticates from behind the same external (translated) IP address, the previous user's session is terminated. The web browser shows that their session was terminated, the same as if an Pulse Policy Secure administrator deleted their session from the active user table.

If the endpoint is behind a NAT device, Source IP enforcement with Pulse Secure client does not work at all, regardless of the type of NAT. The agent reports the internal IP address of the endpoint, but the IC will see the external IP of the endpoint. The user can authenticate, and the active user table displays X.X.X.X-Y.Y.Y.Y, where X.X.X.X is the IP address reported by the agent and Y.Y.Y.Y is the IP address detected by the IC. However, no auth table entry will be provisioned to the firewall, since Pulse Policy Secure detects that the endpoint is behind a NAT.

To provide access for Pulse Secure client behind a NAT device, you must use the IPsec policy feature. The IPsec enforcement section provides instructions on how to accommodate users in this use case.

ScreenOS Infranet Enforcer Configuration Summary

You can configure Source IP security policies in either of the following ways:

•You can configure basic Source IP policies (source and destination zone) on Pulse Policy Secure and then push the policies to the ScreenOS Enforcer to add additional policy details. (Recommended)

•You can configure the policies directly on the ScreenOS Enforcer (using the ScreenOS Web UI or CLI).

To use ScreenOS global policies as infranet auth policies, you must configure them directly on the ScreenOS Enforcer. ScreenOS global policies do not include source and destination zones, and policies pushed from Pulse Policy Secure must include source and destination zones, so the infranet auth policy pushed by Pulse Policy Secure is not useful when configuring ScreenOS global policies.

On ScreenOS, you create a policy using address book entries for the destination and source addresses, as well as policy wildcards, such as Any.

The following example sets an infranet auth policy and adds it to the top of the list of policies controlling traffic from the Untrust zone to the Trust zone. The policy applies to all traffic of any type from any host to another host. The policy allows traffic according to the Infranet Enforcer resource access policies that you configure on Pulse Policy Secure.

set policy top from untrust to trust any permit infranet-auth

The following example sets two address book entries and a policy for anyone in the 10.64.0.0/16 range to reach the 10.65.0.0/16 range, subject to resource access policies.

set address Trust "10.64 Range" 10.64.0.0 255.255.0.0

set address Untrust "10.65 Range" 10.65.0.0 255.255.0.0

set policy from trust to untrust "10.64 Range" "10.65 Range" any permit infranet-auth

Junos Infranet Enforcer Configuration Summary

On the Junos Enforcer, security policies enforce rules for the transit traffic. From the perspective of security policies, traffic enters one security zone and exits another. This combination of a from-zone and a to-zone is called a context on the Junos Enforcer.

A security zone is a logical group of interfaces with identical security requirements. Each security zone contains an address book. Before you can set up policies between two zones, you must define the addresses for each of the zone's address books. A zone's address book must contain entries for the addressable networks and end hosts belonging to the zone.

Each security policy that you create must contain at a minimum match criteria and an action. You can specify additional policy options as required.

You can create security policies on the Junos Enforcer from the Junos Web interface, or from the CLI.

The following example sets a Pulse Policy Secure-policy security policy controlling traffic from the Untrust zone to the Trust zone. The policy applies to all traffic of any type from any host to another host. The policy allows traffic according to the Infranet Enforcer resource access policies that you configure on Pulse Policy Secure.

set security policies from-zone Untrust to-zone Trust policy ENFORCE_ALL match source-address any

set security policies from-zone Untrust to-zone Trust policy ENFORCE_ALL match destination-address any

set security policies from-zone Untrust to-zone Trust policy ENFORCE_ALL match application any

set security policies from-zone Untrust to-zone Trust policy ENFORCE_ALL then permit application-services uac-policy

The following example sets two address book entries and a policy for anyone in the 10.64.0.0/16 range to reach the 10.65.0.0/16 range, subject to resource access policies.

set security zones security-zone Trust address-book address 10.64_Range 10.64.0.0/16

set security zones security-zone Untrust address-book address 10.65_Range 10.65.0.0/16

set security policies from-zone Trust to-zone Untrust policy ENFORCE_ALL match source-address 10.64_Range

set security policies from-zone Trust to-zone Untrust policy ENFORCE_ALL match destination-address 10.65_Range

set security policies from-zone Trust to-zone Untrust policy ENFORCE_ALL match application any

set security policies from-zone Trust to-zone Untrust policy ENFORCE_ALL then permit application-services uac-policy

Understanding Infranet Enforcer Auth Tables

The Infranet Enforcer holds auth tables for valid sessions on Pulse Policy Secure. Auth tables consist of a unique identification number, the source IP address of the endpoint that initiated the session, the username, and a list of roles that the user has been assigned.

When a user with a username containing spaces or quotes authenticates with Pulse Policy Secure, the device removes spaces and quotes from the username in the authentication table entry that is sent to Infranet Enforcers.

You can allow the Infranet Enforcer to automatically generate auth tables whenever users are authenticated, or you can configure dynamic auth table allocation. With dynamic auth table allocation, auth tables are provisioned only as a response to a valid request from an authenticated user for a resource behind the Infranet Enforcer.

Dynamic auth table allocation is available on all Junos Enforcers, and on ScreenOS Enforcers with Release 6.1 or later.

Dynamic auth table allocation is required to use IF-MAP Federation.

Understanding Dynamic Auth Table Allocation

You can use the dynamic auth table allocation feature to push auth table entries to the Infranet Enforcer only when a user attempts to access a protected resource. This is more efficient than the Auth Table Mapping Policies option, which requires administrators to provision auth table entries for authenticated users whether they are accessing resources or not. Dynamic auth table allocation reduces auth table entries to only those that are needed, enabling you to deploy smaller firewalls with a larger user population.

When dynamic auth table allocation is used and a user attempts to access a protected resource, the Infranet Enforcer does not yet have an auth table entry for the user, so it sends a drop notification to Pulse Policy Secure to prompt it to send an auth table entry. Unlike captive portal redirect, which only occurs when the user sends HTTP traffic, drop notifications are triggered by any type of traffic for which the destination is a protected resource.

After the user disconnects, the Infranet Enforcer automatically expires the auth table entry.

On the Junos Enforcer, whenever traffic matches a security policy that includes an application-services uac-policy statement, then the firewall sends a drop notification to Pulse Policy Secure if there is no auth table entry associated with that traffic. This applies in the captive portal use case, and for all policies that include the application-services uac-policy statement.

However, this behavior changes if user role firewall is configured. When a match source-identity statement is included in any policy within a zone pair (source zone + destination zone), user and role information must be retrieved before policy lookup can proceed. (If all policies in the zone pair are set to match source-identity any, or have no match source-identity state, user and role information is not required and the five standard match criteria are used for policy lookup.) Therefore, for any zone pair in which a security policy is configured that contains a match source-identity statement, the firewall sends a drop notification for all traffic matching that source and destination zone, whether or not the traffic matches the specific security policy containing the match source-identity statement. This can result in an unexpected number of drop notifications if a single zone contains a mix of protected and unprotected resources.

In most deployments, it is recommended that you use dynamic auth table allocation. The benefits of dynamic auth table allocation are based on many factors within the network deployment: the number of Infranet Enforcers, the anticipated number of sessions, and the persistence of user sessions.

The following requirements and limitations apply:

•Dynamic auth table allocation is supported for all deployments with Junos Enforcer and with ScreenOS Enforcers running ScreenOS 6.1 or later.

•Dynamic auth table allocation does not work with HTTP traffic if the captive portal feature is configured to redirect user traffic to an external web server other than Pulse Policy Secure. Pulse Policy Secure must be aware of a user login/session before it can provision an auth table entry.

•If you configure dynamic auth table allocation on Pulse Policy Secure, and the DNS server for the network is behind the Infranet Enforcer, endpoints might occasionally experience DNS time-out issues before resources are provisioned.

•Dynamic auth table allocation is required to use IF-MAP Federation.

One scenario in which static auth tables are more practical is a deployment that forces every endpoint to go through a single Infranet Enforcer for all access. In this case, static auth tables can reduce overall traffic between Pulse Policy Secure servers and Infranet Enforcers.

For deployments that use static auth table mapping policies (for example, if you are using a ScreenOS Release 6.1 or earlier), we recommend no more than 100 connected Infranet Enforcers. For deployment scenarios with more than 100 Infranet Enforcers, we recommend a deployment strategy using dynamic auth table allocation.

Testing has shown that with 5,000 active sessions, performance is impacted significantly when dynamic auth table allocation is not configured and 100 connected firewalls are deployed.

Performance metrics vary for each Pulse Policy Secure release.

Configuring Dynamic Auth Table Policies

You can use the dynamic auth table allocation feature to push auth table entries to the Infranet Enforcer only when a user attempts to access a protected resource. This is more efficient than the Auth Table Mapping Policies option, which requires administrators to provision auth table entries for authenticated users whether they are accessing resources or not. Dynamic auth table allocation reduces auth table entries to only those that are needed, enabling you to deploy smaller firewalls with a larger user population.

When dynamic auth table allocation is used and a user attempts to access a protected resource, the Infranet Enforcer does not yet have an auth table entry for the user, so it sends a drop notification to PPS to prompt it to send an auth table entry. Unlike captive portal redirect, which only occurs when the user sends HTTP traffic, drop notifications are triggered by any type of traffic for which the destination is a protected resource.

After the user disconnects, the Infranet Enforcer automatically expires the auth table entry.

On the SRX device, whenever traffic matches a security policy that includes an application-services uac-policy statement, then the firewall sends a drop notification to PPS if there is no auth table entry associated with that traffic. This applies in the captive portal use case, and for all policies that include the application-services uac-policy statement.

However, this behavior changes if user role firewall is configured. When a match source-identity statement is included in any policy within a zone pair (source zone + destination zone), user and role information must be retrieved before policy lookup can proceed. (If all policies in the zone pair are set to match source-identity any, or have no match source-identity state, user and role information is not required and the five standard match criteria are used for policy lookup.) Therefore, for any zone pair in which a security policy is configured that contains a match source-identity statement, the firewall sends a drop notification for all traffic matching that source and destination zone, whether or not the traffic matches the specific security policy containing the match source-identity statement. This can result in an unexpected number of drop notifications if a single zone contains a mix of protected and unprotected resources.

In most deployments, it is recommended that you use dynamic auth table allocation. The benefits of dynamic auth table allocation are based on many factors within the network deployment: the number of Infranet Enforcers, the anticipated number of sessions, and the persistence of user sessions.

The following requirements and limitations apply:

•Dynamic auth table allocation is supported for all deployments with Junos Enforcer and with ScreenOS Enforcers running ScreenOS 6.1 or later.

•Dynamic auth table allocation does not work with HTTP traffic if the captive portal feature is configured to redirect user traffic to an external web server other than PPS. PPS must be aware of a user log in/session before it can provision an auth table entry.

•If you configure dynamic auth table allocation on PPS, and the DNS server for the network is behind the Infranet Enforcer, endpoints might occasionally experience DNS time-out issues before resources are provisioned.

•Dynamic auth table allocation is required to use IF-MAP Federation.

One scenario in which static auth tables are more practical is a deployment that forces every endpoint to go through a single Infranet Enforcer for all access. In this case, static auth tables can reduce overall traffic between PPS servers and Infranet Enforcers.

For deployments that use static auth table mapping policies, we recommend not more than 100 connected Infranet Enforcers. For deployment scenarios with more than 100 Infranet Enforcers, we recommend a deployment strategy using dynamic auth table allocation. Testing has shown that with 5,000 active sessions, performance is impacted significantly when dynamic auth table allocation is not configured and 100 connected firewalls are deployed. Performance metrics vary for each PPS release.

To enable dynamic auth table allocation:

1.Select Infranet Enforcer > Auth Table Mapping in the admin console. Either delete the Default Policy or specify an Enforcer for which you do not want to configure this feature.

2.Click Save Changes.

Binding an Interface to a Security Zone on a Junos Enforcer

Interfaces are the doorways through which traffic enters and exits an Enforcer. Many interfaces share the same security requirements. However, different interfaces can have different security requirements for inbound and outbound data packets. Interfaces with identical security requirements can be grouped together in a single security zone.

A security zone is a collection of network segments that require the regulation of inbound and outbound traffic through policies. Security zones are logical entities to which one or more interfaces are bound. Many types of Enforcers let you define multiple security zones based on network requirements.

You can configure multiple security zones by dividing the network into segments to which you can then apply various security options to satisfy the needs of each segment. At a minimum, you must define two security zones, basically to protect one area of the network from the other. On some security platforms, you can define many security zones, bringing finer granularity to the network security design without deploying multiple security appliances to do so.

From the perspective of security policies, traffic enters one security zone and exits through another security zone. This combination of a "from-zone" and a "to-zone" is defined as a context. Each context contains an ordered list of policies. On the Junos Enforcer, you must define at least two zones to protect one area of the network from another.

You might need to bind the physical interfaces on a Juniper security device to security zones or you might need to change a binding to accommodate your deployment.

Slot numbering varies by platform, and interface numbering varies by module type. For numbering information, see the user guide that accompanied the device for slot and interface numbering information or visit https://www.ivanti.com/support/product-documentation https://www.ivanti.com/support/product-documentation to obtain a copy of the user guide specific to your device.

Endpoints must reside in a different security zone from your protected resources. PPS can reside in any security zone. If you place PPS in a different security zone from the one that contains endpoints, you must set a policy allowing traffic from the endpoints to PPS.

Through the policies you define, you can permit traffic between zones to flow in one or both directions. The routes that you define specify the interfaces that traffic from one zone to another must use. Because you can bind multiple interfaces to a zone, the routes you chart are important for directing traffic to the interfaces of your choice.