- play_arrow Introduction
- play_arrow Customer Portal Overview
- About the Customer Portal User Guide
- Customer Portal Overview
- Accessing Customer Portal
- Personalize the Customer Portal
- Switching the Tenant Scope
- Setting Up Your Network with Customer Portal
- About the Customer Portal Dashboard
- Changing the Customer Portal Password
- Resetting the Password
- Changing the Password on First Login
- Set a New Password After Your Existing Password Expires
- Configuring Two-Factor Authentication
- Extending the User Login Session
- Resend Activation Link in Customer Portal
- View and Edit Tenant Settings
- play_arrow Users and Roles
- Role-Based Access Control Overview
- About the Users Page in Customer Portal
- Adding Tenant and OpCo Tenant Users
- Editing and Deleting Tenant and OpCo Tenant Users
- Resetting the Password for Tenant Users
- Roles Overview
- About the Tenant Roles Page
- Adding User-Defined Roles for Tenant Users
- Editing, Cloning, and Deleting User-Defined Roles for Tenant Users
- Access Privileges for Role Scopes (Tenant and Operating Company)
- play_arrow SD-WAN and NGFW Deployments
-
- play_arrow Managing Sites, Site Groups, and Site Templates
- play_arrow Managing Sites
- About the Site Management Page
- Multihoming Overview
- Enterprise Hubs Overview
- Understand BGP Underlay Routing and Provider Edge (PE) Resiliency
- Upgrading Sites Overview
- Add Enterprise Hubs with SD-WAN Capability
- Add Provider Hub Sites in SD-WAN Deployments
- Adding Cloud Spoke Sites for SD-WAN Deployment
- Provisioning a Cloud Spoke Site in AWS VPC
- Manually Adding Branch Sites
- Add a Branch Site with SD-WAN Capability
- Adding and Provisioning a Next Generation Firewall Overview
- Enabling Integration with Mist Access Points
- Add a Standalone Next-Generation Firewall Site
- Managing LAN Segments on a Tenant Site
- Manage a Site
- Start a Network Service
- Disable a Network Service
- Delete a Network Service
- Add IP VPN Configuration to Provider Hubs
- Edit IP VPN Configuration for Provider Hubs
- Delete IP VPN Configuration from Provider Hubs
- Viewing the Sites History
- Edit Site Overview
- Edit Branch and Enterprise Hub Site Parameters
- Reconfigure Static Tunnels
- Edit Site Examples
- Upgrading Sites
- Delete a Site—Enterprise Hub, Cloud Spoke, and Branch
- play_arrow Managing Site Groups
- play_arrow Managing Site Templates
- play_arrow Managing Mesh Tags
- play_arrow Managing Dynamic Mesh
-
- play_arrow Managing Devices and Resources
- play_arrow Managing Authentication
- play_arrow Managing Devices
- Device Redundancy Support Overview
- Activate a Device
- Activating Dual CPE Devices (Device Redundancy)
- Viewing the History of Tenant Device Activation Logs
- Zero Touch Provisioning Overview
- Workflow for Onboarding a Device Using ZTP
- Configure an SRX Series CPE to Discover an EX Series Switch or AP Connected to the CPE
- play_arrow Managing Device Images
- play_arrow Managing Resources
- Multidepartment CPE Device Support
- About the Devices Page
- Perform Return Material Authorization (RMA) for a Device
- Grant Return Material Authorization (RMA) for a Device
- Manage a Single CPE Device
- Rebooting a CPE Device
- Configuring APN Settings on CPE Devices
- Identifying Connectivity Issues by Using Ping
- Identifying Connectivity Issues by Using Traceroute
- Remotely Accessing a Device CLI
- View the Current Configuration on a Device
- Generate Device RSI for Enterprise Hub and Spoke Devices
- Configuring the Firewall Device
- About the Physical Interfaces Page
- About the Logical Interfaces Page
- Adding a Logical Interface
- Editing, Deleting, and Deploying Logical Interfaces
- Enable LLDP on a CPE Interface
- Create LAG Interface
- Create a RETH Interface
- Create a Redundancy Group
- Manage Redundancy Groups
- Adding a Security Zone
- Adding a Routing Instance
- Create Management Connectivity Between a CPE and a Switch
- Discover an EX Series Switch or APs Configured Behind a CPE
- View an EX Series Switch or an AP on Mist
- View an SRX Series CPE on Juniper Mist
- About the Static Routes Page
- Adding a Static Route
- Editing, Deleting, and Deploying Static Routes
- play_arrow Managing Device Templates
- play_arrow Managing Configuration Templates
- Configuration Templates Overview
- Configuration Templates Workflow
- About the Configuration Templates Page
- Predefined Configuration Templates
- Edit, Clone, and Delete Configuration Templates
- Deploy Configuration Templates to Devices
- Undeploy a Configuration Template from a Device
- Dissociate a Configuration Template from a Device
- Preview and Render Configuration Templates
- Import Configuration Templates
- Export a Configuration Template
- Assign Configuration Templates to Device Templates
- Add Configuration Templates
- Jinja Syntax and Examples for Configuration Templates
- View the Configuration Deployed on Devices
- play_arrow Managing Licenses
- play_arrow Managing Signature Database and Certificates
- Signature Database Overview
- About the Signature Database Page
- Manually Installing Signatures
- Automating Signature Database Installation
- Managing Signature Installation Settings (Auto Installation)
- Certificates Overview
- About the Certificates Page
- Importing a Certificate
- Installing and Uninstalling Certificates
- About the VPN Authentication Page
- Modify PKI Settings for All Sites
- Modify PKI Settings for Selected Sites
- play_arrow Managing Juniper Identity Management Service
-
- play_arrow Managing Network Services and Shared Objects
- play_arrow Configuring Network Services
- play_arrow Managing Shared Objects
- Addresses and Address Groups Overview
- About the Addresses Page
- Creating Addresses or Address Groups
- Editing, Cloning, and Deleting Addresses and Address Groups
- Services and Service Groups Overview
- About the Services Page
- Creating Services and Service Groups
- Creating Protocols
- Editing and Deleting Protocols
- Editing, Cloning, and Deleting Services and Service Groups
- Application Signatures Overview
- About the Application Signatures Page
- Understanding Custom Application Signatures
- Adding Application Signatures
- Editing, Cloning, and Deleting Application Signatures
- Adding Application Signature Groups
- Editing, Cloning, and Deleting Application Signature Groups
- About the Departments Page
- Add a Department
- Delete a Department
- About the Protocols Page
- Add a Protocol Endpoint
- Edit or Delete Protocol Endpoint
-
- play_arrow Monitoring Jobs and Audit Logs
- play_arrow Managing Jobs
- play_arrow Managing Audit Logs
-
- play_arrow Monitoring Alarms, Events, and Threats
- play_arrow Monitoring Security Alerts and Alarms
- About the Monitor Overview Page
- Alerts Overview
- About the Generated Alerts Page
- About the Alert Definitions/Notifications Page
- Managing Security Alerts Definitions
- Creating Security Alert Definitions
- Editing, Cloning, and Deleting Security Alert Definitions
- About the Alarms Page
- Enable E-mail Notifications for SD-WAN Alarms
- Rogue Device Detection
- Monitoring Support for LTE Links on Dual CPEs
- play_arrow Monitoring Security
- About the All Security Events Page
- About the Firewall Events Page
- About the Web Filtering Events Page
- About the IPsec VPNs Events Page
- About the Content Filtering Events Page
- About the Antispam Events Page
- About the Antivirus Events Page
- About the IPS Events Page
- About the Screen Events Page
- About the Traffic Logs Page
- play_arrow Monitoring SD-WAN Events
- play_arrow Monitoring Applications
- About the SLA Performance of a Single Tenant Page
- Viewing the SLA Performance of a Site
- Viewing the SLA Performance of an Application or Application Group
- Application Visibility Overview
- About the Application Visibility Page
- About the User Visibility Page
- Viewing Application or User Visibility Data for Specific Sites
- play_arrow Monitoring Threats
- Syslog Streaming
-
- play_arrow Managing Reports
- play_arrow Security Reports
- Reports Overview
- About the Security Report Definitions Page
- Scheduling, Generating, Previewing, and Sharing Security Reports
- About the Security Generated Reports Page
- Creating Log Report Definition
- Creating Bandwidth Report Definition
- Creating ANR Report Definition
- Editing, Deleting, and Cloning Log Report Definitions
- Editing, Deleting, and Cloning Bandwidth Report Definitions
- Editing, Deleting, and Cloning ANR Report Definitions
- play_arrow SD-WAN Reports
-
ON THIS PAGE
Example 2: Firewall Policy that Permits Internet Access for all Departments in Site A and Site B
Example 4: Firewall Policy that Permits Social Media Access to all Departments in Site A
Example 5: Firewall Policy that Controls Access to Specific Applications for Various Departments
Example 6: Firewall Policy that Denies Access to Social Networking Sites
Example 7: Firewall Policy that Controls Access to an Address over the Internet (HTTP)
Example 8: Firewall Policy that Permits or Denies the Use of HTTP or FTP as a Service
Example 10: Firewall Policy that Allows Access to Facebook for Users in User Group A
Example 12: Firewall Policy that blocks access to Internet and allow access to Google Drive.
Firewall Policy Examples
This topic provides information on how firewall policy intents that you define as part of your firewall policy is handled by Contrail Service Orchestration (CSO), using various examples. Each of the examples provide detailed explanation about how a firewall policy intent defined through the CSO GUI resolves into configuration in the system.
For more information, see Firewall Policy Overview and Adding Firewall Policy Intents.
For easier understanding, all the examples have been defined to use the topology in illustrated in Figure 1. In this topology, there are two sites—site A and site B. Each site has two departments defined as follows:
Site A - IT (LAN segment LS1) and Finance (LAN segment LS2).
Site B - Finance (LAN segment LS3) and Sales (LAN segment LS4).

The following definitions are applicable to all the examples:
While creating a site, you can designate some of the WAN interfaces to be breakout interfaces. These WAN interfaces can carry both site-to-site traffic (through the trust zone) and breakout traffic (through the untrust zone). The WAN interfaces can also be designated exclusively for carrying breakout traffic.
A trust zone refers to the overlay interface that contains all the GRE tunnel interfaces, such as gr-0/0/0.1, gr-0/0/0.2, and IPSec interfaces, such as st0.1, st0.2 created between the sites.
An untrust zone refers to the underlay interfaces (underlying physical interfaces) such as ge-0/0/0, ge-0/0/1.
If you select an address or a service as a destination endpoint, CSO considers it as an address or service hosted on the Internet, unless the selected address or service is associated with a site.
Table 1 captures the addresses associated with the LAN segments used in the topology illustrated in Figure 1.
Table 1: LAN Segments Definition Site
Department
LAN Segment
LAN Segment Address
site A
IT
LS1
192.0.2.0/24
site A
Finance
LS2
192.168.1.0/24
site B
Finance
LS3
198.51.100.0/24
site B
Sales
LS4
203.0.113.0/24
The following examples help you understand the creation of intent-based firewall policies for various traffic scenarios across sources and destinations.
Example 1: Firewall Policy that Permits Traffic from Departments in Site A to the Departments in Site B
Define a firewall policy that permits traffic from the departments in site A to the departments in site B.
Table 2 shows the firewall policy intent that is defined:
Source | Destination | Action |
---|---|---|
site A | site B | Permit |
Table 3 shows how this firewall policy intent is resolved:
Site | Source Department | Source Address | Zone | Destination Address | Service | Intent Created |
---|---|---|---|---|---|---|
site A | Finance | [LS2] | Trust | [LS3, LS4] | Any | Intent 1__0 |
IT | [LS1] | Trust | [LS3, LS4] | Any | Intent 1__1 | |
site B | Trust | [LS3, LS4] | Sales | [LS2] | Any | Intent 1__0 |
Trust | [LS3, LS4] | Finance | [LS1] | Any | Intent 1__1 |
Configuration Output Sample
Sample of configuration that permits traffic from departments in site A to the departments in site B.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone FINANCE to-zone trust { policy Intent_1__0 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address [ls-198.51.100.0/24-SP50-L3, ls-203.0.113.0/24-SP50-L4]; application any; } then { permit; } } } from-zone IT to-zone trust { policy Intent_1__1 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address [ls-198.51.100.0/24-SP50-L3, ls-203.0.113.0/24-SP50-L4]; application any; } then { permit; } } }
Sample of configuration that permits traffic from departments in site B to the departments in site A.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone trust to-zone SALES { policy Intent_1__0 { match { source-address [ls-198.51.100.0/24-SP50-L3, ls-203.0.113.0/24-SP50-L4]; destination-address ls-192.0.2.0/24-S42-L1; application any; } then { permit; } } } from-zone trust to-zone FINANCE { policy Intent_1__1 { match { source-address [ls-198.51.100.0/24-SP50-L3, ls-203.0.113.0/24-SP50-L4]; destination-address ls-192.168.1.0/24-SP50-L2; application any; } then { permit; } } }
Example 2: Firewall Policy that Permits Internet Access for all Departments in Site A and Site B
Define a firewall policy that permits all the department in site A and site B access to Internet.
Table 4 shows the firewall policy intent that is defined:
Source | Destination | Action |
---|---|---|
site A | http, https, icmp-ping, dns | Permit |
site B | http, https, icmp-ping, dns | Permit |
Table 5 shows how this firewall policy intent is resolved:
Site | Source Department | Source Address | Zone | Destination Address | Service | Intent Created |
---|---|---|---|---|---|---|
site A | Finance | [LS2] | Untrust | Any | http, https, icmp-ping, dns | Intent 1__0 |
IT | [LSI] | Untrust | Any | http, https, icmp-ping, dns | Intent 1__1 | |
site B | Sales | [LS4] | Untrust | Any | http, https, icmp-ping, dns | Intent 1__0 |
Finance | [LS3] | Untrust | Any | http, https, icmp-ping, dns | Intent 1__1 |
Configuration Output Sample
Sample of configuration that permits Internet access to all departments in site A.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance to-zone untrust { policy Intent_1__0 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address any; application [junos-http junos-dns-tcp junos-https junos-icmp-ping]; } then { permit; } } } from-zone IT to-zone untrust { policy Intent_1__1 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address any; application [junos-http junos-dns-tcp junos-https junos-icmp-ping]; } then { permit; } } } policy-rematch;
Sample of configuration that permits Internet access to all departments in site B.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Sales to-zone untrust { policy Intent_1__0 { match { source-address ls-203.0.113.0/24-SP50-L4; destination-address any; application [junos-http junos-dns-tcp junos-https junos-icmp-ping]; } then { permit; } } } from-zone Finance1 to-zone untrust { policy Intent_1__1 { match { source-address ls-198.51.100.0/24-SP50-L3; destination-address any; application [junos-http junos-dns-tcp junos-https junos-icmp-ping]; } then { permit; } } } policy-rematch;
Example 3: Firewall Policy that Permits Any Public Internet Address to Access the Sales Department in Site B
Define a firewall policy that permits any public Internet address access to a sales application hosted by the Sales department in site B.
For this example, breakout is not enabled and MPLS link type is used.
Table 6 shows the firewall policy intent that is defined:
Source | Destination | Action |
---|---|---|
Internet | Sales, site B | Permit |
Table 7 shows how this firewall policy intent is resolved:
Source Address | Zone | Destination Address | Service | Intent Created |
---|---|---|---|---|
Any public Internet address | Trust to Sales (No breakout) | [LS4] | Any | Intent 1__0 |
Configuration Output Example
Sample of configuration that permits any public Internet address to access the Sales department in site B.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone untrust to-zone Sales { policy Intent_1__0 { match { source-address any; destination-address ls-203.0.113.0/24-SP50-L4; application any; } then { permit; } } }
Example 4: Firewall Policy that Permits Social Media Access to all Departments in Site A
Define a firewall policy that permits all departments in site A access to Facebook.
Table 8 shows the firewall policy intent that is defined:
Source | Destination | Action |
---|---|---|
site A | Permit |
Table 9 shows how this firewall policy intent is resolved:
Site | Source Address | Zone | Destination Address | Service | Intent Created | Application Firewall Profile |
---|---|---|---|---|---|---|
site A | [LS2] | Untrust | Any | Intent 1__0 | AppFwProfile_0 | |
site A | [LS1] | Untrust | Any | Intent 1__1 | AppFwProfile_0 |
Configuration Output Example
Sample of configuration that controls access to Facebook for site A.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance to-zone untrust { policy Intent_1__0 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address any; application any; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } } } } from-zone IT to-zone untrust { policy Intent_1__1 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address any; application any; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } } } } policy-rematch;
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
application-firewall { rule-sets AppFwProfile_0 { rule rule-1 { match { dynamic-application junos:FACEBOOK-APP; ssl-encryption any; } then { permit; } } default-rule { deny; } } }
Example 5: Firewall Policy that Controls Access to Specific Applications for Various Departments
Define a firewall policy that controls access to specific applications from various departments, with the following intents:
The finance departments located in site A and site B (which are in different geographical locations) are permitted to access the news applications BBC and CNN.
The IT department located in site A is denied access to the news applications BBC and CNN.
Access to Telnet and SSH applications is given only to the finance departments.
Access to Telnet and SSH applications is denied to all departments, except for the finance department.
Table 10 shows the firewall policy intents that are to fulfil this requirement:
Source | Destination | Action |
---|---|---|
Finance department, site A and Finance department, site B | BBC and CNN | Permit |
IT department, site A | BBC and CNN | Deny |
Finance department, site A and Finance department, site B | Telnet and SSH | Permit |
Any (All addresses except the finance department) | Telnet and SSH | Deny |
The number of intents depends on the number of source sites within the given department and the number of destination sites.
Table 11 shows how this firewall policy intent is resolved:
Source Department | Source Address | Zone | Destination Address | Service | Application Firewall Profile |
---|---|---|---|---|---|
Finance | [LS2] | Trust/Untrust | Any | Any | AppFwProfile_1 Permit: CNN/BBC Def. Rule : Permit |
Finance | [LS3] | Trust/Untrust | Any | Any | AppFwProfile_1 Permit: CNN/BBC Def. Rule : Permit |
IT | [LS1] | Trust/Untrust | Any | Any | AppFwProfile_3 Deny: CNN/BBC Def. Rule : Deny |
Finance department, site A and Finance department, site B | [LS2, LS3] | Trust/Untrust | Any | Telnet, SSH | AppFwProfile_1-1 Permit: Telnet/SSH Def. Rule : Deny |
IT department, site A | [LS1] | Trust/Untrust | Any | Telnet, SSH | AppFwProfile_3-1 Deny: Telnet/SSH Def. Rule : Deny |
Configuration Output Example
Sample of configuration that controls access to specific applications for various departments in site A.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance to-zone trust { policy Intent_3 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address any; application [junos-telnet junos-ssh]; } then { permit { application-services { application-firewall { rule-set AppFwProfile_1-1; } } } } } policy Intent_1 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address any; application any; } then { permit { application-services { application-firewall { rule-set AppFwProfile_1; } } } } } policy Intent_4__0 { match { source-address any; destination-address any; application [junos-telnet junos-ssh]; } then { permit; } } } from-zone IT to-zone trust { policy Intent_4__1-1 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address any; application [junos-telnet junos-ssh]; } then { permit { application-services { application-firewall { rule-set AppFwProfile_3-1; } } } } } policy Intent_2 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address any; application any; } then { permit { application-services { application-firewall { rule-set AppFwProfile_3; } } } } } policy Intent_4__1 { match { source-address any; destination-address any; application [junos-telnet junos-ssh]; } then { deny; } } }
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
rule-sets AppFwProfile_1-1 { rule rule-1 { match { dynamic-application [junos:BBC junos:CNN]; ssl-encryption any; } then { permit; } } default-rule { deny; } } rule-sets AppFwProfile_3 { rule rule-2 { match { dynamic-application [junos:BBC junos:CNN]; ssl-encryption any; } then { deny; } } default-rule { deny; } } rule-sets AppFwProfile_1 { rule rule-3 { match { dynamic-application [junos:BBC junos:CNN]; ssl-encryption any; } then { permit; } } default-rule { deny; } } rule-sets AppFwProfile_3-1 { rule rule-4 { match { dynamic-application [junos:BBC junos:CNN]; ssl-encryption any; } then { deny; } } default-rule { deny; } }
Sample of configuration that controls access to specific applications for various departments in site B.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance to-zone trust { policy appQoe-36600-Permit-rule { match { source-address any; destination-address any; application appQoe-36000; } then { permit; } } policy Intent_3 { match { source-address ls-198.51.100.0/24-SP50-L3; destination-address any; application [ junos-telnet junos-ssh ]; } then { permit { application-services { application-firewall { rule-set AppFwProfile_1-1; } } } } } policy Intent_1 { match { source-address ls-198.51.100.0/24-SP50-L3; destination-address any; application any; } then { permit { application-services { application-firewall { rule-set AppFwProfile_1; } } } } } policy Intent_4__1 { match { source-address any; destination-address any; application [junos-telnet junos-ssh]; } then { deny; } } } from-zone Sales to-zone trust { policy Intent_4__0 { match { source-address any; destination-address any; application [junos-telnet junos-ssh]; } then { deny; } } } policy-rematch;
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
rule-sets AppFwProfile_1-1 { rule rule-ca2354d6-a7ba-488e-8c5a-91cbddfb9583-appFwRule { match { dynamic-application [junos:BBC junos:CNN]; ssl-encryption any; } then { permit; } } default-rule { deny; } } rule-sets AppFwProfile_1 { rule rule-ca2354d6-a7ba-488e-8c5a-91cbddfb9583-appFwRule { match { dynamic-application [junos:BBC junos:CNN]; ssl-encryption any; } then { permit; } } default-rule { deny; } }
Example 6: Firewall Policy that Denies Access to Social Networking Sites
Define a firewall policy that denies access to networking sites such as Facebook and Twitter (defined as application group Social Networking) to the IT and finance departments located in Site A.
Table 12 shows the firewall policy intent that is needed to fulfil this requirement:
Source | Destination | Action |
---|---|---|
IT and Finance, site A | Application group Social Networking (Facebook and Twitter) | Deny |
Add site A if the IT or finance departments are present in different sites, but you only want to apply this firewall policy intent to the IT or finance departments present in site A.
Table 13 shows how this firewall policy intent is resolved:
Source Department | Source Address | Zone | Destination Address | Service | Application Firewall Profile |
---|---|---|---|---|---|
Finance | [LS2] | Trust/Untrust | Any | Any | AppFwProfile_0 Deny: Social Networking (Apps) Def. Rule : Deny |
IT | [LS1] | Trust/Untrust | Any | Any | AppFwProfile_1 Deny: Social Networking (Apps) Def. Rule : Deny |
Configuration Output Example
Sample of configuration that denies access to social networking sites for departments in site A.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone IT to-zone untrust { policy Intent_1__0 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address any; application any; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } } } } from-zone Finance to-zone untrust { policy Intent_1__1 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address any; application any; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } } } }
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
application-firewall { rule-sets AppFwProfile_0 { rule rule-b7e4ed02-e196-400a-88bf-f1de8973d30c-appFwRule { match { dynamic-application-group Socialnetwork; ssl-encryption any; } then { deny; } } default-rule { deny; } } }
Example 7: Firewall Policy that Controls Access to an Address over the Internet (HTTP)
Define a firewall policy that controls access to an address over the Internet (HTTP) for various sites or site groups with the following intents:
IP address prefix of site A and site B are permitted to access example.com.
IP address prefix of site group Q1 are denied access to example-one.com. Site group Q1 consists of site A and site B.
Table 14 shows the firewall policy intents that are needed to fulfil this requirement:
Source | Service | Destination | Action |
---|---|---|---|
IP address prefix, site A and IP-Prefix, site B | HTTP | www.example.com | Permit |
IP address prefix, site group Q1 | HTTP | www.example-one.com | Deny |
Table 15 shows how this firewall policy intent is resolved:
Source Department | Source Address | Zone | Destination Address | Service | Application Firewall Profile |
---|---|---|---|---|---|
IT, Finance departments in site A | [LS1, LS2] | Trust/Untrust | www.example.com | Any | AppFwProfile_0 Permit: HTTP Def. Rule : Deny |
Finance, Sales departments in site B | [LS3, LS4] | Trust/Untrust | www.example.com | Any | AppFwProfile_1 Permit: HTTP Def. Rule : Deny |
IT, Finance departments in site A | [LS1, LS2] | Trust/Untrust | www.example-one.com | Any | AppFwProfile_2 Deny: HTTP Def. Rule : Deny |
Finance, Sales departments in site B | [LS3, LS4] | Trust/Untrust | www.example-one.com | Any | AppFwProfile_3 Deny: HTTP Def. Rule : Deny |
Configuration Output Example
Sample of configuration that controls access to an address over the Internet (HTTP) for site A.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance to-zone untrust { policy Intent_4__0 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address www.example.com; application junos-http; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } } } policy Intent_1__0 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address addr2; application junos-http; } then { permit { application-services { application-firewall { rule-set AppFwProfile_1; } } } } } } from-zone IT to-zone untrust { policy Intent_4__1 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address addr2; application junos-http; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } } } policy Intent_1__1 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address addr2; application junos-http; } then { permit { application-services { application-firewall { rule-set AppFwProfile_1; } } } } } } policy-rematch;
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
rule-sets AppFwProfile_1 { rule rule-ca2354d6-a7ba-488e-8c5a-91cbddfb9583-appFwRule { match { dynamic-application junos:YOUTUBE; ssl-encryption any; } then { deny; } } default-rule { deny; } } rule-sets AppFwProfile_0 { rule rule-00f3879c-f3d7-4cb3-89b6-78328e3bff38-appFwRule { match { dynamic-application junos:CNN; ssl-encryption any; } then { permit; } } rule rule-ca2354d6-a7ba-488e-8c5a-91cbddfb9583-appFwRule { match { dynamic-application junos:YOUTUBE; ssl-encryption any; } then { deny; } } default-rule { deny; } }
Sample of configuration that controls access to an address over the Internet (HTTP) for site B.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance to-zone untrust { policy Intent_4__1 { match { source-address ls-198.51.100.0/24-SP50-L3; destination-address addr2; application junos-http; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } } } policy Intent_1__1 { match { source-address ls-198.51.100.0/24-SP50-L3; destination-address addr2; application junos-http; } then { permit { application-services { application-firewall { rule-set AppFwProfile_1; } } } } } } from-zone Sales to-zone untrust { policy Intent_4__0 { match { source-address ls-203.0.113.0/24-SP50-L4; destination-address addr2; application junos-http; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } } } policy Intent_1__0 { match { source-address ls-203.0.113.0/24-SP50-L4; destination-address addr2; application junos-http; } then { permit { application-services { application-firewall { rule-set AppFwProfile_1; } } } } } } policy-rematch;
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
rule-sets AppFwProfile_1 { rule rule-ca2354d6-a7ba-488e-8c5a-91cbddfb9583-appFwRule { match { dynamic-application junos:YOUTUBE; ssl-encryption any; } then { deny; } } default-rule { deny; } } rule-sets AppFwProfile_0 { rule rule-00f3879c-f3d7-4cb3-89b6-78328e3bff38-appFwRule { match { dynamic-application junos:CNN; ssl-encryption any; } then { permit; } } rule rule-ca2354d6-a7ba-488e-8c5a-91cbddfb9583-appFwRule { match { dynamic-application junos:YOUTUBE; ssl-encryption any; } then { deny; } } default-rule { deny; } }
Example 8: Firewall Policy that Permits or Denies the Use of HTTP or FTP as a Service
Define a firewall policy where a specific IP address that belongs to the IT department is permitted or denied the use of HTTP or FTP as a service.
Table 16 shows the firewall policy intents that are needed to fulfil this requirement:
Source | Service | Destination | Action |
---|---|---|---|
192.0.2.0 | HTTP | example.com | Permit |
192.0.2.0 | FTP | example.com | Deny |
Table 17 shows how this firewall policy intent is resolved:
Source Department | Source Address | Zone | Destination Address | Service |
---|---|---|---|---|
IT, site A | 192.0.2.0 | Trust/Untrust | example.com | FTP |
IT, site A | 192.0.2.0 | Trust/Untrust | example.com | HTTP |
Configuration Output Example
Sample of configuration that allows access to HTTP
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone IT to-zone trust { policy Intent_1__1 { match { source-address 192.0.2.0; destination-address example.com; application junos-ftp; } then { deny; } } policy Intent_4__1 { match { source-address 192.0.2.0; destination-address example.com; application junos-http; } then { permit; } } } policy-rematch;
Example 9: Firewall Policy that Denies Access to BitTorrent to the Finance Departments across both Site A and Site B
Define a firewall policy that denies access to BitTorrent for the Finance departments in site A and Site B.
Table 18 shows the firewall policy intents that are needed to fulfil this requirement:
Source | Destination | Action |
---|---|---|
site A, Finance department | BitTorrent | Deny |
site B, Finance department | BitTorrent | Deny |
Table 19 shows how this firewall policy intent is resolved:
Site | Source Address | Zone | Destination Application | Service | Application Firewall Profile |
---|---|---|---|---|---|
Finance department, site A | [LS2] | Trust/Untrust | BitTorrent | Any | AppFwProfile_0 Deny: BitTorrent Def. Rule : Deny |
Finance department, site B | [LS3] | Trust/Untrust | BitTorrent | Any | AppFwProfile_0 Deny: BitTorrent Def. Rule : Deny |
Configuration Output Example
Sample of configuration that allows site A access to BitTorrent.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance to-zone untrust { policy appQoe-36600-Permit-rule { match { source-address any; destination-address any; application appQoe-36000; } then { permit; } } policy Intent_1 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address any; application any; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } log { session-init; session-close; } } } } policy-rematch;
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
rule-sets AppFwProfile_0 { rule rule-2226740d-03a9-483c-b315-eddc9ae8619a-appFwRule { match { dynamic-application junos:BITTORRENT; ssl-encryption any; } then { deny; } } default-rule { deny; } }
Sample of configuration that allows site B to access to BitTorrent.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance1 to-zone untrust { policy appQoe-36600-Permit-rule { match { source-address any; destination-address any; application appQoe-36000; } then { permit; } } policy Intent_4 { match { source-address ls-198.51.100.0/24-SP50-L3; destination-address any; application any; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } log { session-init; session-close; } } } } policy-rematch;
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
rule-sets AppFwProfile_0 { rule rule-00f3879c-f3d7-4cb3-89b6-78328e3bff38-appFwRule { match { dynamic-application junos:BITTORRENT; ssl-encryption any; } then { deny; } } default-rule { deny; } }
Example 10: Firewall Policy that Allows Access to Facebook for Users in User Group A
Define a firewall policy where the users that are a part of user group A are provided access only to Facebook, and no other applications. User group A consists of users located in site A.
Table 20 shows the firewall policy intent that is needed to fulfil this requirement:
Source | Destination | Action |
---|---|---|
user group A, site A | Permit |
Table 21 shows how this firewall policy intent is resolved:
Site | User/User Group | Source Address Range | Destination Address | Application |
---|---|---|---|---|
site A | user group A | 192.0.2.0 to 192.0.2.20 | Any |
Configuration Output Example
Sample of configuration that allows users in user group A access to Facebook.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance to-zone untrust { policy appQoe-36600-Permit-rule { match { source-address any; destination-address any; application appQoe-36000; } then { permit; } } policy Intent_4__0 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address any; application any; source-identity "USERFW.LOCAL\Cert Publishers"; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } log { session-init; session-close; } } } } from-zone IT to-zone untrust { policy appQoe-36600-Permit-rule { match { source-address any; destination-address any; application appQoe-36000; } then { permit; } } policy Intent_4__1 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address any; application any; source-identity "USERFW.LOCAL\Cert Publishers"; } then { permit { application-services { application-firewall { rule-set AppFwProfile_0; } } } log { session-init; session-close; } } } } policy-rematch;
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
rule-sets AppFwProfile_0 { rule rule-00f3879c-f3d7-4cb3-89b6-78328e3bff38-appFwRule { match { dynamic-application junos:FACEBOOK-APP; ssl-encryption any; } then { permit; } } default-rule { deny; } }
The hierarchy level for the following configuration sample is [edit services user-identification identity-management]
.
connection { connect-method https; port 443; primary { address 10.213.50.50; client-id 1234; client-secret "$ABC123"; ## SECRET-DATA } token-api oauth_token/oauth; query-api user_query/v2; } batch-query { items-per-batch 200; query-interval 5; } ip-query { query-delay-time 15; }
Example 11: Firewall Policy that Permits User B in Site A Access to YouTube with Content Security Enabled
Define a firewall policy where the User B located in Site A is provided access only to YouTube with Content Security enabled. The user does not have permission to access any other applications.
Table 22 shows the firewall policy intent that is needed to fulfil this requirement:
Source | Destination | Action |
---|---|---|
user B, site A | YouTube | Permit |
Table 23 shows how this firewall policy intent is resolved:
Site | Source Address | User/User Group | Destination Address | Content Security | Application |
---|---|---|---|---|---|
site A | 192.0.2.22 | user B | Any | Enabled |
Configuration Output Example
Sample of configuration that allows user B in site A access to YouTube, with Content Security enabled.
The hierarchy level for the following configuration sample is [edit security policies]
.
from-zone Finance to-zone untrust { policy Intent_4__0 { match { source-address ls-192.168.1.0/24-SP50-L2; destination-address any; application any; source-identity "userfw.local\CSO1"; } then { permit { application-services { utm-policy testUTM; application-firewall { rule-set AppFwProfile_0; } } } log { session-init; session-close; } } } } from-zone IT to-zone untrust { policy Intent_4__1 { match { source-address ls-192.0.2.0/24-S42-L1; destination-address any; application any; source-identity "userfw.local\CSO1"; } then { permit { application-services { utm-policy testUTM; application-firewall { rule-set AppFwProfile_0; } } } log { session-init; session-close; } } } } policy-rematch;
The hierarchy level for the following configuration sample is [edit security utm]
.
feature-profile { web-filtering { type juniper-local; } } utm-policy testUTM { web-filtering { http-profile junos-wf-local-default; } anti-spam { smtp-profile junos-as-defaults; } traffic-options { sessions-per-client { over-limit log-and-permit; } } }
The hierarchy level for the following configuration sample is [edit security application-firewall]
.
rule-sets AppFwProfile_0 { rule rule-00f3879c-f3d7-4cb3-89b6-78328e3bff38-appFwRule { match { dynamic-application junos:FACEBOOK-APP; ssl-encryption any; } then { permit; } } default-rule { deny; } }
The hierarchy level for the following configuration sample is [edit services user-identification identity-management]
.
connection { connect-method https; port 443; primary { address 10.213.50.50; client-id 1234; client-secret "$ABC123"; ## SECRET-DATA } token-api oauth_token/oauth; query-api user_query/v2; } batch-query { items-per-batch 200; query-interval 5; } ip-query { query-delay-time 15; }
Example 12: Firewall Policy that blocks access to Internet and allow access to Google Drive.
The following section provides a sample firewall policy to block access to Internet and allow access to Google Drive. The firewall policy has one enterprise-based intent and one zone-based intent.
An enterprise-based intent to block access to Internet is provided in Table 24.
Rule Name | Source Endpoint | Destination Endpoint | Action |
---|---|---|---|
EnterpriseIntent_1 | Engg (Department) | Internet | Deny |
A zone-based intent to allow access to Google drive is provided in Table 25.
Rule Name | Source Endpoint | Destination Endpoint | Action |
---|---|---|---|
ZoneIntent_1 | Engg (Zone) | untrust(zone), google-drive | Allow |
The intents in Table 24 and Table 25 result in firewall rules order that is provided in Table 26.
Rule Name | Rule Order | Source Endpoint | Destination Endpoint | Action |
---|---|---|---|---|
ZoneIntent_1 | 1 | Engg (Zone) | untrust(zone), google-drive | Allow |
EnterpriseIntent_1 | 2 | Engg (Department) | Internet | Deny |