Juniper : Introduction to the Junos Operating System

To secure a network, a network administrator must create a security policy that outlines all of the network resources within that business and the required security level for those resources. Junos OS allows you to configure security policies. Security policies enforce rules for transit traffic, in terms of what traffic can pass through the firewall, and the actions that need to take place on traffic as it passes through the firewall.

Understanding Security Policy Elements

A security policy is a set of statements that controls traffic from a specified source to a specified destination using a specified service. A policy permits, denies, or tunnels specified types of traffic unidirectionally between two points.

Each policy consists of:

A unique name for the policy.
A from-zone and a to-zone, for example: user@host# set security policies from-zone untrust to-zone untrust
A set of match criteria defining the conditions that must be satisfied to apply the policy rule. The match criteria are based on a source IP address, destination IP address, and applications. The user identity firewall provides greater granularity by including an additional tuple, source-identity, as part of the policy statement.
A set of actions to be performed in case of a match—permit, deny, or reject.
Accounting and auditing elements—counting, logging, or structured system logging.

If the SRX Series receives a packet that matches those specifications, it performs the action specified in the policy.

Security policies enforce a set of rules for transit traffic, identifying which traffic can pass through the firewall and the actions taken on the traffic as it passes through the firewall. Actions for traffic matching the specified criteria include permit, deny, reject, log, or count.

For SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550M devices, a factory default security policy is provided that:

Allows all traffic from the trust zone to the untrust zone.
Allows all traffic between trusted zones, that is from the trust zone to intrazone trusted zones.
Denies all traffic from the untrust zone to the trust zone.

Understanding Security Policy Rules

The security policy applies the security rules to the transit traffic within a context (from-zone to to-zone). Each policy is uniquely identified by its name. The traffic is classified by matching its source and destination zones, the source and destination addresses, and the application that the traffic carries in its protocol headers with the policy database in the data plane.

Each policy is associated with the following characteristics:

A source zone
A destination zone
One or many source address names or address set names
One or many destination address names or address set names
One or many application names or application set names

These characteristics are called the match criteria. Each policy also has actions associated with it: permit, deny, reject, count, log, and VPN tunnel. You have to specify the match condition arguments when you configure a policy, source address, destination address, and application name.

You can specify to configure a policy with IPv4 or IPv6 addresses using the wildcard entry any. When flow support is not enabled for IPv6 traffic, any matches IPv4 addresses. When flow support is enabled for IPv6 traffic, any matches both IPv4 and IPv6 addresses. To enable flow-based forwarding for IPv6 traffic, use the set security forwarding-options family inet6 mode flow-based command. You can also specify the wildcard any-ipv4 or any-ipv6 for the source and destination address match criteria to include only IPv4 or only IPv6 addresses, respectively.

When flow support for IPv6 traffic is enabled, the maximum number of IPv4 or IPv6 addresses that you can configure in a security policy is based on the following match criteria:

Number_of_src_IPv4_addresses + number_of_src_IPv6_addresses * 4 <= 1024
Number_of_dst_IPv4_addresses + number_of_dst_IPv6_addresses * 4 <= 1024

Thr reason for the match criteria is that an IPv6 address uses four times the memory space that an IPv4 address uses.

NOTE:

You can configure a security policy with IPv6 addresses only if flow support for IPv6 traffic is enabled on the device.

If you do not want to specify a specific application, enter any as the default application. To look up the default applications, from configuration mode, enter show groups junos-defaults | find applications (predefined applications). For example, if you do not supply an application name, the policy is installed with the application as a wildcard (default). Therefore, any data traffic that matches the rest of the parameters in a given policy would match the policy regardless of the application type of the data traffic.

NOTE:

If a policy is configured with multiple applications, and more than one of the applications match the traffic, then the application that best meets the match criteria is selected.

The action of the first policy that the traffic matches is applied to the packet. If there is no matching policy, the packet is dropped. Policies are searched from top to bottom, so it is a good idea to place more specific policies near the top of the list. You should also place IPsec VPN tunnel policies near the top. Place the more general policies, such as one that would allow certain users access to all Internet applications, at the bottom of the list. For example, place deny-all or reject-all policies at the bottom after all of the specific policies have been parsed before and legitimate traffic has been allowed/count/logged.

NOTE:

Support for IPv6 addresses is added in Junos OS Release 10.2. Support for IPv6 addresses in active/active chassis cluster configurations (in addition to the existing support of active/passive chassis cluster configurations) is added in Junos OS Release 10.4.

Policies are looked up during flow processing after firewall filters and screens have been processed and route look up has been completed by the Services Processing Unit (SPU) (for SRX5400, SRX5600, and SRX5800 devices). Policy look up determines the destination zone, destination address, and egress interface.

When you are creating a policy, the following policy rules apply:

Security policies are configured in a from-zone to to-zone direction. Under a specific zone direction, each security policy contains a name, match criteria, an action, and miscellaneous options.
The policy name, match criteria, and action are required.
The policy name is a keyword.
The source address in the match criteria is composed of one or more address names or address set names in the from-zone.
The destination address of the match criteria is composed of one or more address names or address set names in the to-zone.
The application name in the match criteria is composed of the name of one or more applications or application sets.
One of the following actions is required: permit, deny, or reject.
Accounting and auditing elements can be specified: count and log.
You can enable logging at the end of a session with the session-close command, or at the beginning of the session with the session-init command.
When the count alarm is turned on, specify alarm thresholds in bytes per second or kilobytes per minute.
You cannot specify global as either the from-zone or the to-zone except under following condition:
Any policy configured with the to-zone as a global zone must have a single destination address to indicate that either static NAT or incoming NAT has been configured in the policy.
In SRX Series Firewalls, the policy permit option with NAT is simplified. Each policy will optionally indicate whether it allows NAT translation, does not allow NAT translation, or does not care.
Address names cannot begin with the following reserved prefixes. These are used only for address NAT configuration:
- static_nat_
- incoming_nat_
- junos_
Application names cannot begin with the junos_ reserved prefix.

Understanding Wildcard Addresses

Source and destination addresses are two of the five match criteria that should be configured in a security policy. You can now configure wildcard addresses for the source and destination address match criteria in a security policy. A wildcard address is represented as A.B.C.D/wildcard-mask. The wildcard mask determines which of the bits in the IP address A.B.C.D should be ignored by the security policy match criteria. For example, the source IP address 192.168.0.11/255.255.0.255 in a security policy implies that the security policy match criteria can discard the third octet in the IP address (symbolically represented as 192.168.*.11). Therefore, packets with source IP addresses such as 192.168.1.11 and 192.168.22.11 conform to the match criteria. However, packets with source IP addresses such as 192.168.0.1 and 192.168.1.21 do not satisfy the match criteria.

The wildcard address usage is not restricted to full octets only. You can configure any wildcard address. For example, the wildcard address 192.168. 7.1/255.255.7.255 implies that you need to ignore only the first 5 bits of the third octet of the wildcard address while making the policy match. If the wildcard address usage is restricted to full octets only, then wildcard masks with either 0 or 255 in each of the four octets only will be permitted.

NOTE:

The first octet of the wildcard mask should be greater than 128. For example, a wildcard mask represented as 0.255.0.255 or 1.255.0.255 is invalid.

A wildcard security policy is a simple firewall policy that allows you to permit, deny, and reject the traffic trying to cross from one security zone to another. You should not configure security policy rules using wildcard addresses for services such as Content Security .

NOTE:

Only Intrusion and Prevention (IDP) for IPv6 sessions is supported for all SRX5400, SRX5600, and SRX5800 devices. Content Security for IPv6 sessions is not supported. If your current security policy uses rules with the IP address wildcard any, and Content Security features are enabled, you will encounter configuration commit errors because Content Security features do not yet support IPv6 addresses. To resolve the errors, modify the rule returning the error so that the any-ipv4 wildcard is used; and create separate rules for IPv6 traffic that do not include Content Security features.

Configuring wildcard security policies on a device affects performance and memory usage based on the number of wildcard policies configured per from-zone and to-zone context. Therefore, you can only configure a maximum of 480 wildcard policies for a specific from-zone and to-zone context.

Understanding Security Policies for Self Traffic

Security policies are configured on the devices to apply services to the traffic flowing through the device. For example UAC and Content Security policies are configured to apply services to the transient traffic.

Self-traffic or host traffic, is the host-inbound traffic; that is, the traffic terminating on the device or the host-outbound traffic that is the traffic originating from the device. You can now configure policies to apply services on self traffic. Services like the SSL stack service that must terminate the SSL connection from a remote device and perform some processing on that traffic, IDP services on host-inbound traffic, or IPsec encryption on host-outbound traffic must be applied through the security policies configured on self-traffic.

When you configure a security policy for self-traffic, the traffic flowing through the device is first checked against the policy, then against the host-inbound-traffic option configured for the interfaces bound to the zone.

You can configure the security policy for self-traffic to apply services to self-traffic. The host-outbound policies will work only in cases where the packet that originated in the host device goes through the flow and the incoming interface of this packet is set to local.

The advantages of using the self-traffic are:

You can leverage most of the existing policy or flow infrastructure used for the transit traffic.
You do not need a separate IP address to enable any service.
You can apply services or policies to any host-inbound traffic with the destination IP address of any interface on the device.

NOTE:

On SRX Series Firewalls, the default security policy rules do not affect self-traffic.

NOTE:

You can configure the security policy for self-traffic with relevant services only. For example, it is not relevant to configure the fwauth service on host-outbound traffic, and gprs-gtp services are not relevant to the security policies for self-traffic.

The security policies for the self traffic are configured under the new default security zone called the junos-host zone. The junos-host zone will be part of the junos-defaults configuration, so users cannot delete it. The existing zone configurations such as interfaces, screen, tcp-rst, and host-inbound-traffic options are not meaningful to the junos-host zone. Therefore there is no dedicated configuration for the junos-host zone.

NOTE:

You can use host-inbound-traffic to control incoming connections to a device; however it does not restrict traffic going out of the device. Whereas, junos-host-zone allows you to select the application of your choice and also restrict outgoing traffic. For example, services like NAT, IDP, Content Security, and so forth can now be enabled for traffic going in or out of the SRX Series Firewall using junos-host-zone.

Security Policies Configuration Overview

You must complete the following tasks to create a security policy:

Create zones. See Example: Creating Security Zones.
Configure an address book with addresses for the policy. See Example: Configuring Address Books and Address Sets.
Create an application (or application set) that indicates that the policy applies to traffic of that type. See Example: Configuring Security Policy Applications and Application Sets.
Create the policy. See Example: Configuring a Security Policy to Permit or Deny All Traffic, Example: Configuring a Security Policy to Permit or Deny Selected Traffic, and Example: Configuring a Security Policy to Permit or Deny Wildcard Address Traffic.
Create schedulers if you plan to use them for your policies. See Example: Configuring Schedulers for a Daily Schedule Excluding One Day.

The Firewall Policy Wizard enables you to perform basic security policy configuration. For more advanced configuration, use the J-Web interface or the CLI.

Best Practices for Defining Policies on SRX Series Devices

A secure network is vital to a business. To secure a network, a network administrator must create a security policy that outlines all of the network resources within that business and the required security level for those resources. The security policy applies the security rules to the transit traffic within a context (from-zone to to-zone) and each policy is uniquely identified by its name. The traffic is classified by matching the source and destination zones, the source and destination addresses, and the application that the traffic carries in its protocol headers with the policy database in the data plane.

Table 1 provides the policy limitations for SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX650, SRX550M, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, SRX5400, SRX5600, and SRX5800 devices. Platform support depends on the Junos OS release in your installation.

NOTE:

Starting with Junos OS Release 12.3X48-D15 and Junos OS Release 17.3R1, the maximum number of address objects per policy for SRX5400, SRX5600, and SRX5800 devices increases from 1024 to 4096, and the maximum number of policies per context increases from 10240 to 80,000.

Starting with Junos OS Release 17.3R1, the number of security policies and the maximum number of policies per context for SRX5400, SRX5600, and SRX5800 devices increases from 80,000 to 100,000.

Starting with Junos OS Release 15.1X49-D120, the number of address objects per policy for SRX5400, SRX5600, and SRX5800 increases from 4096 to 16,000.

Table 1: Policy Limitations for SRX Series Devices
SRX Series Devices	Address Objects	Application objects	Security policies	Policy contexts (zone pairs)	Policies per context	Policies with counting enabled
SRX300SRX320	2048	128	1024	256	1024	256
SRX340	2048	128	2048	512	2048	256
SRX345	2048	128	4096	1024	4096	256
SRX380	2048	128	4096	1024	4096	256
SRX550M	2048	128	10240	2048	10240	1024
SRX1500	4096	3072	16000	4096	16000	1024
SRX4100	4096	3072	60000	4096	60000	1024
SRX4200	4096	3072	60000	4096	60000	1024
SRX4600	4096	3072	80000	8192	80000	1024
SRX5400SRX5600SRX5800	16384	3072	100000	8192	100000	1024

Therefore, as you increase the number of addresses and applications in each rule, the amount of memory that is used by the policy definition increases, and sometimes the system runs out of memory with fewer than 80,000 policies.

To get the actual memory utilization of a policy on the Packet Forwarding Engine (PFE) and the Routing Engine (RE), you need to take various components of the memory tree into consideration. The memory tree includes the following two components:

Policy context–Used to organize all policies in this context. Policy context includes variables such as source and destination zones.
Policy entity–Used to hold the policy data. Policy entity calculates memory using parameters such as policy name, IP addresses, address count, applications, firewall authentication, WebAuth, IPsec, count, application services, and Junos Services Framework (JSF).

Additionally, the data structures used to store policies, rule sets, and other components use different memory on the Packet Forwarding Engine and on the Routing Engine. For example, address names for each address in the policy are stored on the Routing Engine, but no memory is allocated at the Packet Forwarding Engine level. Similarly, port ranges are expanded to prefix and mask pairs and are stored on the Packet Forwarding Engine, but no such memory is allocated on the Routing Engine.

Accordingly, depending on the policy configuration, the policy contributors to the Routing Engine are different from those to the Packet Forwarding Engine, and memory is allocated dynamically.

Memory is also consumed by the “deferred delete” state. In the deferred delete state, when an SRX Series Firewall applies a policy change, there is transitory peak usage whereby both the old and new policies are present. So for a brief period, both old and new policies exist on the Packet Forwarding Engine, taking up twice the memory requirements.

Therefore, there is no definitive way to infer clearly how much memory is used by either component (Packet Forwarding Engine or Routing Engine) at any given point in time, because memory requirements are dependent on specific configurations of policies, and memory is allocated dynamically.

The following best practices for policy implementation enable you to better use system memory and to optimize policy configuration:

Use single prefixes for source and destination addresses. For example, instead of using /32 addresses and adding each address separately, use a large subnet that covers most of the IP addresses you require.
Use application “any” whenever possible. Each time you define an individual application in the policy, you can use an additional 52 bytes.
Use fewer IPv6 addresses because IPv6 addresses consume more memory.
Use fewer zone pairs in policy configurations. Each source or destination zone uses about 16,048 bytes of memory.
The following parameters can change how memory is consumed by the bytes as specified:
- Firewall authentication–About 16 bytes or more (unfixed)
- Web authentication–About 16 bytes or more (unfixed)
- IPsec–12 bytes
- Application services–28 bytes
- Count–64 bytes
Check memory utilization before and after compiling policies.
NOTE:
The memory requirement for each device is different. Some devices support 512,000 sessions by default, and the bootup memory is usually at 72 to 73 percent. Other devices can have up to 1 million sessions and the bootup memory can be up to 83 to 84 percent. In the worst-case scenario, to support about 80,000 policies in the SPU, the SPU should boot with a flowd kernel memory consumption of up to 82 percent, and with at least 170 megabytes of memory available.

Configuring Policies Using the Firewall Wizard

The Firewall Policy Wizard enables you to perform basic security policy configuration on SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550M devices.. For more advanced configuration, use the J-Web interface or the CLI.

To configure policies using the Firewall Policy Wizard:

Select Configure>Tasks>Configure FW Policy in the J-Web interface.
Click the Launch Firewall Policy Wizard button to launch the wizard.
Follow the prompts in the wizard.

The upper-left area of the wizard page shows where you are in the configuration process. The lower-left area of the page shows field-sensitive help. When you click a link under the Resources heading, the document opens in your browser. If the document opens in a new tab, be sure to close only the tab (not the browser window) when you close the document.

Example: Configuring a Security Policy to Permit or Deny All Traffic

This example shows how to configure a security policy to permit or deny all traffic.

Requirements

Before you begin:

Create zones. See Example: Creating Security Zones.
Configure an address book and create addresses for use in the policy. See Example: Configuring Address Books and Address Sets.
Create an application (or application set) that indicates that the policy applies to traffic of that type. See Example: Configuring Security Policy Applications and Application Sets.

Overview

In the Junos OS, security policies enforce rules for transit traffic, in terms of what traffic can pass through the device, and the actions that need to take place on traffic as it passes through the device. From the perspective of security policies, the traffic enters one security zone and exits another security zone. In this example, you configure the trust and untrust interfaces, ge-0/0/2 and ge-0/0/1. See Figure 1.

Figure 1: Permitting All Traffic

This configuration example shows how to:

Permit or deny all traffic from the trust zone to the untrust zone but block everything from the untrust zone to the trust zone.
Permit or deny selected traffic from a host in the trust zone to a server in the untrust zone at a particular time.

Topology

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

content_copy zoom_out_map
set security zones security-zone trust interfaces ge-0/0/2 host-inbound-traffic system-services all 
set security zones security-zone untrust interfaces ge-0/0/1 host-inbound-traffic system-services all 
set security policies from-zone trust to-zone untrust policy permit-all match source-address any
set security policies from-zone trust to-zone untrust policy permit-all match destination-address any 
set security policies from-zone trust to-zone untrust policy permit-all match application any
set security policies from-zone trust to-zone untrust policy permit-all then permit
set security policies from-zone untrust to-zone trust policy deny-all match source-address any
set security policies from-zone untrust to-zone trust policy deny-all match destination-address any
set security policies from-zone untrust to-zone trust policy deny-all match application any
set security policies from-zone untrust to-zone trust policy deny-all then deny

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.

To configure a security policy to permit or deny all traffic:

Configure the interfaces and security zones.

content_copy zoom_out_map
[edit security zones]
user@host# set security-zone trust interfaces ge-0/0/2 host-inbound-traffic system-services all 
user@host# set security-zone untrust interfaces ge-0/0/1 host-inbound-traffic system-services all 

Create the security policy to permit traffic from the trust zone to the untrust zone.

content_copy zoom_out_map
[edit security policies from-zone trust to-zone untrust]
user@host# set policy permit-all match source-address any
user@host# set policy permit-all match destination-address any 
user@host# set policy permit-all match application any
user@host# set policy permit-all then permit

Create the security policy to deny traffic from the untrust zone to the trust zone.

content_copy zoom_out_map
[edit security policies from-zone untrust to-zone trust]
user@host# set policy deny-all match source-address any
user@host# set policy deny-all match destination-address any
user@host# set policy deny-all match application any
user@host# set policy deny-all then deny

Results

From configuration mode, confirm your configuration by entering the show security policies and show security zones commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

NOTE:

The configuration example is a default permit-all from the trust zone to the untrust zone.

content_copy zoom_out_map
[edit]
user@host# show security policies
from-zone trust to-zone untrust {
    policy permit-all {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone untrust to-zone trust {
    policy deny-all {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
        }
    }
}
Show more 

content_copy zoom_out_map
user@host# show security zones
security-zone trust {
    interfaces {
        ge-0/0/2.0 {
            host-inbound-traffic {
                system-services {
                    all;
                }
            }
        }
    }
}
security-zone untrust {
    interfaces {
        ge-0/0/1.0 {
            host-inbound-traffic {
                system-services {
                    all;
                }
            }
        }
    }
}
Show more 

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Policy Configuration

Purpose

Verify information about security policies.

Action

From operational mode, enter the show security policies detail command to display a summary of all security policies configured on the device.

Meaning

The output displays information about policies configured on the system. Verify the following information:

From and to zones
Source and destination addresses
Match criteria

Example: Configuring a Security Policy to Permit or Deny Selected Traffic

This example shows how to configure a security policy to permit or deny selected traffic.

Requirements

Before you begin:

Create zones. See Example: Creating Security Zones.
Configure an address book and create addresses for use in the policy. See Example: Configuring Address Books and Address Sets.
Create an application (or application set) that indicates that the policy applies to traffic of that type. See Example: Configuring Security Policy Applications and Application Sets.
Permit traffic to and from trust and untrust zones. See Example: Configuring a Security Policy to Permit or Deny All Traffic.

Overview

In Junos OS, security policies enforce rules for the transit traffic, in terms of what traffic can pass through the device, and the actions that need to take place on the traffic as it passes through the device. From the perspective of security policies, the traffic enters one security zone and exits another security zone. In this example, you configure a specific security policy to allow only e-mail traffic from a host in the trust zone to a server in the untrust zone. No other traffic is allowed. See Figure 2.

Figure 2: Permitting Selected Traffic

Configuration

Procedure

CLI Quick Configuration

content_copy zoom_out_map
set security zones security-zone trust interfaces ge-0/0/2 host-inbound-traffic system-services all 
set security zones security-zone untrust interfaces ge-0/0/1 host-inbound-traffic system-services all 
set security address-book book1 address mail-untrust 203.0.113.14/24 
set security address-book book1 attach zone untrust 
set security address-book book2 address mail-trust 192.168.1.1/32 
set security address-book book2 attach zone trust
set security policies from-zone trust to-zone untrust policy permit-mail match source-address mail-trust
set security policies from-zone trust to-zone untrust policy permit-mail match destination-address mail-untrust 
set security policies from-zone trust to-zone untrust policy permit-mail match application junos-mail 
set security policies from-zone trust to-zone untrust policy permit-mail then permit 

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.

To configure a security policy to allow selected traffic:

Configure the interfaces and security zones.

content_copy zoom_out_map
[edit security zones]
user@host# set security-zone trust interfaces ge-0/0/2 host-inbound-traffic system-services all 
user@host# set security-zone untrust interfaces ge-0/0/1 host-inbound-traffic system-services all 

Create address book entries for both the client and the server. Also, attach security zones to the address books.

content_copy zoom_out_map
[edit security address-book book1]
user@host# set address mail-untrust 203.0.113.14/24 
user@host# set attach zone untrust 

content_copy zoom_out_map
[edit security address-book book2]
user@host# set address mail-trust 192.168.1.1/32 
user@host# set attach zone trust

Define the policy to permit mail traffic.

content_copy zoom_out_map
[edit security policies from-zone trust to-zone untrust]
user@host# set policy permit-mail match source-address mail-trust
user@host# set policy permit-mail match destination-address mail-untrust 
user@host# set policy permit-mail match application junos-mail 
user@host# set policy permit-mail then permit

Results

content_copy zoom_out_map
[edit]
user@host# show security policies
from-zone trust to-zone untrust {
    policy permit-mail {
        match {
            source-address mail-trust;
            destination-address mail-untrust;
            application junos-mail;
        }
        then {
            permit;
        }
    }
}
Show more 

content_copy zoom_out_map
user@host# show security zones
security-zone trust {
    host-inbound-traffic {
        system-services {
            all;
        }
        interfaces {
            ge-0/0/2 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                }
            }
        }
    }
    security-zone untrust {
        interfaces {
            ge-0/0/1 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                }
            }
        }
    }
Show more 

content_copy zoom_out_map
user@host# show security address-book
book1 {
    address mail-untrust 203.0.113.14/24;
    attach {
        zone untrust;
    }
}
    book2 {
        address mail-trust 192.168.1.1/32;
        attach {
            zone trust;
        }
    }

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Policy Configuration

Purpose

Verify information about security policies.

Action

From operational mode, enter the show security policies detail command to display a summary of all security policies configured on the device.

Meaning

The output displays information about policies configured on the system. Verify the following information:

From and to zones
Source and destination addresses
Match criteria

Example: Configuring a Security Policy to Permit or Deny Wildcard Address Traffic

This example shows how to configure a security policy to permit or deny wildcard address traffic.

Requirements

Before you begin:

Understand wildcard addresses. See Understanding Security Policy Rules.
Create zones. See Example: Creating Security Zones.
Configure an address book and create addresses for use in the policy. See Example: Configuring Address Books and Address Sets.
Create an application (or application set) that indicates that the policy applies to traffic of that type. See Example: Configuring Security Policy Applications and Application Sets.
Permit traffic to and from trust and untrust zones. See Example: Configuring a Security Policy to Permit or Deny All Traffic.
Permit e-mail traffic to and from trust and untrust zones. See Example: Configuring a Security Policy to Permit or Deny Selected Traffic

Overview

In the Junos operating system (Junos OS), security policies enforce rules for the transit traffic, in terms of what traffic can pass through the device, and the actions that need to take place on the traffic as it passes through the device. From the perspective of security policies, the traffic enters one security zone and exits another security zone. In this example, you configure a specific security to allow only wildcard address traffic from a host in the trust zone to the untrust zone. No other traffic is allowed.

Configuration

Procedure

CLI Quick Configuration

content_copy zoom_out_map
set security zones security-zone trust interfaces ge-0/0/2 host-inbound-traffic system-services all 
set security zones security-zone untrust interfaces ge-0/0/1 host-inbound-traffic system-services all 
set security address-book book1 address wildcard-trust wildcard-address 192.168.0.11/255.255.0.255 
set security address-book book1 attach zone trust
set security policies from-zone trust to-zone untrust policy permit-wildcard match source-address wildcard-trust
set security policies from-zone trust to-zone untrust policy permit-wildcard match destination-address any
set security policies from-zone trust to-zone untrust policy permit-wildcard match application any
set security policies from-zone trust to-zone untrust policy permit-wildcard then permit 

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.

To configure a security policy to allow selected traffic:

Configure the interfaces and security zones.

content_copy zoom_out_map
[edit security zones]
user@host# set security-zone trust interfaces ge-0/0/2 host-inbound-traffic system-services all 
user@host# set security-zone untrust interfaces ge-0/0/1 host-inbound-traffic system-services all 

Create an address book entry for the host and attach the address book to a zone.

content_copy zoom_out_map
[edit security address-book book1]
user@host# set address wildcard-trust wildcard-address 192.168.0.11/255.255.0.255 
user@host# set attach zone trust

Define the policy to permit wildcard address traffic.

content_copy zoom_out_map
[edit security policies from-zone trust to-zone untrust]
user@host# set policy permit-wildcard match source-address wildcard-trust
user@host# set policy permit-wildcard match destination-address any
user@host# set policy permit-wildcard match application any
user@host# set policy permit-wildcard then permit

Results

content_copy zoom_out_map
[edit]
user@host# show security policies
from-zone trust to-zone untrust {
    policy permit-wildcard {
        match {
            source-address wildcard-trust;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
Show more 

content_copy zoom_out_map
user@host# show security zones
security-zone trust {
    host-inbound-traffic {
        system-services {
            all;
        }
        interfaces {
            ge-0/0/2 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                }
            }
        }
    }
}
    security-zone untrust {
        interfaces {
            ge-0/0/1 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                }
            }
        }
    }
user@host# show security address-book
book1 {
    address wildcard-trust {
        wildcard-address 192.168.0.11/255.255.0.255;
    }
    attach {
        zone trust;
    }
}
Show more 

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Policy Configuration

Purpose

Verify information about security policies.

Action

From operational mode, enter the show security policies policy-name permit-wildcard detail command to display details about the permit-wildcard security policy configured on the device.

Meaning

The output displays information about the permit-wildcard policy configured on the system. Verify the following information:

From and To zones
Source and destination addresses
Match criteria

Example: Configuring a Security Policy to Redirect Traffic Logs to an External System Log Server

This example shows how to configure a security policy to send traffic logs generated on the device to an external system log server.

Requirements

This example uses the following hardware and software components:

A client connected to an SRX5600 device at the interface ge-4/0/5
A server connected to the SRX5600 device at the interface ge-4/0/1
The logs generated on the SRX5600 device are stored in a Linux-based system log server.
An SRX5600 device connected to the Linux-based server at interface ge-4/0/4

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you configure a security policy on the SRX5600 device to send traffic logs, generated by the device during data transmission, to a Linux-based server. Traffic logs record details of every session. The logs are generated during session establishment and termination between the source and the destination device that are connected to the SRX5600 device.

zoom_out_map

Configuration

Procedure

CLI Quick Configuration

content_copy zoom_out_map
set security log source-address 127.0.0.1
set security log stream trafficlogs severity debug 
set security log stream trafficlogs host 203.0.113.2 
set security zones security-zone client host-inbound-traffic system-services all 
set security zones security-zone client host-inbound-traffic protocols all 
set security zones security-zone client interfaces ge-4/0/5.0 
set security zones security-zone server host-inbound-traffic system-services all 
set security zones security-zone server interfaces ge-4/0/4.0 
set security zones security-zone server interfaces ge-4/0/1.0 
set security policies from-zone client to-zone server policy policy-1 match source-address any 
set security policies from-zone client to-zone server policy policy-1 match destination-address any 
set security policies from-zone client to-zone server policy policy-1 match application any 
set security policies from-zone client to-zone server policy policy-1 then permit  
set security policies from-zone client to-zone server policy policy-1 then log session-init 
set security policies from-zone client to-zone server policy policy-1 then log session-close 
Show more 

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.

To configure a security policy to send traffic logs to an external system log server:

Configure security logs to transfer traffic logs generated at the SRX5600 device to an external system log server with the IP address 203.0.113.2. The IP address 127.0.0.1 is the loopback address of the SRX5600 device.
```
[edit security log]
user@host# set source-address 127.0.0.1
user@host# set stream trafficlogs severity debug 
user@host# set stream trafficlogs host  203.0.113.2 
```

Configure a security zone and specify the types of traffic and protocols that are allowed on interface ge-4/0/5.0 of the SRX5600 device.

content_copy zoom_out_map
[edit security zones]
user@host# set security-zone client host-inbound-traffic system-services all 
user@host# set security-zone client host-inbound-traffic protocols all 
user@host# set security-zone client interfaces ge-4/0/5.0 

Configure another security zone and specify the types of traffic that are allowed on the interfaces ge-4/0/4.0 and ge-4/0/1.0 of the SRX5600 device.

content_copy zoom_out_map
[edit security zones]
user@host# set security-zone server host-inbound-traffic system-services all 
user@host# set security-zone server interfaces ge-4/0/4.0 
user@host# set security-zone server interfaces ge-4/0/1.0 

Create a policy and specify the match criteria for that policy. The match criteria specifies that the device can allow traffic from any source, to any destination, and on any application.

content_copy zoom_out_map
[edit security policies from-zone client to-zone server]
user@host# set policy policy-1 match source-address any 
user@host# set policy policy-1 match destination-address any 
user@host# set policy policy-1 match application any 
user@host# set policy policy-1 match then permit 

Enable the policy to log traffic details at the beginning and at the end of the session.

content_copy zoom_out_map
[edit security policies from-zone client to-zone server]
user@host# set policy policy-1 then log session-init 
user@host# set policy policy-1 then log session-close 

Results

From configuration mode, confirm your configuration by entering the show security log command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

content_copy zoom_out_map
[edit]
user@host# show security log
format syslog;
source-address 127.0.0.1;
stream trafficlogs {
    severity debug;
    host {
        203.0.113.2;
    }
}

If you are done configuring the device, enter commit from the configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying Zones

Purpose

Verify that the security zone is enabled or not.

Action

From operational mode, enter the show security zones command.

Verifying Policies

Purpose

Verify that the policy is working.

Action

From operational mode, enter the show security policies command on all the devices.

TAP Mode for Security Zones and Policies

The Terminal Access Point (TAP) mode for security zones and policy allows you to passively monitor traffic flows across a network by way of a switch SPAN or mirror port.

Understanding TAP Mode Support for Security Zones and Policies

The Terminal Access Point (TAP) mode is a standby device, which checks the mirrored traffic through switch. If security zones and policies are configured, then the TAP mode inspects the incoming and outgoing traffic by configuring the TAP interface and generating a security log report to display the number of threats detected and the user usage. If some packet gets lost in the tap interface, the security zones and policies terminates the connection, as a result no report generates for this connection. The security zone and policy configuration remains the same as non-TAP mode.

When you configure an SRX Series Firewall to operate in TAP mode, the device generates security log information to display the information on threats detected, application usage, and user details. When the device is configured to operate in TAP mode, the SRX Series Firewall receives packets only from the configured TAP interface. Except the configured TAP interface, other interface are configured to normal interface that is used as management interface or connected to the outside server. The SRX Series Firewall will generate security report or log according to the incoming traffic.

The security zone and default security policy will be configured after TAP interface is configured. You can configure other zones or policies if required. If one interface is used to connect a server then the IP address, routing-interface, and security configuration also need be configured.

NOTE:

You can configure only one TAP interface when you operate the device in TAP mode.

Example: Configuring Security Zones and Policies in TAP mode

This example shows how to configure security zones, and policies when the SRX Series Firewall is configured in TAP (Terminal Access Point) mode.

Requirements

This example uses the following hardware and software components:

An SRX Series Firewall
Junos OS Release 19.1R1

Before you begin:

Read the Understanding TAP Mode Support for Security Zones and Policies to understand how and where this procedure fits in the overall support for Security Zones and Policies.

Overview

In this example, you configure the SRX Series Firewall to operate in TAP mode. When you configure the SRX Series Firewall to operate in TAP mode, the device generates security log information to display the information on threats detected, application usage, and user details.

Configuration

CLI Quick Configuration

content_copy zoom_out_map
set security zones security-zone tap-zone interfaces ge-0/0/0.0
set security zones security-zone tap-zone application-tracking
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match source-address any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match destination -address any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match application any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then permit
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-init
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-close

Procedure

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure zones in TAP mode:

Configure security zone tap-zone interface.

content_copy zoom_out_map
user@host# set security zones security-zone tap-zone interfaces ge-0/0/0.0

Configure security zone tap-zone application-tracking.
```
user@host# set security zones security-zone tap-zone application-tracking
```

Configure security policy that permits traffic from zone tap-zone to zone tap-zone policy tap and configure the match condition.

content_copy zoom_out_map
user@host# set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match source-address any
user@host# set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match destination -address any
user@host# set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match application any
user@host# set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then permit
user@host# set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-init
user@host# set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-close

Results

From configuration mode, confirm your configuration by entering the show security zones and show security policies commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

content_copy zoom_out_map
[edit]
user@host#show security zones
    security-zone tap-zone {
        interfaces {
            ge-0/0/0.0;
        }
        application-tracking;
    }
[edit]
user@host#show security policies
    from-zone tap-zone to-zone tap-zone {
        policy tap-policy {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                permit;
                log {
                    session-init;
                    session-close;
                }
            }
        }
    }
Show more 

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying Policy Configuration in TAP Mode

Purpose

Verify information about security policies.

Action

From operational mode, enter the show security policies detail command.

content_copy zoom_out_map
user@host> show security policies detail
node0:
--------------------------------------------------------------------------
Default policy: permit-all
Pre ID default policy: permit-all
Policy: Trust_to_Untrust, action-type: permit, State: enabled, Index: 4, Scope Policy: 0
  Policy Type: Configured
  Sequence number: 1
  From zone: izone, To zone: ozone
  Source addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Destination addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No
  Session log: at-create, at-close
Policy: Untrust_to_Trust, action-type: permit, State: enabled, Index: 5, Scope Policy: 0
  Policy Type: Configured
  Sequence number: 1
  From zone: ozone, To zone: izone
  Source addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Destination addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No
  Session log: at-create, at-close
Show more 

Meaning

Displays a summary of all security policies configured on the device in TAP mode.

Dynamic Address Groups in Security Policies

Manually adding address entries into a policy can be time consuming. There are external sources that provide lists of IP addresses that have a specific purpose (such as a blocklist) or that have a common attribute (such as a particular location or behavior that might pose a threat). You can use the external source to identify threat sources by their IP address, then group those addresses into a dynamic address entry, and reference that entry in a security policy. Thereby you can control the traffic to and from those addresses. Each such group of IP addresses is referred to as a dynamic address entry.

The following types of IP addresses are supported:

Single IP. For example : 192.0.2.0
IP range. For example : 192.0.2.0- 192.0.2.10
CIDR. For example : 192.0.2.0/24

Each entry occupies one line. Starting in Junos OS Release 19.3R1, IP address ranges do not need to be sorted in ascending order and the value of the IP entries can overlap in the same feed file. In Junos OS Releases before 19.3R1, IP address ranges need to be sorted in ascending order and the value of the IP entries cannot overlap in the same feed file.

NOTE:

A dynamic address entry is a group of IP addresses, not a single IP prefix. A dynamic address entry is different from the security address concepts of address books and address entry addresses.

The following are the benefits of deploying dynamic address entries in security policies:

The network administrator has more control over the traffic to and from groups of IP addresses.
The external server provides updated IP address feeds to the SRX Series Firewall.
The administrator’s efforts are dramatically reduced. For example, in a legacy security policy configuration, adding 1000 address entries for a policy to reference would require some 2000 lines of configuration. By defining a dynamic address entry and referencing it in a security policy, up to millions of entries could flow into the SRX Series Firewall without much additional configuration effort.
No commit process is required to add new addresses. Adding thousands of addresses to a configuration through a legacy method takes a long time to commit. Alternatively, IP addresses in a dynamic address entry come from an external feed, so no commit process is required when the addresses in an entry change.

Figure 3 illustrates a functional overview of how the dynamic address entry in a security policy works.

Figure 3: Functional Components of the Dynamic Address Entry in a Security Policy

zoom_out_map

A security policy references the dynamic address entry in a source address or destination address field (in much the same way that a security policy references a legacy address entry).

Figure 4 illustrates a policy that uses a dynamic address entry in the Destination-address field.

Figure 4: A Dynamic Address Entry in a Security Policy

In Figure 4, Policy 1 uses the destination address 10.10.1.1, which is a legacy security address entry. Policy 2 uses the destination address Vendor blocklist, which is a dynamic address entry named by the network administrator. Its content is the list of IP addresses retrieved from an external feed file. Packets that match all five criteria (the From-zone named untrust, the To-zone named engineer, any source address, a destination IP address that belongs to the Vendor blocklist dynamic address entry, and the mail application) are handled according to the policy actions, which are to deny and log the packet.

NOTE:

The dynamic address entry names share the same name space as legacy security address entries, so do not use the same name for more than one entry. The Junos OS commit process checks that names are not duplicated to avoid a conflict.

Dynamic address groups support the following data feeds:

Custom lists (allowlists and blocklists)
GeoIP

Feed Servers

Feed servers contain dynamic address entries in a feed file. You can create custom feeds which can be local or remote. For custom feeds creation, see, Creating Custom Feeds
Configure the SRX Series Firewall for using the feeds. See, feed-server to configure SRX Series Firewall.

Bundle Feeds

IP addresses, IP prefixes or IP ranges contained in a dynamic address entry can be updated periodically by downloading an external feed. SRX Series Firewalls periodically initiate a connection to the feed server to download and update the IP lists which contain the updated dynamic addresses.

Starting in Junos OS Release 19.3R1, you can download a single tgz file from server and extract it into multiple children feed files. Each individual file corresponds to one feed. Let individual dynamic-addresses reference the feed inside the bundle file. The bundle file reduces the CPU overhead when too many feeds are configured, where multiple child feeds are compressed into one .tgz file

The following bundle feed modes are supported:

Archive Mode

In the archive mode, you need to compress all feed files for the SRX Series Firewall into one tgz file. The SRX Series Firewall downloads this file and extract all the feeds after extraction. This process is explained below:

When the feed server's url is a url of a file with the suffix .tgz instead of original url of folder, this means this server uses a single file to carry all its feeds for SRX Series dynamic-address deployment. In this case, feeds under this server inherit the update-interval or hold-interval from the server. Any user configuration of the update-interval or hold-interval for this feed is ignored.
After this change, follow the steps below to maintain server feeds as below example.
The example below shows the steps required to maintain the server feeds:
1. Place all feed files for the SRX Series Firewall under the folder feeds-4-srx
2. Generate all feed files fd1 fd2 fd3 ..fdN in the folder feeds-4-srx
3. Add or remove the IP ranges from the feeds
4. Access the files by running the following command: cd feeds-4-srx;tar -zcvf ../feeds-4-srx.tgz *;cd-
Post Step 4, the file feeds-4-srx.tgz is ready for download on the SRX Series Firewall containing the same folder which contains the feeds-4-srx.tgz file. After the download, the extracted files are placed in the same folder as feeds-4-srx.tgz. The following example shows a samle configuration on an SRX Series Firewall:
```
[edit]
set security dynamic-address feed-server server-4-srx url 10.170.40.50/feeds-4-srx.tgz
set security dynamic-address feed-server server-4-srx feed-name feed1 path fd1
set security dynamic-address feed-server server-4-srx feed-name feed2 path fd2
set security dynamic-address feed-server server-4-srx feed-name feed3 path fdN
```

The path parameter requires the relative path of the feed inside the bundle archive.

If the tar -zxf feeds-4-srx.tgz file generates a folder feeds-4-srx and this folder holds the feed file fd1, then use the following command to configure the feed:
```
[edit]
set security dynamic-address feed-server server-4-srx feed fd1 path feeds-4-srx/fd1
```
If the tar -zxf feeds-4-srx.tgz file extracts the file fd1 directly, then use the following command to configure the feed:
```
[edit]
set security dynamic-address feed-server server-4-srx feed fd1 path fd1
```

Flat File Mode

Flat file mode offers ultimate simplicity for user by introducing one syntax change in existing feed file format. The content of all the feed files are compiled into a single file, with .bundle as a suffix. This allows you to manage a single file. The SRX Series Firewall classifies IP ranges in this bundle file into numerous feed files. You can gzip this file as .bundle.gz if you can save some bandwidth for transmission. In addition to file format defined earlier, an upper case tag FEED: followed by the feed name is introduced. The lines below this tag are regarded as IP ranges belonging to the feed. An example of the file format looks is given below:

content_copy zoom_out_map
root>cat feeds-4-srx.bundle
FEED:fd1
12.1.1.1-12.1.1.2
11.1.1.1-11.1.1.2

content_copy zoom_out_map
FEED:fd2
14.1.1.1-14.1.1.2

The configuration on an SRX Series Firewall is similar to archive mode and is given below:

content_copy zoom_out_map
[edit]
set security dynamic-address feed-server server-4-srx url 10.170.40.50/feeds-4-srx.bundle
set security dynamic-address feed-server server-4-srx feed-name fd1 path fd1
set security dynamic-address feed-server server-4-srx feed-name fd2 path fd2

The difference between flat mode and archive mode is the file’s suffix and the layout inside the file. You can select the mode that is most convenient for you.

As the feed files are in the plaintext format, gzip can reduce the file size. If a server and an SRX Series Firewall has WAN link in between, use a smaller sized file to be transmitted on the network, in this case, gzip the bundle file and configure the following commands:

content_copy zoom_out_map
[edit]
set security dynamic-address feed-server server-4-srx url 10.170.40.50/feeds-4-srx.bundle.gz
set security dynamic-address feed-server server-4-srx feed-name fd1 path fd1
set security dynamic-address feed-server server-4-srx feed-name fd2 path fd2

Feed Server Support for SRX Series Firewalls

Table 2:
Platform	Maximum Number of Feed Servers	Maximum Number of Feeds	Maximum Number of Dynamic Addresses entries
SRX300SRX320SRX340SRX345SRX550SRX550MSRX650	10	500	500
SRX4100SRX4200SRX4600SRX5400SRX5600SRX5800vSRX Virtual FirewallvSRX Virtual Firewall 3.0	100	5000	5000
SRX1500	40	2000	2000

Configure Security Policies for VXLAN

SUMMARY Use this example to configure security policies for EVPN (Ethernet VPN) Virtual Extensible LAN (VXLAN) tunnel inspection.

Requirements

VXLAN support on SRX Series Firewalls provides the flexibility to bring an enterprise grade firewall to connect end points in their campus, data center, branch and public cloud environments while providing embedded security.

This example uses the following hardware and software components:

SRX4600 device
Junos OS Release 20.4R1

Before you begin:

Make sure you understand how EVPN and VXLAN works.

Overview

The EVPN solution provides large enterprises a common framework used to manage their campus and data center networks. An EVPN-VxLAN architecture supports efficient Layer 2 and Layer 3 network connectivity with scale, simplicity, and agility. Figure 5 shows an simplified VXLAN traffic flow topology.

Topology

Figure 5: Simplified VXLAN Traffic Flow Topology

zoom_out_map

Configuration

CLI Quick Configuration

content_copy zoom_out_map
set security zones security-zone cloud-1
set security zones security-zone dc
set security tunnel-inspection inspection-profile ins-pf1 vxlan vx1 vni r1
set security tunnel-inspection inspection-profile ins-pf1 vxlan vx1 vni r2
set security tunnel-inspection inspection-profile ins-pf1 vxlan vx1 vni r3
set security tunnel-inspection inspection-profile ins-pf1 vxlan vx1 vni r4
set security tunnel-inspection inspection-profile ins-pf1 vxlan vx1 policy-set pset1
set security tunnel-inspection vni r1 vni-range 160 to 200
set security tunnel-inspection vni r2 vni-id 155
set security tunnel-inspection vni r3 vni-range 300 to 399
set security tunnel-inspection vni r4 vni-range 100 to 120
set security tunnel-inspection vni v1 vni-range 1 to 100
set security policies from-zone dc to-zone cloud-1 policy p1 match source-address any
set security policies from-zone dc to-zone cloud-1 policy p1 match destination-address any
set security policies from-zone dc to-zone cloud-1 policy p1 match application junos-vxlan
set security policies from-zone dc to-zone cloud-1 policy p1 then permit tunnel-inspection ins-pf1
set security policies from-zone cloud-1 to-zone dc policy p1 match source-address any
set security policies from-zone cloud-1 to-zone dc policy p1 match destination-address any
set security policies from-zone cloud-1 to-zone dc policy p1 match application junos-vxlan
set security policies from-zone cloud-1 to-zone dc policy p1 then permit tunnel-inspection ins-pf1
set security policies policy-set pset1 policy pset_p1 match source-address any
set security policies policy-set pset1 policy pset_p1 match destination-address any
set security policies policy-set pset1 policy pset_p1 match application any
set security policies policy-set pset1 policy pset_p1 then permit
set security policies default-policy deny-all
Show more 

Procedure

Step-by-Step Procedure

To configure VXLAN:

Define Security Zones.

content_copy zoom_out_map
[edit security zones]
user@host# set security-zone cloud-1
user@host# set zones security-zone dc

Define tunnel-inspection profile.

content_copy zoom_out_map
[edit security tunnel-inspection]
user@host# set inspection-profile ins-pf1 vxlan vx1 vni r1
user@host# set inspection-profile ins-pf1 vxlan vx1 vni r2
user@host# set inspection-profile ins-pf1 vxlan vx1 vni r3
user@host# set inspection-profile ins-pf1 vxlan vx1 vni r4
user@host# set inspection-profile ins-pf1 vxlan vx1 policy-set pset1
user@host# set vni r1 vni-range 160 to 200
user@host# set vni r2 vni-id 155
user@host# set vni r3 vni-range 300 to 399
user@host# set vni r4 vni-range 100 to 120
user@host# set vni v1 vni-range 1 to 100

Define outer session policies.

content_copy zoom_out_map
[edit security policies]
user@host# set from-zone dc to-zone cloud-1 policy p1 match source-address any
user@host# set from-zone dc to-zone cloud-1 policy p1 match destination-address any
user@host# set from-zone dc to-zone cloud-1 policy p1 match application junos-vxlan
user@host# set from-zone dc to-zone cloud-1 policy p1 then permit tunnel-inspection profile-1
user@host# set from-zone cloud-1 to-zone dc policy p1 match source-address any
user@host# set from-zone cloud-1 to-zone dc policy p1 match destination-address any
user@host# set from-zone cloud-1 to-zone dc policy p1 match application junos-vxlan
user@host# set from-zone cloud-1 to-zone dc policy p1 then permit tunnel-inspection ins-pf1

Define policy-set.

content_copy zoom_out_map
[edit security policies]
user@host# set policy-set pset1 policy pset_p1 match source-address any
user@host# set policy-set pset1 policy pset_p1  destination-address any
user@host# set policy-set pset1 policy pset_p1  match application any
user@host# set policy-set pset1 policy pset_p1 then permit
user@host# set default-policy deny-all

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

content_copy zoom_out_map
user@host# show security policies

content_copy zoom_out_map
from-zone dc to-zone cloud-1 {
    policy p1 {
        match {
            source-address any;
            destination-address any;
            application junos-vxlan;
        }
        then {
            permit {
                tunnel-inspection {
                    ins-pf1;
                }
            }
        }
    }
}
from-zone cloud-1 to-zone dc {
    policy p1 {
        match {
            source-address any;
            destination-address any;
            application junos-vxlan;
        }
        then {
            permit {
                tunnel-inspection {
                    ins-pf1;
                }
            }
        }
    }
}
policy-set pset1 {
    policy pset_p1 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
default-policy {
    deny-all;
}
Show more 

If you are done configuring the feature on your device, enter commit from configuration mode.

Verification

Verify tunnel inspection profiles and VNI

Purpose

Verify that the tunnel inpection profile and VNI are confugured..

Action

From operational mode, enter the show security tunnel-inspection profiles ins-pf1 and show security tunnel-inspection vnis commands.

content_copy zoom_out_map
user@host> show security tunnel-inspection profiles ins-pf1
node0:
--------------------------------------------------------------------------
Logical system: root-logical-system
  Profile count: 1
  Profile: ins-pf1
    Type: VXLAN
    Vxlan count: 1
    Vxlan name: vx1
    VNI count: 4
      VNI:r1, r2, r3, r4
      Policy set: pset1
      Inspection level: 1

content_copy zoom_out_map
user@host> show security tunnel-inspection vnis
node0:
--------------------------------------------------------------------------
Logical system: root-logical-system
  VNI count: 5
  VNI name: r1
      VNI id count: 1
      [160 - 200] 
  VNI name: r2
      VNI id count: 1
      [155 - 155] 
  VNI name: r3
      VNI id count: 1
      [300 - 399] 
  VNI name: r4
      VNI id count: 1
      [100 - 120] 
  VNI name: v1
      VNI id count: 1
      [1 - 100]
Show more 

Meaning

The output displays that the VXLAN feature is enabled and there are no safe search redirects and safe search rewrites.

Verify Safe Search Function

Purpose

Verify that the safe search feature is enabled for Content Security Web filtering solutions.

Action

From operational mode, enter the Show security flow tunnel-inspection statistic command to view the tunnel-inspection statistics.

content_copy zoom_out_map
user@host> show security flow tunnel-inspection statistics
node0:
--------------------------------------------------------------------------
 
  Flow Tunnel-inspection statistics:
  Tunnel-inspection statistics of FPC4 PIC1:
  Tunnel-inspection type VXLAN:
    overlay session active:             0
    overlay session create:           269
    overlay session close:            269
    underlay session active:            0
    underlay session create:          566
    underlay session close:           566
    input packets:       349717
    input bytes:      363418345
    output packets:      348701
    output bytes:     363226339
    bypass packets:         501
    bypass bytes:         50890
 
  Tunnel-inspection statistics of FPC4 PIC2:
  Tunnel-inspection type VXLAN:
    overlay session active:             0
    overlay session create:           270
    overlay session close:            270
    underlay session active:            0
    underlay session create:          586
    underlay session close:           586
    input packets:       194151
    input bytes:      200171306
    output packets:      193221
    output bytes:     199987258
    bypass packets:         617
    bypass bytes:         92902
 
  Tunnel-inspection statistics of FPC4 PIC3:
  Tunnel-inspection type VXLAN:
    overlay session active:             0
    overlay session create:           275
    overlay session close:            275
    underlay session active:            0
    underlay session create:          615
    underlay session close:           615
    input packets:       216486        
    input bytes:      222875066
    output packets:      213827
    output bytes:     222460378
    bypass packets:        2038
    bypass bytes:        270480
 
  Tunnel-inspection statistics summary:
  Tunnel-inspection type VXLAN:
    overlay session active:             0
    overlay session create:           814
    overlay session close:            814
    underlay session active:            0
    underlay session create:         1767
    underlay session close:          1767
    input packets:       760354
    input bytes:      786464717
    output packets:      755749
    output bytes:     785673975
    bypass packets:        3156
    bypass bytes:        414272
 
node1:
--------------------------------------------------------------------------
 
  Flow Tunnel-inspection statistics:
  Tunnel-inspection statistics of FPC4 PIC1:
  Tunnel-inspection type VXLAN:
    overlay session active:             0
    overlay session create:           269
    overlay session close:            269
    underlay session active:            0
    underlay session create:          566
    underlay session close:           566
    input packets:            0
    input bytes:              0
    output packets:           0
    output bytes:             0
    bypass packets:           0
    bypass bytes:             0
 
  Tunnel-inspection statistics of FPC4 PIC2:
  Tunnel-inspection type VXLAN:        
    overlay session active:             0
    overlay session create:           270
    overlay session close:            270
    underlay session active:            0
    underlay session create:          586
    underlay session close:           586
    input packets:            0
    input bytes:              0
    output packets:           0
    output bytes:             0
    bypass packets:           0
    bypass bytes:             0
 
  Tunnel-inspection statistics of FPC4 PIC3:
  Tunnel-inspection type VXLAN:
    overlay session active:             0
    overlay session create:           275
    overlay session close:            275
    underlay session active:            0
    underlay session create:          615
    underlay session close:           615
    input packets:            0
    input bytes:              0
    output packets:           0
    output bytes:             0
    bypass packets:           0
    bypass bytes:             0
 
  Tunnel-inspection statistics summary:
  Tunnel-inspection type VXLAN:
    overlay session active:             0
    overlay session create:           814
    overlay session close:            814
    underlay session active:            0
    underlay session create:         1767
    underlay session close:          1767
    input packets:            0
    input bytes:              0
    output packets:           0
    output bytes:             0
    bypass packets:           0
    bypass bytes:             0    
Show more 

Meaning

The output displays that the VXLAN feature is enabled and there are no safe search redirects and safe search rewrites.

Enable Security Policies for Geneve Packet Flow Tunnel Inspection

SUMMARY Use this configuration to enable security policies on vSRX Virtual Firewall 3.0 for Geneve packet flow tunnel inspection.

With Geneve support on vSRX Virtual Firewall 3.0 instances, you can use vSRX3.0 to:

Connect end points in a campus, data center, and public cloud environments and their banches.
Secure these environments with embedded security.

Requirements

This example uses the following hardware and software components:

vSRX Virtual Firewall 3.0
Junos OS Release 23.1R1

Before you begin:

Make sure you understand how the Geneve protocol works.

Overview

Geneve flow support on vSRX Virtual Firewall 3.0 instances provides large enterprises a common framework to manage their campus and data center networks. The Geneve-based architecture supports efficient Layer 3 (L3) and Layer 4 (L4) network connectivity by ensuring scalability, simplicity, and agility.

Using this configuration you can:

Enable the security policies to process the Geneve tunnel encapsulated L3 packets.
Create distinct profiles for Geneve traffic based on VNI and vendor TLV attributes-Policy once attached with an inspection profile dictates the type of Geneve traffic to be processed and policies to be applied to the inner traffic.
Configure the regular security policy on vSRX Virtual Firewall 3.0 to apply L4 and L7 services on the inner traffic.

Configuration (vSRX Virtual Firewall 3.0 as Tunnel Endpoint)

Simplified Geneve Traffic Flow Topology with AWS GWLB and vSRX Virtual Firewall 3.0 as Tunnel End-point

Figure 6: AWS GWLB and vSRX Virtual Firewall 3.0 as Tunnel End-point

zoom_out_map

CLI Quick Configuration

NOTE:

Define a trust and untrust zone to permit all host traffic.

content_copy zoom_out_map
set security tunnel-inspection inspection-profile ti-vendor geneve g-rule policy-set ps-vendor
set security tunnel-inspection inspection-profile ti-vendor geneve g-rule vni vni-vendor
set security tunnel-inspection vni vni-vendor vni-id 0

set security policies from-zone vtepc to-zone junos-host policy self match application junos-geneve
set security policies from-zone vtepc to-zone junos-host policy self match source-address any
set security policies from-zone vtepc to-zone junos-host policy self match destination-address any
set security policies from-zone vtepc to-zone junos-host policy self then permit tunnel-inspection ti-vendor
set security policies default-policy deny-all
set security policies policy-set ps-vendor policy self match source-address any
set security policies policy-set ps-vendor policy self match destination-address any
set security policies policy-set ps-vendor policy self match application any
set security policies policy-set ps-vendor policy self then permit
set interfaces ge-0/0/1 mtu 9000
set interfaces ge-0/0/1 unit 0 family inet address any
set interfaces ge-0/0/1 unit 0 family inet6 address any
Show more 

Procedure

Step-by-Step Procedure

To configure Geneve flow support for tunnel inspection on vSRX Virtual Firewall 3.0:

Define a trust and untrust zone to permit all host traffic under the [edit security zones] hierarchy.

Define the tunnel-inspection profile.

content_copy zoom_out_map
[edit security tunnel-inspection]
user@host# set security tunnel-inspection inspection-profile ti-vendor geneve g-rule policy-set ps-vendor

user@host# set security tunnel-inspection inspection-profile ti-vendor geneve g-rule vni vni-vendor

user@host# set security tunnel-inspection vni vni-vendor vni-id 0

Define outer session policies to the outer packets and attach the referenced tunnel inspection profile

NOTE:

In the policy configuration, the to-zone for the outer policy in case of vSRX Virtual Firewall 3.0 as tunnel endpoint must be junos-host, which is an inbuilt (reserved identifier) zone to process traffic.

content_copy zoom_out_map
[edit security policies]
user@host# set security policies from-zone vtepc to-zone junos-host policy self match source-address any
user@host# set security policies from-zone vtepc to-zone junos-host policy self match destination-address any
user@host# set security policies from-zone vtepc to-zone junos-host policy self match application junos-geneve
user@host# set security policies from-zone vtepc to-zone junos-host policy self then permit tunnel-inspection ti-vendor
user@host# set security policies default-policy deny-all

Define an inner policy under policy-set to process the decapsulated packet.

content_copy zoom_out_map
[edit security policies]
user@host# set security policies policy-set ps-vendor policy self match source-address any
user@host# set security policies policy-set ps-vendor policy self match destination-address any
user@host# set security policies policy-set ps-vendor policy self match application any
user@host# set security policies policy-set ps-vendor policy self then permit

Configure the interface associated with from-zone of the virtual tunnel endpoint client (VTEPC) to receive the Geneve-encapsulated packets and the health-check packets.
```
[edit]
user@host# set interfaces ge-0/0/1 mtu 9000
user@host# set interfaces ge-0/0/1 unit 0 family inet address any
user@host# set interfaces ge-0/0/1 unit 0 family inet6 address any
```

Results

From the configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

content_copy zoom_out_map
user@host# show security policies

content_copy zoom_out_map
from-zone trust to-zone untrust {
    policy p1 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit {
                application-services {
                    application-traffic-control {
                        rule-set ftp-test1;
                    }
                }
            }
        }
    }
    policy internet-access {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone untrust to-zone trust {
    policy dst-nat-pool-access {
        match {
            source-address any;
            destination-address 233.252.0.1/21;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone vtepc to-zone junos-host {
    policy self {
        match {
            source-address any;
            destination-address any;
            application junos-geneve;
        }
        then {
            permit {
                tunnel-inspection {
                    ti-vendor;
                }
            }
        }
    }
}
policy-set ps-vendor {
    policy self {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
default-policy {
    deny-all;
}
Show more 

content_copy zoom_out_map
user@host# show security tunnel-inspection

content_copy zoom_out_map
inspection-profile ti-vendor {
    geneve g-rule {
        policy-set ps-vendor;
        vni vni-vendor;
    }
}
vni v1 {
    vni-id 0;
}
vni vni-vendor {
    vni-id 0;
}

After you complete configuring the feature on your device, enter commit from the configuration mode.

Verify Tunnel Inspection Profile and VNI

Purpose

Verify that you have configured the tunnel-inspection profile and the VXLAN network identifier (VNI).

Action

From operational mode, enter the show security tunnel-inspection profiles ti-vendor and show security tunnel-inspection vnis commands.

content_copy zoom_out_map
user@host> show security tunnel-inspection profiles ti-vendor
--------------------------------------------------------------------------
Logical system: root-logical-system
  Profile count: 1
  Profile: ti-vendor
    Type: Geneve
    geneve count: 1
    geneve name: g-rule
    VNI count: 1
      VNI: vni-vendor
      Policy set: ps-vendor 
      Inspection level: 1

content_copy zoom_out_map
user@host> show security tunnel-inspection vnis
--------------------------------------------------------------------------
Logical system: root-logical-system
  VNI count: 1
  VNI name: vni-vendor
      VNI id count: 0

Meaning

The output displays that the Geneve tunnel-inspection profile is enabled and the VXLAN network identifier (VNI) is configured.

Verify Tunnel Inspection Profile and VNI

Purpose

Verify that you have configured the tunnel-inspection profile and the VXLAN network identifier (VNI).

Action

From operational mode, enter the show security tunnel-inspection profiles ti-vendor and show security tunnel-inspection vnis commands.

content_copy zoom_out_map
user@host> show security tunnel-inspection profiles ti-vendor
--------------------------------------------------------------------------
Logical system: root-logical-system
  Profile count: 1
  Profile: ti-vendor
    Type: Geneve
    geneve count: 1
    geneve name: g-rule
    VNI count: 1
      VNI: vni-vendor
      Policy set: ps-vendor 
      Inspection level: 1

content_copy zoom_out_map
user@host> show security tunnel-inspection vnis
--------------------------------------------------------------------------
Logical system: root-logical-system
  VNI count: 1
  VNI name: vni-vendor
      VNI id count: 0

Meaning

The output displays that the Geneve tunnel-inspection profile is enabled and the VXLAN network identifier (VNI) is configured.

Configuration (vSRX Virtual Firewall 3.0 as Transit Router)

Simplified Geneve Traffic Flow Topology vSRX Virtual Firewall 3.0 as Transit Router

In this deployment mode the virtual tunnel endpoint client (vtepc) (Geneve tunnel endpoint) must ensure that packets destined to both the client and the server pass through virtual tunnel endpoint server (vteps) (vSRX Virtual Firewall 3.0). The source port is selected by the virtual tunnel endpoint (vtep).

Figure 7: Simplified Topology of vSRX Virtual Firewall 3.0 as Transit Router

zoom_out_map

CLI Quick Configuration

content_copy zoom_out_map
set security tunnel-inspection vni r1 vni-range 1 to 100
set security tunnel-inspection vni r1 vni-id 500
set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve1 vni r1
set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve1 policy-set pset1
set security tunnel-inspection vni r2 vni-range 200 to 400
set security tunnel-inspection vni r2 vni-id 500
set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve2 vni r2
set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve2 policy-set pset2
set security policies from-zone vtepc to-zone vteps policy p1 match application junos-geneve

set security policies from-zone vtepc to-zone vteps policy p1 match source-address any

set security policies from-zone vtepc to-zone vteps policy p1 match destination-address any

set security policies from-zone vtepc to-zone vteps policy p1 then permit tunnel-inspection ti-vendor

set security policies from-zone vteps to-zone vtepc policy p1 match application junos-geneve

set security policies from-zone vteps to-zone vtepc policy p1 match source-address any

set security policies from-zone vteps to-zone vtepc policy p1 match destination-address any

set security policies from-zone vteps to-zone vtepc policy p1 then permit tunnel-inspection ti-vendor

set security policies default-policy deny-all

set security policies policy-set pset1 policy pset_p1 match source-address any
set security policies policy-set pset1 policy pset_p1 match destination-address any
set security policies policy-set pset1 policy pset_p1 match application any
set security policies policy-set pset1 policy pset_p1 then permit
set interfaces ge-0/0/1 mtu 9000
set interfaces ge-0/0/1 unit 0 family inet address any

set interfaces ge-0/0/1 unit 0 family inet6 address any
Show more 

Procedure

Step-by-Step Procedure

To configure Geneve flow support for tunnel inspection on vSRX Virtual Firewall 3.0 (vSRX Virtual Firewall 3.0 as transit router) :

Define a trust and untrust zone to permit all host traffic under the [edit security zones] hierarchy.

Define the tunnel-inspection profile.

content_copy zoom_out_map
[edit security tunnel-inspection]
user@host# set security tunnel-inspection vni r1 vni-range 1 to 100
user@host# set security tunnel-inspection vni r1 vni-id 500
user@host# set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve1 vni r1
user@host# set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve1 policy-set pset1
user@host# set security tunnel-inspection vni r2 vni-range 200 to 400
user@host# set security tunnel-inspection vni r2 vni-id 500
user@host# set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve2 vni r2
user@host# set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve2 policy-set pset2

Define outer session policies.

NOTE:

For vSRX Virtual Firewall 3.0 as transit router, you need two policies in each direction. The from-zone and to-zone are the respective zones that must be defined under the interfaces.

content_copy zoom_out_map
[edit security policies]
user@host# set security policies from-zone vtepc to-zone vteps policy p1 match source-address any
user@host# set security policies from-zone vtepc to-zone vteps policy p1 match destination-address any
user@host# set security policies from-zone vtepc to-zone vteps policy p1 match application junos-geneve
user@host# set security policies from-zone vtepc to-zone vteps policy p1 then permit tunnel-inspection ti-vendor
user@host# set security policies from-zone vteps to-zone vtepc policy p1 match application junos-geneve
user@host# set security policies from-zone vteps to-zone vtepc policy p1 match source-address any
user@host# set security policies from-zone vteps to-zone vtepc policy p1 match destination-address any
user@host# set security policies from-zone vteps to-zone vtepc policy p1 then permit tunnel-inspection ti-vendor
user@host#set security policies default-policy deny-all

Define an inner policy under policy-set to process the decapsulated packet.

content_copy zoom_out_map
[edit security policies]
user@host# set security policies policy-set pset1 policy pset_p1 match source-address any
user@host# set security policies policy-set pset1 policy pset_p1 match destination-address any
user@host# set security policies policy-set pset1 policy pset_p1 match application any
user@host# set security policies policy-set pset1 policy pset_p1 then permit

Configure the interface associated with from-zone of the virtual tunnel endpoint client (VTEPC) to receive the Geneve-encapsulated packets and the health-check packets.
NOTE:
In case of transit mode, vSRX Virtual Firewall 3.0 must be configured with two L3 interfaces for ingress and egress.
```
[edit]
user@host# set interfaces ge-0/0/1 mtu 9000
user@host# set interfaces ge-0/0/1 unit 0 family inet address any
user@host# set interfaces ge-0/0/1 unit 0 family inet6 address any
```

Results

content_copy zoom_out_map
user@host# show security policies

content_copy zoom_out_map
from-zone trust to-zone untrust {
    policy p1 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit {
                application-services {
                    application-traffic-control {
                        rule-set ftp-test1;
                    }
                }
            }
        }
    }
}
from-zone vtepc to-zone vteps {
        policy p1 {
        match {
            source-address any;
            destination-address any;
            application junos-geneve;
        }
        then {
            permit {
                tunnel-inspection {
                  ti-vendor;
                }
            }
        }
    }
}
from-zone vteps to-zone vtepc {
     policy p1 {
        match {
            source-address any;
            destination-address any;
            application junos-geneve;
        }
        then {
            permit {
                tunnel-inspection {
                   ti-vendor;
                }
            }
        }
    }
}
policy-set pset1 {
    policy pset_p1 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
default-policy {
    deny-all;
}}
Show more 

content_copy zoom_out_map
user@host# show security tunnel-inspection

content_copy zoom_out_map
inspection-profile ti-vendor {
    geneve g-rule {
        policy-set ps-vendor;
        vni vni-vendor;
    }
}
inspection-profile pro1;
vni r1 {
    vni-id 500;
}
vni r2 {
    vni-id 500;
}
}
Show more 

After you complete configuring the feature on your device, enter commit from the configuration mode.

Sunday, 1 December 2024

Junos OS Evolved Overview

Friday, 1 November 2024

Configuring Security Policies

Understanding Security Policy Elements

Understanding Security Policy Rules

Understanding Wildcard Addresses

SEE ALSO

Understanding Security Policies for Self Traffic

Security Policies Configuration Overview

SEE ALSO

Best Practices for Defining Policies on SRX Series Devices

SEE ALSO

Configuring Policies Using the Firewall Wizard

Example: Configuring a Security Policy to Permit or Deny All Traffic

Requirements

Overview

Topology

Configuration

Procedure

CLI Quick Configuration

Step-by-Step Procedure

Results

Verification

Verifying Policy Configuration

Purpose

Action

Meaning

Example: Configuring a Security Policy to Permit or Deny Selected Traffic

Requirements

Overview

Configuration

Procedure

CLI Quick Configuration

Step-by-Step Procedure

Results

Verification

Verifying Policy Configuration

Purpose

Action

Meaning

Example: Configuring a Security Policy to Permit or Deny Wildcard Address Traffic

Requirements

Overview

Configuration

Procedure

CLI Quick Configuration

Step-by-Step Procedure

Results

Verification

Verifying Policy Configuration

Purpose

Action

Meaning

Example: Configuring a Security Policy to Redirect Traffic Logs to an External System Log Server

Requirements

Overview

Configuration

Procedure

CLI Quick Configuration

Step-by-Step Procedure

Results

Verification

Verifying Zones

Purpose

Action

Verifying Policies

Purpose

Action

TAP Mode for Security Zones and Policies

Understanding TAP Mode Support for Security Zones and Policies

Example: Configuring Security Zones and Policies in TAP mode

Requirements

Overview

Configuration

CLI Quick Configuration

Procedure

Step-by-Step Procedure

Results

Verification