This is the fifth post in the Loading Configs series. In this post, we will cover the load set command. This allows you to enter commands into the buffer just like you would on the CLI. All these commands are either set or delete based commands. Yes, you can use this to delete as well.
Here is a quick refresher on what we are doing…
For this lab series, we will use a simple topology to demonstrate the different ways to load configs. We have our SRX configured with TRUST and UNTRUST zones, a connection to the Internet, and a Windows 7 PC that has a browser installed. We will focus on making changes to our security policies.
Our current configured security policy is fairly straight forward. NAT, routing, security zones have all been pre-configured for this post. We will be permitting traffic from TRUST to the Internet for HTTP, ICMP, and DNS initially with the goal to add an HTTPS policy and have traffic pass. Our currently configured security policy is below:
security {
policies {
from-zone TRUST to-zone UNTRUST {
policy PERMIT-HTTPS {
match {
source-address any;
destination-address any;
application junos-http;
}
then {
permit;
}
}
policy PERMIT-ICMP {
match {
source-address any;
destination-address any;
application junos-icmp-all;
}
then {
permit;
}
}
policy PERMIT-DNS {
match {
source-address any;
destination-address any;
application [ junos-dns-tcp junos-dns-udp ];
}
then {
permit;
}
}
policy DENY-ALL {
match {
source-address any;
destination-address any;
application any;
}
then {
reject;
}
}
}
}
}
The load set command is used to enter normal commands into the buffer, just like you would at the terminal. This is an easy way to do batch loads and broad strokes of changes when you want to make sure you cover all your bases in a config. Using set-based commands is sometimes easier for people to understand what is going on as that is how they are used to entering them at the CLI.
Again for this lab we will permit HTTPS from the TRUST zone to the UNTRUST zone. The configuration below is what we will be using. Notice that we are actually deleting and then re-entering the DENY-ALL statement. This is just another way to make sure we have the right order of policies.
delete security policies from-zone TRUST to-zone UNTRUST policy DENY-ALL
set security policies from-zone TRUST to-zone UNTRUST policy PERMIT-HTTPS match source-address any
set security policies from-zone TRUST to-zone UNTRUST policy PERMIT-HTTPS match destination-address any
set security policies from-zone TRUST to-zone UNTRUST policy PERMIT-HTTPS match application junos-https
set security policies from-zone TRUST to-zone UNTRUST policy PERMIT-HTTPS then permit
set security policies from-zone TRUST to-zone UNTRUST policy DENY-ALL match source-address any
set security policies from-zone TRUST to-zone UNTRUST policy DENY-ALL match destination-address any
set security policies from-zone TRUST to-zone UNTRUST policy DENY-ALL match application any
set security policies from-zone TRUST to-zone UNTRUST policy DENY-ALL then reject
Once we have them added, we can do our show compare and we will see that we are inserting the PERMIT-HTTPS policy before the DENY-ALL policy.
[edit]
jfry@FRYGUY-LAB# show | compare
[edit security policies from-zone TRUST to-zone UNTRUST]
policy PERMIT-DNS { ... }
+ policy PERMIT-HTTPS {
+ match {
+ source-address any;
+ destination-address any;
+ application junos-https;
+ }
+ then {
+ permit;
+ }
+ }
policy DENY-ALL { ... }
As I mentioned, this is just like adding commands via the CLI -but instead, you can batch them and add them. Below is a quick video of me using the load set terminal command.