SRX

 View Only
Back to discussions
Expand all | Collapse all

Simple question regarding policy naming/use

  • 1.  Simple question regarding policy naming/use

    Posted 07-08-2025 03:45
    Edited by ae716 07-08-2025 04:14

    Would it be possible to create security policies and later attach them to zones when needed? I have done this on VyOS and it makes reading through the SET commands much easier. Here is an example:

    I would like to change the following:

    set security policies from-zone LAN to-zone LAN policy LAN-to-LAN match source-address any
set security policies from-zone LAN to-zone LAN policy LAN-to-LAN match destination-address any
set security policies from-zone LAN to-zone LAN policy LAN-to-LAN match application any
set security policies from-zone LAN to-zone LAN policy LAN-to-LAN then permit
set security policies from-zone LAN to-zone IoT policy LAN-to-IoT match source-address any
set security policies from-zone LAN to-zone IoT policy LAN-to-IoT match destination-address any
set security policies from-zone LAN to-zone IoT policy LAN-to-IoT match application any
set security policies from-zone LAN to-zone IoT policy LAN-to-IoT then permit
set security policies from-zone LAN to-zone GUEST policy LAN-to-GUEST match source-address any
set security policies from-zone LAN to-zone GUEST policy LAN-to-GUEST match destination-address any
set security policies from-zone LAN to-zone GUEST policy LAN-to-GUEST match application any
set security policies from-zone LAN to-zone GUEST policy LAN-to-GUEST then permit
set security policies from-zone LAN to-zone WORK policy LAN-to-WORK match source-address any
set security policies from-zone LAN to-zone WORK policy LAN-to-WORK match destination-address any
set security policies from-zone LAN to-zone WORK policy LAN-to-WORK match application any
set security policies from-zone LAN to-zone WORK policy LAN-to-WORK then permit
set security policies from-zone LAN to-zone WAN policy LAN-to-WAN match source-address any
set security policies from-zone LAN to-zone WAN policy LAN-to-WAN match destination-address any
set security policies from-zone LAN to-zone WAN policy LAN-to-WAN match application any
set security policies from-zone LAN to-zone WAN policy LAN-to-WAN then permit

    to this

    set security policies policy ALLOW_ALL match source-address any
set security policies policy ALLOW_ALL match destination-address any
set security policies policy ALLOW_ALL match application any
set security policies policy ALLOW_ALL then permit
set security policies from-zone LAN to-zone LAN policy ALLOW_ALL
set security policies from-zone LAN to-zone IoT policy ALLOW_ALL
set security policies from-zone LAN to-zone GUEST policy ALLOW_ALL
set security policies from-zone LAN to-zone WORK policy ALLOW_ALL



    Or would it even be possible to make it even shorter by doing something like this:

    set security policies policy ALLOW_ALL match source-address any
set security policies policy ALLOW_ALL match destination-address any
set security policies policy ALLOW_ALL match application any
set security policies policy ALLOW_ALL then permit
set security policies from-zone LAN to-zone {LAN IoT GUEST WORK} policy ALLOW_ALL

    Finally, I would like to create rules which are later attached to a zone when needed. For example:

    set security policies policy ALLOW_DNS match source-address 192.168.10.1/24 - 192.168.40.1/24
set security policies policy ALLOW_ALL match destination-address 192.168.10.110/32
set security policies policy ALLOW_ALL match application dns
set security policies policy ALLOW_ALL then permit

    and then attach them to zones when they become required:

    set security policies from-zone {LAN IoT GUEST WORK}  to-zone LAN policy ALLOW_DNS

    Again here are my questions:

    1) Would this concept work on Junos (SRX)?

    2) Please check if the syntax used is correct, e.g. multiple addresses (192.168.10.1/24, 192.168.20.1/24, 192.168.30.1/24 ...) and application name. 

    3) How to set the order of the rules if multiple policies are applied? 

    4) Can  do the same for nat rules? For example I would like to change:

    set security nat source rule-set LAN-to-WAN from zone LAN
set security nat source rule-set LAN-to-WAN to zone WAN
set security nat source rule-set LAN-to-WAN rule source-nat-rule_LAN match source-address 0.0.0.0/0
set security nat source rule-set LAN-to-WAN rule source-nat-rule_LAN then source-nat interface
set security nat source rule-set IoT-to-WAN from zone IoT
set security nat source rule-set IoT-to-WAN to zone WAN
set security nat source rule-set IoT-to-WAN rule source-nat-rule_IoT match source-address 0.0.0.0/0
set security nat source rule-set IoT-to-WAN rule source-nat-rule_IoT then source-nat interface
set security nat source rule-set GUEST-to-WAN from zone GUEST
set security nat source rule-set GUEST-to-WAN to zone WAN
set security nat source rule-set GUEST-to-WAN rule source-nat-rule_GUEST match source-address 0.0.0.0/0
set security nat source rule-set GUEST-to-WAN rule source-nat-rule_GUEST then source-nat interface
set security nat source rule-set WORK-to-WAN from zone WORK
set security nat source rule-set WORK-to-WAN to zone WAN
set security nat source rule-set WORK-to-WAN rule source-nat-rule_WORK match source-address 0.0.0.0/0
set security nat source rule-set WORK-to-WAN rule source-nat-rule_WORK then source-nat interface

    to something like this:

    set security nat source rule-set SOURCE_NAT_ALLOW_ALL match source-address 0.0.0.0/0
set security nat source rule-set SOURCE_NAT_ALLOW_ALL then source-nat interface
set security nat source rule-set SOURCE_NAT_ALLOW_ALL from zone LAN IoT GUEST WORK to zone WAN

    Thank you for your help. 



  • 2.  RE: Simple question regarding policy naming/use
    Best Answer

    Posted 07-08-2025 10:51

    1)

    Yes!!! This is one my favorite JunOS features -- Configuration Groups (see https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/configuration-groups-usage.html for lots of examples)!

    You can use groups not just for policies, but also for any part of the configuration where you may have lots of repetition.

    For security policies specifically, though, you also have the option to use global policies (https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/security-global-policies.html) and those support matching multiple zones at once. In JunOS a set of values is enclosed in [ ] rather than { }. Use the "?" when typing in commands to see available options -- when a set of values is supported, you will see "[" listed as an option.

    So, for policies you can do:

    set groups policy_group1 security policies from-zone <*> to-zone <*> policy allow-all /*blah blah blah*/
set security policies from-zone LAN to-zone WAN apply-groups policy_group1
set security policies from-zone IoT to-zone WAN apply-groups policy_group1

    Or

    set security policies global policy allow-all match from-zone [LAN IoT]
set security policies global policy allow-all match to-zone WAN
set security policies global policy allow-all /*blah blah blah*/

    Though, do read the documentation on global policies for caveats when it comes to mixing zone-based and global policies.

    2)

    Define addresses and address sets under security address-book and then use those named addresses (or address sets) in policies. You can specify more than one address in a policy with [ ]. The question mark is your friend, use it!

    3)
    Within a section where order matters (such as policies), they are processed in the order in which they appear. You can use the insert command to change the order. For example:

    {primary:node0}[edit security policies from-zone LAN to-zone WAN]
user@MY-DEVICE# insert policy some_policy before policy some_other_policy
   /*OR*/
user@MY-DEVICE# insert policy some_policy after policy some_other_policy

    4)

    Yes, NAT rule sets support matching multiple zones at once with the set definition [ ].



    ------------------------------
    Nikolay Semov
    ------------------------------

    Original Message


  • 3.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 18:55
    Edited by ae716 07-08-2025 19:13

    Hi Nicolay, thanks for the useful information. I will read into the groups topic. Just a quick question:

    On VyOS I did something like this, which I found to be very intuitive and easily readable.

    1) Creating just the rules:

    set firewall ipv4 name ACCEPT_ALL default-action 'accept'
set firewall ipv4 name ACCEPT_ICMP_AND_STATE default-action 'drop'
set firewall ipv4 name ACCEPT_ICMP_AND_STATE rule 5 action 'accept'
set firewall ipv4 name ACCEPT_ICMP_AND_STATE rule 5 description 'Allow EST/Related Traffic'
set firewall ipv4 name ACCEPT_ICMP_AND_STATE rule 5 state 'established'
set firewall ipv4 name ACCEPT_ICMP_AND_STATE rule 5 state 'related'
set firewall ipv4 name ACCEPT_ICMP_AND_STATE rule 20 action 'accept'
set firewall ipv4 name ACCEPT_ICMP_AND_STATE rule 20 description 'Allow ICMP'
set firewall ipv4 name ACCEPT_ICMP_AND_STATE rule 20 protocol 'icmp'
set firewall ipv4 name ACCEPT_ICMP_AND_STATE rule 20 state 'new'
set firewall ipv4 name ACCEPT_TRAFFIC_LAN_IoT default-action 'drop'
set firewall ipv4 name ACCEPT_TRAFFIC_LAN_IoT rule 5 action 'accept'
set firewall ipv4 name ACCEPT_TRAFFIC_LAN_IoT rule 5 description 'Allow LAN to IoT'
set firewall ipv4 name ACCEPT_TRAFFIC_LAN_IoT rule 5 destination address '192.168.20.0/24'
set firewall ipv4 name ACCEPT_TRAFFIC_LAN_IoT rule 5 source address '192.168.10.0/24'

    *) Please ignore the part of the ACCEPT_ICMP_AND_STATE rule which allows for established and related traffic back in. The SRX does that automatically and on VyOS I could also achieve this with two lines:

    set firewall global-options state-policy established action 'accept'
set firewall global-options state-policy related action 'accept'

    2) And then just apply the rules when needed: 

    set firewall zone GUEST default-action 'drop'
set firewall zone GUEST from ROUTER firewall name 'ACCEPT_ALL'
set firewall zone GUEST from WAN firewall name 'ACCEPT_ICMP_AND_STATE'
set firewall zone GUEST interface 'eth0.30'
set firewall zone IoT default-action 'drop'
set firewall zone IoT from LAN firewall name 'ACCEPT_TRAFFIC_LAN_IoT'
set firewall zone IoT from ROUTER firewall name 'ACCEPT_ALL'
set firewall zone IoT from WAN firewall name 'ACCEPT_ICMP_AND_STATE'
set firewall zone IoT interface 'eth0.20'
set firewall zone LAN default-action 'drop'
set firewall zone LAN from IoT firewall name 'ACCEPT_ICMP_AND_STATE'
set firewall zone LAN from ROUTER firewall name 'ACCEPT_ALL'
set firewall zone LAN from WAN firewall name 'ACCEPT_ICMP_AND_STATE'
set firewall zone LAN interface 'eth0'
set firewall zone ROUTER default-action 'drop'
set firewall zone ROUTER from GUEST firewall name 'ACCEPT_ALL'
set firewall zone ROUTER from IoT firewall name 'ACCEPT_ALL'
set firewall zone ROUTER from LAN firewall name 'ACCEPT_ALL'
set firewall zone ROUTER from WAN firewall name 'ACCEPT_ICMP_AND_STATE'
set firewall zone ROUTER from WORK firewall name 'ACCEPT_ALL'
set firewall zone ROUTER local-zone
set firewall zone WAN default-action 'drop'
set firewall zone WAN from GUEST firewall name 'ACCEPT_ALL'
set firewall zone WAN from IoT firewall name 'ACCEPT_ALL'
set firewall zone WAN from LAN firewall name 'ACCEPT_ALL'
set firewall zone WAN from ROUTER firewall name 'ACCEPT_ALL'
set firewall zone WAN from WORK firewall name 'ACCEPT_ALL'
set firewall zone WAN interface 'eth0.99'
set firewall zone WORK default-action 'drop'
set firewall zone WORK from ROUTER firewall name 'ACCEPT_ALL'
set firewall zone WORK from WAN firewall name 'ACCEPT_ICMP_AND_STATE'
set firewall zone WORK interface 'eth0.40'

    Would something like this be possible on the SRX? Without creating groups first?

    Thanks for your help.



    Original Message


  • 4.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 19:24

    No, not without groups.  The VyOS syntax mashes together packet-based filters with the concept of zones. While you can still define packet-based filters with set firewall <...> the newer flow-based security configuration in SRX does not define policies separately on their own like you can do in VyOS.  So you cannot achieve the same configuration style without using groups.

    Here are some translations using groups:

    set firewall ipv4 name ACCEPT_ALL default-action 'accept'

    becomes:

    set groups ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL match source-address any
set groups ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL match destination-address any
set groups ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL match application any
set groups ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL then permit

    You can take it a step further and do something like this:

    set groups src-any security policies from-zone <*> to-zone <*> policy <*> match source-address any
set groups dst-any security policies from-zone <*> to-zone <*> policy <*> match destination-address any
set groups app-any security policies from-zone <*> to-zone <*> policy <*> match application any
set groups action-permit security policies from-zone <*> to-zone <*> policy <*> then permit
set groups action-deny security policies from-zone <*> to-zone <*> policy <*> then deny
# --------
set groups ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL apply-groups [src-any dst-any app-any action-permit]

    And then you can reference these groups using apply-groups as much as you like as you write different policies. This makes the configuration really quite flexible.

    --------------------

    set firewall zone ROUTER local-zone

    Not needed. SRX has built-in zone junos-host

    -----------------------------------

    set firewall zone WAN interface 'eth0.99'

    becomes

    set security zones WAN interface ge-0/0/0.99

    --------------------------------------

    set firewall zone WAN from WORK firewall name 'ACCEPT_ALL'

    becomes

    set security policies from-zone WORK to-zone WAN apply-groups ALLOW_ALL

    -------------------------------------

    You can always display the resulting configuration using show | display inheritance and show | display inheritance no-comments 



    ------------------------------
    Nikolay Semov
    ------------------------------

    Original Message


  • 5.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 19:35

    Hi Nicolay, sorry for another question. I am still trying to understand your suggestion about creating groups (although I would prefer the way I have done this on VyOS as you can see from my other reply). 

    So, we still have the same policies: 

    set security policies from-zone LAN to-zone LAN policy LAN-to-LAN match source-address any
set security policies from-zone LAN to-zone LAN policy LAN-to-LAN match destination-address any
set security policies from-zone LAN to-zone LAN policy LAN-to-LAN match application any
set security policies from-zone LAN to-zone LAN policy LAN-to-LAN then permit
set security policies from-zone LAN to-zone IoT policy LAN-to-IoT match source-address any
set security policies from-zone LAN to-zone IoT policy LAN-to-IoT match destination-address any
set security policies from-zone LAN to-zone IoT policy LAN-to-IoT match application any
set security policies from-zone LAN to-zone IoT policy LAN-to-IoT then permit
set security policies from-zone LAN to-zone GUEST policy LAN-to-GUEST match source-address any
set security policies from-zone LAN to-zone GUEST policy LAN-to-GUEST match destination-address any
set security policies from-zone LAN to-zone GUEST policy LAN-to-GUEST match application any
set security policies from-zone LAN to-zone GUEST policy LAN-to-GUEST then permit
set security policies from-zone LAN to-zone WORK policy LAN-to-WORK match source-address any
set security policies from-zone LAN to-zone WORK policy LAN-to-WORK match destination-address any
set security policies from-zone LAN to-zone WORK policy LAN-to-WORK match application any
set security policies from-zone LAN to-zone WORK policy LAN-to-WORK then permit
set security policies from-zone LAN to-zone WAN policy LAN-to-WAN match source-address any
set security policies from-zone LAN to-zone WAN policy LAN-to-WAN match destination-address any
set security policies from-zone LAN to-zone WAN policy LAN-to-WAN match application any
set security policies from-zone LAN to-zone WAN policy LAN-to-WAN then permit
set security policies from-zone IoT to-zone WAN policy IoT-to-WAN match source-address any
set security policies from-zone IoT to-zone WAN policy IoT-to-WAN match destination-address any
set security policies from-zone IoT to-zone WAN policy IoT-to-WAN match application any
set security policies from-zone IoT to-zone WAN policy IoT-to-WAN then permit
set security policies from-zone GUEST to-zone WAN policy GUEST-to-WAN match source-address any
set security policies from-zone GUEST to-zone WAN policy GUEST-to-WAN match destination-address any
set security policies from-zone GUEST to-zone WAN policy GUEST-to-WAN match application any
set security policies from-zone GUEST to-zone WAN policy GUEST-to-WAN then permit
set security policies from-zone WORK to-zone WAN policy WORK-to-WAN match source-address any
set security policies from-zone WORK to-zone WAN policy WORK-to-WAN match destination-address any
set security policies from-zone WORK to-zone WAN policy WORK-to-WAN match application any
set security policies from-zone WORK to-zone WAN policy WORK-to-WAN then permit

    Would I be right in my assumption, that we can write this as the following (using groups)?

    set groups GROUP_ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL match source-address any
set groups GROUP_ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL match destination-address any
set groups GROUP_ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL match application any
set groups GROUP_ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL then permit
set security policies from-zone LAN to-zone [LAN IoT GUEST WORK WAN] apply-groups GROUP_ALLOW_ALL
set security policies from-zone [IoT GUEST WORK] to-zone WAN apply-groups GROUP_ALLOW_ALL


    ------------------------------
    Eric Akimoto
    ------------------------------

    Original Message


  • 6.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 19:44
    Edited by Nikolay Semov 07-08-2025 19:45

    No. I understand you prefer the VyOS syntax, but while SRX configuration looks similar, the JunOS configuration syntax is not the same as in VyOS. 

    You can only match multiple zones at once when using global policies (see the documentation link in my first response), like this:

    set groups GROUP_ALLOW_ALL security policies global policy <*> match source-address any
set groups GROUP_ALLOW_ALL security policies global policy <*> match destination-address any
set groups GROUP_ALLOW_ALL security policies global policy <*> match application any
set groups GROUP_ALLOW_ALL security policies global policy <*> then permit
# # #
set security policies global policy FROM_LAN match from-zone LAN 
set security policies global policy FROM_LAN match to-zone [LAN IoT GUEST WORK WAN]
set security policies global policy FROM_LAN apply-groups GROUP_ALLOW_ALL
# # #
set security policies global policy TO_WAN match from-zone [IoT GUEST WORK] 
set security policies global policy TO_WAN match to-zone WAN 
set security policies global policy TO_WAN apply-groups GROUP_ALLOW_ALL



    ------------------------------
    Nikolay Semov
    ------------------------------

    Original Message


  • 7.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 20:19
    Edited by ae716 07-08-2025 20:33

    Nicolay, thanks for your explanation. I understand that I have to deal with a new syntax so I am willing to learn the best practices for writing rules on Junos.
    Just to make sure I'm not missing anything, I could write the current rules as either

    ##NOT USING GLOBAL POLICIES
set groups GROUP_ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL match source-address any
set groups GROUP_ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL match destination-address any
set groups GROUP_ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL match application any
set groups GROUP_ALLOW_ALL security policies from-zone <*> to-zone <*> policy ALLOW_ALL then permit
set security policies from-zone LAN to-zone LAN apply-groups GROUP_ALLOW_ALL
set security policies from-zone LAN to-zone IoT apply-groups GROUP_ALLOW_ALL
set security policies from-zone LAN to-zone GUEST apply-groups GROUP_ALLOW_ALL
set security policies from-zone LAN to-zone WORK apply-groups GROUP_ALLOW_ALL
set security policies from-zone LAN to-zone WAN apply-groups GROUP_ALLOW_ALL
set security policies from-zone IoT to-zone WAN apply-groups GROUP_ALLOW_ALL
set security policies from-zone GUEST to-zone WAN apply-groups GROUP_ALLOW_ALL
set security policies from-zone WORK to-zone WAN apply-groups GROUP_ALLOW_ALL

    or as 

    ##USING GLOBAL POLICIES##
set groups GROUP_ALLOW_ALL security policies global policy <*> match source-address any
set groups GROUP_ALLOW_ALL security policies global policy <*> match destination-address any
set groups GROUP_ALLOW_ALL security policies global policy <*> match application any
set groups GROUP_ALLOW_ALL security policies global policy <*> then permit
# # #
set security policies global policy FROM_LAN match from-zone LAN 
set security policies global policy FROM_LAN match to-zone [LAN IoT GUEST WORK WAN]
set security policies global policy FROM_LAN apply-groups GROUP_ALLOW_ALL
# # #
set security policies global policy TO_WAN match from-zone [IoT GUEST WORK] 
set security policies global policy TO_WAN match to-zone WAN 
set security policies global policy TO_WAN apply-groups GROUP_ALLOW_ALL

    Would that be correct? I am also getting confused with the terminology of groups, sets, etc. For example when it comes to policies, I might be able to use the above example. But when I look at the (source) NAT section of my set config, it uses the term "rule-set" instead of using the same syntax as in set security policies. Is there a specific reason for this? Also with this source nat rules, would there be a shorter way of writing them? I figured out that I had to assign a different rule name for each zone otherwise I could not commit the configuration. 

    set security nat source rule-set LAN-to-WAN from zone LAN
set security nat source rule-set LAN-to-WAN to zone WAN
set security nat source rule-set LAN-to-WAN rule source-nat-rule_LAN match source-address 0.0.0.0/0
set security nat source rule-set LAN-to-WAN rule source-nat-rule_LAN then source-nat interface
set security nat source rule-set IoT-to-WAN from zone IoT
set security nat source rule-set IoT-to-WAN to zone WAN
set security nat source rule-set IoT-to-WAN rule source-nat-rule_IoT match source-address 0.0.0.0/0
set security nat source rule-set IoT-to-WAN rule source-nat-rule_IoT then source-nat interface
set security nat source rule-set GUEST-to-WAN from zone GUEST
set security nat source rule-set GUEST-to-WAN to zone WAN
set security nat source rule-set GUEST-to-WAN rule source-nat-rule_GUEST match source-address 0.0.0.0/0
set security nat source rule-set GUEST-to-WAN rule source-nat-rule_GUEST then source-nat interface
set security nat source rule-set WORK-to-WAN from zone WORK
set security nat source rule-set WORK-to-WAN to zone WAN
set security nat source rule-set WORK-to-WAN rule source-nat-rule_WORK match source-address 0.0.0.0/0
set security nat source rule-set WORK-to-WAN rule source-nat-rule_WORK then source-nat interface

    I am really sorry for bothering you with all these questions but while I am not new to networking, I am having a hard time understanding some aspects of Junos. Anyways, thank you for your patience.



    ------------------------------
    Eric
    ------------------------------

    Original Message


  • 8.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 20:33

    Yes, apply-groups GROUP_ALLOW_ALL, but yes, either way is fine. You can even mix the two if you like, though keep in mind that if you have a matching zone-based policy, it will take precedence over global policy.

    As for NAT, I'm not sure why the difference; I guess if you look at it on its own, it's alright.

    Each NAT rule-set can match multiple zones with [ ], so you don't have to split them up so much, but yes, each rule needs a unique name even if it's in a separate rule-set. I guess internally the NAT rule names are used as a key, so it needs to be unique, while security policies all get index numbers upon commit so the names can repeat.



    ------------------------------
    Nikolay Semov
    ------------------------------

    Original Message


  • 9.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 20:40
    Edited by ae716 07-08-2025 20:46

    So that means I could put all of the above source nat rules into a simple block like so: ?

    set security nat source rule-set SOURCE-NAT-TO-WAN from zone [LAN IoT GUEST WORK] 
set security nat source rule-set SOURCE-NAT-TO-WAN to zone WAN
set security nat source rule-set SOURCE-NAT-TO-WAN rule ALLOW_ALL_SOURCE_ADDRESSES match source-address 0.0.0.0/0
set security nat source rule-set SOURCE-NAT-TO-WAN rule ALLOW_ALL_SOURCE_ADDRESSES then source-nat interface



    ------------------------------
    Eric
    ------------------------------

    Original Message


  • 10.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 20:47

    Mhmm, yep.



    ------------------------------
    Nikolay Semov
    ------------------------------

    Original Message


  • 11.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 21:42

    Great Nicolay! The above works very well! Thank you for your help.

    If I was to add another rule  for let's say maybe a local DNS server, could I just do something like this:

    #Set a group to allow access to a local DNS server
set groups GROUP_ALLOW_DNS security policies from-zone <*> to-zone <*> policy ALLOW_DNS_1 match source-address any
set groups GROUP_ALLOW_DNS security policies from-zone <*> to-zone <*> policy ALLOW_DNS_1 match destination-address 192.168.10.110/32
set groups GROUP_ALLOW_DNS security policies from-zone <*> to-zone <*> policy ALLOW_DNS_1 match application junos-dns
set groups GROUP_ALLOW_DNS security policies from-zone <*> to-zone <*> policy ALLOW_DNS_1 then permit

#Apply group to policy
set security policies from-zone IoT to-zone LAN apply-groups GROUP_ALLOW_DNS
set security policies from-zone GUEST to-zone LAN apply-groups GROUP_ALLOW_DNS
...

*The goal is to allow hosts in zones "IoT"and "GUEST" who usually don't have access to zone LAN to reach a DNS server 
that is located in zone "LAN" only on port 53


    ------------------------------
    Eric
    ------------------------------

    Original Message


  • 12.  RE: Simple question regarding policy naming/use

    Posted 07-08-2025 23:35

    Yes, that looks alright.



    ------------------------------
    Nikolay Semov
    ------------------------------

    Original Message


  • 13.  RE: Simple question regarding policy naming/use

    Posted 07-09-2025 01:07
    Edited by ae716 07-09-2025 02:58

    I have tested the above configuration and it gives me the following error after loading the set:

    [edit security policies from-zone WORK to-zone LAN]
  'policy ALLOW_DNS_1'
    warning: Destination address or address_set (192.168.10.110/32) not found. Please check if it is a SecProfiling Feed.

*from-zone WORK is an example, the same error comes up for any other zone where I have configured this policy

    NOTE: This article suggests that creating an address book could prevent this warning, even though somewhere else I read that an address book is not strictly necessary Here's the link to the article (Juniper Support Portal)

    Besides this, I have just tried to change the name server for the LAN DHCP (which should be reachable from LAN clients)

    from this:
set access address-assignment pool LAN_DHCP_POOL family inet network 192.168.10.0/24
set access address-assignment pool LAN_DHCP_POOL family inet range junosRange low 192.168.10.2
set access address-assignment pool LAN_DHCP_POOL family inet range junosRange high 192.168.10.99
set access address-assignment pool LAN_DHCP_POOL family inet dhcp-attributes router 192.168.10.1
set access address-assignment pool LAN_DHCP_POOL family inet dhcp-attributes name-server 1.1.1.1
set access address-assignment pool LAN_DHCP_POOL family inet dhcp-attributes propagate-settings irb.1

to this:
set access address-assignment pool LAN_DHCP_POOL family inet network 192.168.10.0/24
set access address-assignment pool LAN_DHCP_POOL family inet range junosRange low 192.168.10.2
set access address-assignment pool LAN_DHCP_POOL family inet range junosRange high 192.168.10.99
set access address-assignment pool LAN_DHCP_POOL family inet dhcp-attributes router 192.168.10.1
set access address-assignment pool LAN_DHCP_POOL family inet dhcp-attributes name-server 192.168.10.110
set access address-assignment pool LAN_DHCP_POOL family inet dhcp-attributes propagate-settings irb.1

    But even after restarting the dhcp server, the changes do not propagate to the client. 

    I might need to say that I have configured 1.1.1.1 as the system dhcp 

    set system name-server 1.1.1.1

    But this should not be name server that is given out to the clients, right?

    Might also need to mention that I have the following in my set config:

    set system services dhcp-local-server group jdhcp-group interface irb.1
set system services dhcp-local-server group jdhcp-group interface irb.20
set system services dhcp-local-server group jdhcp-group interface irb.30
set system services dhcp-local-server group jdhcp-group interface irb.40

    Could it be that those entries are causing the issue? Should I remove them since I have the following as well:

    set access address-assignment pool LAN_DHCP_POOL family inet network 192.168.10.0/24
set access address-assignment pool LAN_DHCP_POOL family inet range junosRange low 192.168.10.2
set access address-assignment pool LAN_DHCP_POOL family inet range junosRange high 192.168.10.99
set access address-assignment pool LAN_DHCP_POOL family inet dhcp-attributes router 192.168.10.1
set access address-assignment pool LAN_DHCP_POOL family inet dhcp-attributes name-server 192.168.10.110
set access address-assignment pool LAN_DHCP_POOL family inet dhcp-attributes propagate-settings irb.1
set access address-assignment pool IoT_DHCP_POOL family inet network 192.168.20.0/24
set access address-assignment pool IoT_DHCP_POOL family inet range junosRange low 192.168.20.2
set access address-assignment pool IoT_DHCP_POOL family inet range junosRange high 192.168.20.99
set access address-assignment pool IoT_DHCP_POOL family inet dhcp-attributes router 192.168.20.1
set access address-assignment pool IoT_DHCP_POOL family inet dhcp-attributes name-server 192.168.10.110
set access address-assignment pool IoT_DHCP_POOL family inet dhcp-attributes propagate-settings irb.20
set access address-assignment pool GUEST_DHCP_POOL family inet network 192.168.30.0/24
set access address-assignment pool GUEST_DHCP_POOL family inet range junosRange low 192.168.30.2
set access address-assignment pool GUEST_DHCP_POOL family inet range junosRange high 192.168.30.99
set access address-assignment pool GUEST_DHCP_POOL family inet dhcp-attributes router 192.168.30.1
set access address-assignment pool GUEST_DHCP_POOL family inet dhcp-attributes name-server 192.168.10.110
set access address-assignment pool GUEST_DHCP_POOL family inet dhcp-attributes propagate-settings irb.30
set access address-assignment pool WORK_DHCP_POOL family inet network 192.168.40.0/29
set access address-assignment pool WORK_DHCP_POOL family inet range junosRange low 192.168.40.2
set access address-assignment pool WORK_DHCP_POOL family inet range junosRange high 192.168.40.6
set access address-assignment pool WORK_DHCP_POOL family inet dhcp-attributes router 192.168.40.1
set access address-assignment pool WORK_DHCP_POOL family inet dhcp-attributes name-server 192.168.10.110
set access address-assignment pool WORK_DHCP_POOL family inet dhcp-attributes propagate-settings irb.40



    ------------------------------
    Eric
    ------------------------------

    Original Message


  • 14.  RE: Simple question regarding policy naming/use

    Posted 07-09-2025 08:22

    I missed that part of your configuration yesterday. Yes, addresses need to be defined in an address book attached to the corresponding zone. Note that you can attach an address book to more than one zone, and you have a global address book, so you can organize addresses however you like.

    As for DHCP, the new name server you specified should be seen by clients when they renew their leases. Your configuration doesn't specify the lease time and I don't remember what the default is. Clients usually renew their leases automatically at half the lease time. Try restarting DHCP clients rather than the DHCP server.

    Also, the propagate-settings option expects an interface that's using DHCP client, not the interface where the DHCP server is listening. The idea is that if SRX uses DHCP to obtain an address and various DHCP settings from an upstream DHCP server, you may want to propagate those settings to the SRX's DHCP clients. This doesn't seem to be the case in your situation, so you don't need that statement in there.



    ------------------------------
    Nikolay Semov
    ------------------------------

    Original Message


  • 15.  RE: Simple question regarding policy naming/use

    Posted 07-09-2025 08:44

    I was experiencing a few network issues since this morning when I connected a switch to which a Proxmox host was connected to the SRX. It took me a few hours to realize that the VyOS VM was still running on it so I had two routers in the same network, all with the same VLANS, subnets and DNS settings. I suspect that this was the issue with the DHCP server not updating the DNS server. Pretty stupid mistake. 
    I will try again again tomorrow with an address book and I will remove the propagate statement as well and let you know what happened. 



    ------------------------------
    Eric
    ------------------------------

    Original Message


  • 16.  RE: Simple question regarding policy naming/use

    Posted 07-09-2025 13:36

    I'm not sure jow helpful this is but think of apply-groups as an instruction to merge two configurations at time of commit. JunOS takes matching configuration from the specified group and inserts it at the place where you put apply-groups.

    Here's an extreme example of non-matching configuration:

    Set groups MYGROUP system host-name blahblahblah

    Set security apply-groups MYGROUP 

    The won't do anything because the group only has configuration for system, and apply-groups is under security.

    Set system apply-groups MYGROUP 

    And

    Set apply-groups MYGROUP 

    would both work, and set the host-name to blahblahblah because the group configuration has commands matching the place where apply-groups appears.



    ------------------------------
    Nikolay Semov
    ------------------------------

    Original Message


  • 17.  RE: Simple question regarding policy naming/use

    Posted 07-09-2025 19:45

    I can confirm that adding the global address book got rid of the warning when loading the set configuration:

    set security address-book global address DNS-SERVER-1 192.168.10.110/32
set groups GROUP_ALLOW_DNS security policies from-zone <*> to-zone <*> policy ALLOW_DNS_1 match source-address any
set groups GROUP_ALLOW_DNS security policies from-zone <*> to-zone <*> policy ALLOW_DNS_1 match destination-address DNS-SERVER-1
set groups GROUP_ALLOW_DNS security policies from-zone <*> to-zone <*> policy ALLOW_DNS_1 match application junos-dns-udp
set groups GROUP_ALLOW_DNS security policies from-zone <*> to-zone <*> policy ALLOW_DNS_1 then permit
set security policies from-zone IoT to-zone LAN apply-groups GROUP_ALLOW_DNS
set security policies from-zone GUEST to-zone LAN apply-groups GROUP_ALLOW_DNS
set security policies from-zone WORK to-zone LAN apply-groups GROUP_ALLOW_DNS

set access address-assignment pool IoT_DHCP_POOL family inet network 192.168.20.0/24
set access address-assignment pool IoT_DHCP_POOL family inet range junosRange low 192.168.20.2
set access address-assignment pool IoT_DHCP_POOL family inet range junosRange high 192.168.20.99
set access address-assignment pool IoT_DHCP_POOL family inet dhcp-attributes router 192.168.20.1
set access address-assignment pool IoT_DHCP_POOL family inet dhcp-attributes name-server 192.168.10.110
.....
.....

    This will work with or without the propagate statement mentioned earlier, but I have removed it anyways. Thanks for your help!

    Allow me a last question regarding the address book. I have created the global address book 

    set security address-book global address DNS-SERVER-1 192.168.10.110/32

    1) Can I also add other entries to it like for example adding a Web Server and use them in other security policies?

    set security address-book global address DNS-SERVER-1 192.168.10.110/32
set security address-book global address WEB-SERVER-1 192.168.10.120/32
set security address-book global address WEB-SERVER-2 192.168.10.130/32

    2) Can I use the DNS-SERVER-1 entry in this case as well:

    [Current Config]
set access address-assignment pool IoT_DHCP_POOL family inet dhcp-attributes name-server 192.168.10.110

[Would like to change to this]
set access address-assignment pool IoT_DHCP_POOL family inet dhcp-attributes name-server DNS-SERVER-1

    So in case the DNS server IP address would change in the future, I would just need to change it in the address book, right?

    Thanks!



    ------------------------------
    Eric
    ------------------------------

    Original Message


  • 18.  RE: Simple question regarding policy naming/use

    Posted 07-10-2025 00:25

    1) By all means, add as many addresses as you like. Keep in mind that besides CIDR notation, you can also use ranges, wildcards, and dns names when defining addresses.

    2) Alas, no. Address book entries can only be used in security policies, and, with some restrictions and caveats, in destination NAT.



    ------------------------------
    Nikolay Semov
    ------------------------------

    Original Message


  • 19.  RE: Simple question regarding policy naming/use

    Posted 07-10-2025 02:58
    Edited by ae716 07-10-2025 06:40

    Ok, so that means I shouldn't look at the global address book as a database  to store IPs/CIDR notations as variables, since the use case is limited to policies and NAT. Now that brings up another question: Destination NAT. I have read a bit into how it is implemented on Junos but most articles are mentioning POOLS for storing IP addresses. Are those really required?  So DNAT doesn't use the address book, but an address POOL? The WAN interface will have a dynamically changing IP address, not a static one as most articles suggest.

    The basic concept of a simple DNAT configuration  to me would be something like this (in VyOS but the logic would be the same I guess)

    set nat destination rule 5 description "DNAT port 80"
set nat destination rule 5 inbound-interface eth0.99
set nat destination rule 5 destination address 0.0.0.0/0 
set nat destination rule 5 translation address 192.168.10.120/32
set nat destination rule 5 protocol tcp
set nat destination rule 5 destination port 80

set nat destination rule 10 description "DNAT port 443"
set nat destination rule 10 inbound-interface eth0.99
set nat destination rule 10 destination address 0.0.0.0/0 
set nat destination rule 10 translation address 192.168.10.120/32
set nat destination rule 10 protocol tcp
set nat destination rule 10 destination port 443

    How could this be accomplished on the SRX? I would be able to write the policy for the WAN-LAN traffic with the WEB-SERVER-1  entry I have in my global address book I guess. 

    Here is the part sans the DNAT settings

    ##Adding entry for Web-Server to global addres book
set security address-book global address WEB-SERVER-1 192.168.10.120/32

##Creating policy rules
set groups GROUP_ALLOW_HTTP security policies from-zone <*> to-zone <*> policy ALLOW_HTTP match source-address any
set groups GROUP_ALLOW_HTTP security policies from-zone <*> to-zone <*> policy ALLOW_HTTP match destination-address WEB-SERVER-1
set groups GROUP_ALLOW_HTTP security policies from-zone <*> to-zone <*> policy ALLOW_HTTP match application junos-http
set groups GROUP_ALLOW_HTTP security policies from-zone <*> to-zone <*> policy ALLOW_HTTP then permit
set groups GROUP_ALLOW_HTTPS security policies from-zone <*> to-zone <*> policy ALLOW_HTTPS match source-address any
set groups GROUP_ALLOW_HTTPS security policies from-zone <*> to-zone <*> policy ALLOW_HTTPS match destination-address WEB-SERVER-1
set groups GROUP_ALLOW_HTTPS security policies from-zone <*> to-zone <*> policy ALLOW_HTTPS match application junos-https
set groups GROUP_ALLOW_HTTPS security policies from-zone <*> to-zone <*> policy ALLOW_HTTPS then permit

##Asign policies to interfaces
set security policies from-zone WAN to-zone LAN apply-groups GROUP_ALLOW_HTTP
set security policies from-zone WAN to-zone LAN apply-groups GROUP_ALLOW_HTTPS

    And here is an attempt at writing those destination nat rules for Junos. Would they be OK?

    set security nat destination pool WEBSERVER address 192.168.1.120/32
set security nat destination rule-set DNAT from zone WAN
set security nat destination rule-set DNAT rule RULE1 match destination-address 0.0.0.0/0
set security nat destination rule-set DNAT rule RULE1 match destination-port 80
set security nat destination rule-set DNAT rule RULE1 match destination-port 443
set security nat destination rule-set DNAT rule RULE1 then destination-nat pool WEBSERVER

    UPDATE 7/10 6:26PM: Tested and not working

    UPDATE 7/10 6:30PM: Tested and WORKING *The IP in pool WEBSERVER was wrong: It was supposed to be 192.168.10.120/32

    Thanks



    ------------------------------
    Eric
    ------------------------------

    Original Message