Junos OS runs on the following Juniper Network's ® products: ACX Series, cRPD, cSRX, EX Series, JRR Series, Juniper Secure Connect, MX Series, NFX Series, QFX Series, SRX Series, vMX, vRR, and vSRX. These release notes accompany Junos OS Release 23.2R1. They describe new and updated features, limitations, open and resolved problems in the hardware and software.
You can find release notes for all Junos OS releases at https://www.juniper.net/documentation/product/us/en/junos-os#cat=release_notes.
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.
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.
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.
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_
Application names cannot begin with the junos_ reserved prefix.
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.
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.
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.
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.
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.
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.
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:
Configure>Tasks>Configure FW Policy in the J-Web interface.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.
This example shows how to configure a security policy to permit or deny all traffic.
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.
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.
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.
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
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
Create the security policy to permit traffic from the trust zone to the untrust zone.
[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.
[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
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.
Verify information about security policies.
From operational mode, enter the show security policies detail command to display a summary of all security policies configured on the device.
The output displays information about policies configured on the system. Verify the following information:
From and to zones
Source and destination addresses
Match criteria
This example shows how to configure a security policy to permit or deny selected traffic.
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.
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.
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
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
Create address book entries for both the client and the server. Also, attach security zones to the address books.
[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
Define the policy to permit mail traffic.
[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
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.
Verify information about security policies.
From operational mode, enter the show security policies detail command to display a summary of all security policies configured on the device.
The output displays information about policies configured on the system. Verify the following information:
From and to zones
Source and destination addresses
Match criteria
This example shows how to configure a security policy to permit or deny wildcard address traffic.
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
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.
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
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
Create an address book entry for the host and attach the address book to a zone.
[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.
[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
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 zonessecurity-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-bookbook1 { 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.
Verify information about security policies.
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.
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
This example shows how to configure a security policy to send traffic logs generated on the device to an external system log server.
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.
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.
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
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.
[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.
[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.
[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.
[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
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.
Confirm that the configuration is working properly.
Verify that the security zone is enabled or not.
From operational mode, enter the show security zones command.
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.
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.
This example shows how to configure security zones, and policies when the SRX Series Firewall is configured in TAP (Terminal Access Point) mode.
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.
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.
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
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
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.
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
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.
To confirm that the configuration is working properly, perform these tasks:
Verify information about security policies.
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
Displays a summary of all security policies configured on the device in TAP mode.
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.
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.
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 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.
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:
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:
Place all feed files for the SRX Series Firewall under the folder feeds-4-srx
Generate all feed files fd1 fd2 fd3 ..fdN in the folder feeds-4-srx
Add or remove the IP ranges from the feeds
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.tgzset security dynamic-address feed-server server-4-srx feed-name feed1 path fd1set security dynamic-address feed-server server-4-srx feed-name feed2 path fd2set 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 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.bundleFEED:fd112.1.1.1-12.1.1.211.1.1.1-11.1.1.2
FEED:fd214.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.bundleset security dynamic-address feed-server server-4-srx feed-name fd1 path fd1set 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.gzset security dynamic-address feed-server server-4-srx feed-name fd1 path fd1set security dynamic-address feed-server server-4-srx feed-name fd2 path fd2
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 |
SUMMARY Use this example to configure security policies for EVPN (Ethernet VPN) Virtual Extensible LAN (VXLAN) tunnel inspection.
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.
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.
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
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
Define tunnel-inspection profile.
[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.
[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.
[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
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 {
deny-all;
}
If you are done configuring the feature on your device, enter commit from configuration mode.
Verify that the tunnel inpection profile and VNI are confugured..
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: 1user@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]The output displays that the VXLAN feature is enabled and there are no safe search redirects and safe search rewrites.
Verify that the safe search feature is enabled for Content Security Web filtering solutions.
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 The output displays that the VXLAN feature is enabled and there are no safe search redirects and safe search rewrites.
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.
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.
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.
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.
Define a trust and untrust zone to permit all host traffic.
set security tunnel-inspection inspection-profile ti-vendor geneve g-rule policy-set ps-vendorset security tunnel-inspection inspection-profile ti-vendor geneve g-rule vni vni-vendorset security tunnel-inspection vni vni-vendor vni-id 0set security policies from-zone vtepc to-zone junos-host policy self match application junos-geneveset security policies from-zone vtepc to-zone junos-host policy self match source-address anyset security policies from-zone vtepc to-zone junos-host policy self match destination-address anyset security policies from-zone vtepc to-zone junos-host policy self then permit tunnel-inspection ti-vendorset security policies default-policy deny-allset security policies policy-set ps-vendor policy self match source-address anyset security policies policy-set ps-vendor policy self match destination-address anyset security policies policy-set ps-vendor policy self match application anyset security policies policy-set ps-vendor policy self then permitset interfaces ge-0/0/1 mtu 9000set interfaces ge-0/0/1 unit 0 family inet address anyset interfaces ge-0/0/1 unit 0 family inet6 address any
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 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.
[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
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.
[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.
[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
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.
user@host# show security policies
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;
}user@host# show security tunnel-inspection
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 that you have configured the tunnel-inspection profile and the VXLAN network identifier (VNI).
From operational mode, enter the show security tunnel-inspection profiles ti-vendor and show security tunnel-inspection vnis commands.
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: 1user@host> show security tunnel-inspection vnis
--------------------------------------------------------------------------
Logical system: root-logical-system
VNI count: 1
VNI name: vni-vendor
VNI id count: 0The output displays that the Geneve tunnel-inspection profile is enabled and the VXLAN network identifier (VNI) is configured.
Verify that you have configured the tunnel-inspection profile and the VXLAN network identifier (VNI).
From operational mode, enter the show security tunnel-inspection profiles ti-vendor and show security tunnel-inspection vnis commands.
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: 1user@host> show security tunnel-inspection vnis
--------------------------------------------------------------------------
Logical system: root-logical-system
VNI count: 1
VNI name: vni-vendor
VNI id count: 0The output displays that the Geneve tunnel-inspection profile is enabled and the VXLAN network identifier (VNI) is configured.
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).
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 tunnel-inspection vni r1 vni-range 1 to 100set security tunnel-inspection vni r1 vni-id 500set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve1 vni r1set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve1 policy-set pset1set security tunnel-inspection vni r2 vni-range 200 to 400set security tunnel-inspection vni r2 vni-id 500set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve2 vni r2set security tunnel-inspection profile inspection-profile ti-vendor geneve geneve2 policy-set pset2set security policies from-zone vtepc to-zone vteps policy p1 match application junos-geneveset security policies from-zone vtepc to-zone vteps policy p1 match source-address anyset security policies from-zone vtepc to-zone vteps policy p1 match destination-address anyset security policies from-zone vtepc to-zone vteps policy p1 then permit tunnel-inspection ti-vendorset security policies from-zone vteps to-zone vtepc policy p1 match application junos-geneveset security policies from-zone vteps to-zone vtepc policy p1 match source-address anyset security policies from-zone vteps to-zone vtepc policy p1 match destination-address anyset security policies from-zone vteps to-zone vtepc policy p1 then permit tunnel-inspection ti-vendorset security policies default-policy deny-allset security policies policy-set pset1 policy pset_p1 match source-address anyset security policies policy-set pset1 policy pset_p1 match destination-address anyset security policies policy-set pset1 policy pset_p1 match application anyset security policies policy-set pset1 policy pset_p1 then permitset interfaces ge-0/0/1 mtu 9000set interfaces ge-0/0/1 unit 0 family inet address anyset interfaces ge-0/0/1 unit 0 family inet6 address any
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 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.
[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.
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.
[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.
[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.
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
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.
user@host# show security policies
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;
}}user@host# show security tunnel-inspection
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;
}
}After you complete configuring the feature on your device, enter commit from the configuration mode.