Hi Alex,
Thanks for the link! I just noticed in the description of the script:
"Note that this script will not work with config groups, since they are
always the last terms." Duh! I didn't do a display inheritance when I
put my first couple of policies in, so I didn't notice that even though
my other policies came after the apply-groups statement, the PERMIT-ALL
policy came last because of the way config groups are handled. And,
that was exactly what I wanted.
I did learn something, though. :-)
Thanks for your help!
-John
On 06/28/2011 02:39 PM, Alex wrote:
Re-test #2:
If I type "set" commands, uppercase is accepted.
However, when I use "load merge terminal", the uppercase group name is
errored and converted to "?".
Using your exact example config:
{primary:node1}[edit]
user@host# load merge terminal
[Type ^D at a new line to end input]
groups {
? PERMIT-ALL {
security {
terminal:2:(15) syntax error: PERMIT-ALL
[edit groups "?"]
'? PERMIT-ALL {'
syntax error
policies {
from-zone<*> to-zone<*> {
policy PERMIT-ALL {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
log {
session-init;
session-close;
}
}
}
}
}
}
}
?}
load complete (1 errors)
{primary:node1}[edit]
user@host# show groups
<snip>
"?" {
security {
policies {
from-zone<*> to-zone<*> {
policy PERMIT-ALL {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
log {
session-init;
session-close;
}
}
}
}
}
}
}
After renaming "?" to PERMIT-ALL it is accepted and applied without any
further probs:
{primary:node1}[edit]
lab@jimbo# show security policies | display inheritance | except ##
from-zone LAN to-zone VPN {
policy LAN_VPN {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
policy PERMIT-ALL {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
log {
session-init;
session-close;
}
}
}
}
<snip>
So it looks like a small bug with "load merge terminal" in 11.1 daily I am
using for this test, I guess :-)
As for commit-scripts - check if this one fulfills your requirement
http://www.juniper.net/us/en/community/junos/script-automation/library/configuration/deny-last/
HTH
Rgds
Alex
----- Original Message -----
From: "John Center"<[email protected]>
To:<[email protected]>
Sent: Tuesday, June 28, 2011 7:12 PM
Subject: Re: [j-nsp] Using apply-groups for last policy on SRX
Hi Alex,
Thanks for responding. I'm not sure I understand what you mean about the
capitalization. The group PERMIT-ALL works under 10.4:
policies {
from-zone PROD-SYSTEMS to-zone ADMIN-SYSTEMS {
##
## 'PERMIT-ALL' was inherited from group 'PERMIT-ALL'
##
policy PERMIT-ALL {
##
## 'match' was inherited from group 'PERMIT-ALL'
##
match {
##
## 'any' was inherited from group 'PERMIT-ALL'
##
source-address any;
##
## 'any' was inherited from group 'PERMIT-ALL'
##
destination-address any;
##
## 'any' was inherited from group 'PERMIT-ALL'
## Warning: application or application-set must be defined
##
application any;
}
##
## 'then' was inherited from group 'PERMIT-ALL'
##
then {
##
## 'permit' was inherited from group 'PERMIT-ALL'
##
permit;
##
## 'log' was inherited from group 'PERMIT-ALL'
##
log {
##
## 'session-init' was inherited from group
'PERMIT-ALL'
##
session-init;
##
## 'session-close' was inherited from group
'PERMIT-ALL'
##
session-close;
}
}
}
}
The only thing strange is the warning above about "application or
application-set must be defined". It appears to be working, though,
otherwise I'd have no connectivity to the subnets behind the firewall.
What I'd like to do is be able to insert other policies before this one in
an economical way. Do you have an example of a commit script that might
do something similar, so I can see an example of what you're talking
about?
Thanks.
-John
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
