Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

New and Changed Features

 

This section describes new features and enhancements to existing features in Junos OS Release 18.2 for vSRX.

Release 18.2R3 New and Changed Features

There are no new features or enhancements to existing features for vSRX in Junos OS Release 18.2R3.

Release 18.2R2 New and Changed Features

There are no new features or enhancements to existing features for vSRX in Junos OS Release 18.2R2.

Release 18.2R1 New and Changed Features

This section describes new features and enhancements to existing features in Junos OS Release 18.2R1 for vSRX.

Application Security

  • Advanced policy-based routing (APBR) policy (SRX Series, vSRX Instances)—Starting in Junos OS Release 18.2R1, this feature introduces configuration of SLA (Service Level Agreement) policy for advanced policy-based routing (APBR). The SLA policy can be used to achieve the required match criteria (source address, destination address and applications). After successful match, the APBR profile configured with SLA policy will be used for the session. APBR profile will continue to be used for matching the dynamic application rule. APBR can now be applied as security service at security policy-level. These enhancements provides more flexible traffic-handling capabilities that offer granular control for forwarding packets.

    [See Advanced Policy-Based Routing.]

  • Application firewall support with unified policy (SRX Series, vSRX instances) —Starting in Junos OS Release 18.2R1, unified policies are now supported on SRX Series devices and vSRX instances, allowing granular control and enforcement of Layer 7 dynamic applications within the traditional security policy.

    Unified policies leverage the application identity information determined from AppID, to make an informed decision to permit, deny, reject, or redirect the traffic.

    Starting in Junos OS Release 18.2R1, the Application Firewall (AppFW) functionality is deprecated— rather than immediately removed—to provide backward compatibility and a chance to bring your configuration into compliance with the new configuration.

    As a part of this change, the [edit security application-firewall] hierarchy and all the configuration options under this hierarchy are deprecated.

    If you configure a traditional security policy (with 5-tuple matching condition or dynamic-application configured as none) and a unified policy (with 6-tuple matching condition), the traditional security policy matches the traffic first, before the unified policy.

    If you configure a unified policy with a dynamic application as one of the matching conditions, then the configuration eliminates the additional steps involved in AppFW configuration—that is, configuring a security policy to invoke the application firewall service. The unified policy configuration handles all AppFW functionality and simplifies the task of configuring firewall policy to permit or block application traffic from the network.

  • Application Identification support for unified policy (SRX Series, vSRX instances) — Starting in Junos OS Release 18.2R1, unified policies are now supported on SRX Series devices and vSRX instances, allowing granular control and enforcement of dynamic Layer 7 applications within the traditional security policy.

    Unified policies are security policies in which you can use dynamic applications as match conditions along with existing 5-tuple or 6-tuple matching conditions (with user firewall) to detect application changes time. The use of unified policies enable you to enforce a set of rules for the transit traffic.

    In unified policy configuration, you can define dynamic application as a match condition; and the policy leverages the application identity information determined from the Application Identification (AppID) functionality. AppID provides the information such as dynamic application classification, default protocol and port of an application, and whether an application is part of the dependent list of another application, which you can use to implement the unified policy.

    After a particular application is identified, an action such as permitting, denying, rejecting, or redirecting the traffic is performed in accordance with the policy rules configured on the device.

  • Application Quality of Service (AppQoS) for unified policy (SRX Series, vSRX instances) —Starting in Junos OS Release 18.2R1, Unified Policies are now supported on SRX Series devices, allowing granular control and enforcement of dynamic Layer 7 applications within the traditional security policy.

    AppQoS feature expands the capability of Junos OS class of service (CoS) to include marking DSCP values based on Layer 7 application types, honoring application-based traffic through loss priority settings, and controlling transfer rates on egress PICs based on Layer 7 application types.

    You can configure AppQoS rule set/rule, define a QoS action, and attach AppQoS rule sets to a unified policy as application services, if the action is permit and the traffic matches the specified dynamic application.

    You can also configure AppQoS default rule set to manage unified policy conflicts when multiple security policies match the traffic. This default AppQoS rule set is leveraged from one of the existing AppQoS rule sets, which are configured under the [edit class-of-service application-traffic-control] hierarchy, and applied as default AppQoS rule set under the [edit security ngfw] hierarchy.

    Integrating dynamic applications as policy match condition provide additional security control by enforcing protocol and policy control at Layer 7 and enables flexibility in classifying the traffic.

  • ICAP service redirect support for unified policy (SRX Series, vSRX instances) —Starting in Junos OS Release 18.2R1, SRX Series devices and vSRX instances support the Internet Content Adaptation Protocol (ICAP) service redirect feature when the device is configured with unified policies.

    The SRX Series device decrypts the pass-through traffic when the device is configured with an SSL profile and applied under the security policy permitting the traffic. The SRX Series device acts as the SSL proxy, decrypts HTTP or HTTPS traffic, and redirects the HTTP or HTTPS message to a third-party, on-premises Data Loss prevention (DLP) server through an ICAP channel.

    In a unified policy with dynamic applications configured as match conditions, when the traffic matches the policy, the ICAP redirect service profile configured as application services is applied. The ICAP server profile defines the behavior of the redirection and server specifications. The DLP server performs the policy scan, and the traffic is redirected back to the SRX Series device, and an action is taken, as specified in the ICAP redirect profile.

    See SSL Proxy.

  • SSL proxy profile for unified policy (SRX Series, vSRX instances) —Starting in Junos OS Release 18.2R1, Unified Policies are now supported on SRX Series devices, allowing granular control and enforcement of dynamic Layer 7 applications within the traditional security policy.

    Unified policies are the security policies, where you can use dynamic applications as match conditions along with existing 5-tuple or 6-tuple matching conditions (with user firewall) to detect application changes over time, and allow you to enforce a set of rules for the transit traffic. As a part of this enhancement, you can configure a default SSL proxy profile, and apply it as an application services in a unified policy.

    Having a default SSL proxy profile helps in handling conflict in a unified policy when multiple matches occur in policy. That is—if there is a conflict or overlap between profiles configured on different unified policies within the same set of potential match policies, then a default SSL proxy profile is required to handle encrypted traffic. We recommend creating default SSL proxy profile; because sessions are dropped in case of policy conflicts when there is no default SSL proxy profile is available.

    You can configure SSL proxy profile under the services ssl proxy hierarchy, which can be applied as default SSL proxy profile under the security ngfw hierarchy. This configuration does not impact the existing SSL service configuration.

    Configuring default SSL proxy profile is supported for both SSL forward and reverse proxy.

    See SSL Proxy.

CoS

  • vSRX: Policer and shaper adjustment per interface —Starting in Junos OS Release 18.2R1, a vSRX instance now supports Layer 2 overhead configuration for shaping/policer. New commands have been added in Junos OS to support this feature on a vSRX:

    Note

    Only the interface-specific filter and logical-interface-policer policer are supported.

    • New command for shaping overhead per interface: set class-of-service interfaces ge-0/0/0 interface-name shaping-rate overhead <bytes>

    • New commands for policer overhead per interface:

      • set interfaces ge-0/0/0 interface-name policer-overhead <bytes>

      • set interfaces ge-0/0/0 interface-name policer-overhead ingress <bytes>

      • set interfaces interface-name policer-overhead egress <bytes>

    [See interfaces (CoS Interfaces).]

  • PowerMode IPsec for SPC3 (SRX4000 and SRX5000 Series devices, and vSRX instances)—Starting in Junos OS Release 18.2R1, PowerMode IPsec™ is a new mode of operation for Juniper’s Intel-based SRX product offerings, including vSRX, SRX4000 series, and SRX5000 series when equipped with SPC3 services cards. PowerMode IPsec is small software block inside SRXPFE, which is activated when PowerMode is enabled.

    You enable PowerMode IPsec processing using the set security flow power-mode-ipsec command.

    Note

    Enabling PowerMode IPsec processing restarts the SRXPFE.

    When PowerMode IPsec is enabled, only the following features are supported:

    • IPSec functionality

    • Traffic selectors

    • St0 interface

    • All control plane IKE functionality

    • Auto VPN with traffic selector

    • Auto VPN with routing protocol

    • IPv6

    • Stateful Layer 4 firewall

    • ADVPN

    • High-Availability

    • NAT-T

Note the following usage considerations with PowerMode IPsec:

  • Anti-Replay maximum window size supported is 64

  • Post/Pre-Fragment packets will not go through PowerMode IPSec

  • Any fragments received on an interface will not go through PowerMode IPSec

  • A tunnel session belongs to either PowerMode IPSec or Non PowerMode IPSec

[See Advanced Policy-Based Routing.]

IDP

  • Flexible grouping of IDP signatures for policies and profiles (SRX Series, vSRX instances)—Starting in Junos OS Release 18.2R1, IDP signature updates support four new tags for creating more sophisticated dynamic groups in addition to the existing seven tags. The signature database is one of the major components of intrusion detection and prevention (IDP). It contains definitions of different objects—such as attack objects, application signatures objects, and service objects—that are used in defining IDP policy rules. Attacks can be grouped by set of tags.

    The additional tags are:

    • CVSS Score (for example: All signatures above 8.0)

    • Age (for example: Older than <x> years)

    • File Type (for example: MPEG, MP4, PPT, *.doc, and so on)

    • Vulnerability Type (for example: buffer overflow, injection, use after free, XSS, RCE, and so on.

    The Product and Vendor tags are already supported under existing filter products. The CLI interface for configuring these tags is now been made more user friendly with possible completions being available for configuration.

    • Vendor (for example: Microsoft, Apple, Red Hat, Google, Juniper, Cisco, Oracle, and so on.)

    • Product (for example: Office, Database, Firefox, Chrome, Flash, DirectX, Java, Kerberos, and so on.)

  • IDP support within unified security policy (SRX Series, vSRX instances)—Starting in Junos OS Release 18.2R1, Unified Policies are supported on SRX Series devices and vSRX instances, allowing granular control and enforcement of dynamic Layer 7 applications within the traditional Security Policy. Layer 7 dynamic applications are integrated with Firewall policy match criteria and IDP supports Layer 7 application based Firewall policies.

    IDP policy support within unified security policies enables the device to match conditions based on applications and provide deep packet inspection by identifying the Layer 3 and Layer 4 details.

    All IDP matches are now handled within the unified policy unless explicit source, destination, or application is defined.

    You can additionally configure match conditions in IDP to achieve additional inspection granularity.

    You activate an IDP policy by using the set security policies from-zone zone-name to-zone zone-name policy policy-name then permit application-services idp-policy idp-policy-name command.

    With this configuration of the unified policy, you need not configure source or destination address, source or destination-except, from or to-zone, or application as the match happens in the firewall itself.

    Starting from Junos OS Release 18.2R1 active IDP policy configuration is deprecated, instead being removed, to provide backward compatibility and a chance to bring your configuration into compliance with the new configuration. For implementing this the set security idp active-policy policy-name CLI command is now deprecated.

Routing Policies and Firewall Filters

  • Support for unified policies (SRX Series, vSRX instances)—Starting in Junos OS Release 18.2R1, unified policies are now supported on SRX Series devices and vSRX instances, allowing granular control and enforcement of dynamic Layer 7 applications within the traditional security policy.

    Unified policies can permit, deny, reject, or redirect traffic based on results returned by the Application Identification (AppID) function. In releases before Junos OS Release 18.2R1, a separate Application Firewall(AppFW) rule base is required for this functionality. As unified policy provides a superior mechanism for controlling dynamic applications, the legacy AppFW feature has been deprecated in this release.

    Unified Policies uses policy match mode to create as one of the policy’s match criteria action rule in each application would be configured on policy level. The application ID could only be identified after several packets are checked. Before the application ID is available, policy cannot be matched precisely and potential policy list would be made available. Traffic is permitted with those potential matched policy list. After the application ID is identified, one final policy will be applied to the session.

UTM

  • UTM support within Unified Policy (SRX Series, vSRX instances)—Starting in Junos OS Release 18.2R1, Unified Policies are now supported on SRX Series devices and vSRX instances, allowing granular control and enforcement of dynamic Layer 7 applications within the traditional security policy.

    A new dynamic-application policy match condition is added to SRX Series devices, allowing an administrator to more effectively control the behavior of layer 7 applications. To accommodate layer 7 application-based policies in UTM, the set security utm default-configuration command is introduced. If any parameter in a specific UTM feature profile configuration is not configured, then the corresponding parameter from the UTM default configuration is applied.

VPN

  • Configuring forwarding class on IPsec VPNs (SRX Series, vSRX instances)—Starting in Junos OS Release 18.2R1, forwarding classes configured on an SRX Series device or vSRX instance can be mapped to IPsec security associations (SAs). Multiple IPsec SAs are negotiated on the same IKE SA with a peer device, one SA per forwarding class configured in IPsec.

    A unique IPsec SA is negotiated with the VPN peer for each forwarding class. By mapping the forwarding class to the IPsec SA, all the packets with a certain class-of-service (CoS) value will get quality-of-service (QoS) treatment between the peer devices, avoiding packet drop due to the anti-replay window. This feature provides QoS for IPsec when peer devices allow for multiple SA negotiation.

vSRX Architecture Illustration

vSRX Architecture

Figure 1 is a high-level illustration of the vSRX architecture as of Junos OS Release 18.2R1.

Figure 1: vSRX Architecture



vSRX Architecture

Supported Features

For details about Junos OS features supported on vSRX, see Feature Explorer: vSRX.

Supported Features References

Table 1 lists documentation references to Junos OS features that are supported on vSRX.

Note

Some vSRX features require a license. See vSRX Feature Licenses Overview for more details.

Table 1: Documentation References for Junos OS Features Supported on vSRX

Feature

Feature Documentation

vSRX Platform

Application Firewall (AppFW)

Application Firewall Overview

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Application Identification (AppID)

Understanding Application Identification Techniques

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Application Layer Gateways (ALGs)

ALG Overview

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Application Quality of Service (AppQoS)

Understanding Application QoS (AppQoS)

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Attack Detection and Prevention (ADP)

Attack Detection and Prevention Overview

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Chassis cluster support for Virtio driver

Chassis Cluster Overview

KVM

Chassis cluster support for VMXNET3 driver

Chassis Cluster Overview

VMware

Chassis cluster support for Windows Hyper-V Server 2016

Chassis Cluster Overview

Hyper-V

Class of service (CoS)

Understanding Class of Service

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Dynamic Host Configuration Protocol (DHCP)

Understanding Interfaces

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Flow and packet processing

Juniper Networks Devices Processing Overview

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Intrusion Detection and Prevention (IDP)

Understanding Intrusion Detection and Prevention

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

IPsec VPN

IPsec VPN Overview

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Multiprotocol Label Switching (MPLS)

MPLS Overview

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Multicast

Multicast Overview

VMware, KVM, and Contrail

Network Address Translation (NAT)

Introduction to NAT

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Routing protocols

Junos OS Routing Protocols Library

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Security building bocks

Understanding Security Basics

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Transparent mode

Ethernet Switching and Layer 2 Transparent Mode Overview

VMware, KVM, and Contrail

Unified Threat Management (UTM)

Unified Threat Management Overview

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

User authentication

Understanding User Authentication for Security Devices

VMware, KVM, Contrail, AWS, Azure, and Hyper-V

Unsupported Features

While vSRX supports many of the Junos OS features supported on other SRX Series devices, not all features are supported. For information about Junos OS features that are not supported on vSRX, see Known Behavior and SRX Series Features Not Supported on vSRX for specific support limitations.