Configuring Security Policies

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 Number_of_dst_IPv4_addresses + number_of_dst_IPv6_addresses * 4

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

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.

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.

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_

  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.

  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 .

  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.

  See Also

  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.

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

  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.

  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:

  1. Create zones. See Example: Creating Security Zones.
  2. Configure an address book with addresses for the policy. See Example: Configuring Address Books and Address Sets.
  3. 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.
  4. 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.
  5. 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.

  See Also

  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.

  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

  Policy contexts (zone pairs)

  Policies per context

  Policies with counting enabled

  SRX5400 SRX5600 SRX5800

  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

    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.

    See Also

    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:

    1. Select Configure>Tasks>Configure FW Policy in the J-Web interface.
    2. Click the Launch Firewall Policy Wizard button to launch the wizard.
    3. 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
    • Step-by-Step Procedure
    • Results

    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.

    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.

    [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 

    [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 

    [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.

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

    [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; >> >

    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; >> > > >

    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
    • Step-by-Step Procedure
    • Results

    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.

    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.

    [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 

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

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

    [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

    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.

    [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; >> >

    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 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
    • Step-by-Step Procedure
    • Results

    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 in configuration mode.

    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.

    [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 

    [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 

    [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

    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.

    [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; >> >

    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; >>

    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.

    Configuration

    Procedure

    • CLI Quick Configuration
    • Step-by-Step Procedure
    • Results

    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 in configuration mode.

    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 

    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 

    [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 

    [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 

    [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 

    [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.

    [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
    • Example: Configuring Security Zones and Policies in TAP mode

    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.

    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
    • Procedure
    • Results

    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.

    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.

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

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

    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.

    [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; >> > >

    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.

    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

    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.

    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

    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.

    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
    • Bundle Feeds
    • Feed Server Support for SRX Series Firewalls

    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

    [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:

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

    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:

    [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:

    [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

    Maximum Number of Feed Servers

    Maximum Number of Feeds

    Maximum Number of Dynamic Addresses entries

    SRX300 SRX320 SRX340 SRX345 SRX550 SRX550M SRX650

    SRX4100 SRX4200 SRX4600 SRX5400 SRX5600 SRX5800 vSRX Virtual Firewall vSRX Virtual Firewall 3.0

    See Also

    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

    

    Configuration

    • CLI Quick Configuration
    • Procedure
    • Results

    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.

    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 

    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 VXLAN:

    Define Security Zones.

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

    [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 

    [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 

    [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.

    user@host# show security policies

    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

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

    Verification

    • Verify tunnel inspection profiles and VNI
    • Verify Safe Search Function

    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.

    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

    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]

    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.

    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

    Meaning

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