SRX Services Gateway
SRX Services Gateway

SRX IP exception through policy

08.30.11   |  
‎08-30-2011 07:17 PM

Hi All,


Have been having a good think about this and spent some time working out how to do this but have yet to have a bright idea.


Basically, after a easily manageable way to ignore/omit a smaller range of IPs within a supernet. There is a couple of ways I can achieve what I would like but would prefer it remain in policy.


This is basically one of the rules I'm having issues with:


address ra-vpn-pool

address hq-networks


policy hq_to_dr_db_network {
    match {
        source-address [ ra-vpn-pool hq-networks ];
        destination-address dr_db_tier-network;
        application [ junos-icmp-all junos-ssh ];
    then {
        log {





So in my problem with this is:

The SRX is actually the second tier firewall, the middle/app tier IP ranges are also within the 172.16/12 network, so if there is a lapse in policies the middle tier could potentially gain unauthorised access to the DB tier.

The Prod networks (connected via WAN service to the front end firewalls) also sit on 172.16/12 networks so they too due to a lapse in security (within the prod network) then get access through to the servers too.


What I was hoping for was to be able to negate a match for known networks on a this rule not block as there are  requirements where a app server needs ssh to a db server (yeah yeah I know, I don't like this, and this has been raised as a pointless procedure in having a firewall when this occurs). Something akin to "except" within a firewall rule.


My personal findings leads me to either:

1. Put the access rule right at the end, above this a deny rule from the known networks that shouldn't have access. Problem is ensuring this rule always gets applied last

2. Create a firewall filter and having this on the inbound interface to drop traffic specific to the known networks, this then means two places for rules and makes it quite confusing (considering other team members).

3. groups, my understanding at this point is that group rules would be applied at the very end which comes out something like 1 but without the risk.




Any thoughts would be appreciated







SRX Services Gateway

Re: SRX IP exception through policy

08.30.11   |  
‎08-30-2011 09:31 PM

So further reading confirms groups is the way to do it by the looks.


Adapting the techniques used by Stefan.


Would still have preferred to be able to do it in policy but looks to be the cleanest way of doing it.


Can I give kudos to myself? Smiley Happy




SRX Services Gateway

Re: SRX IP exception through policy

08.31.11   |  
‎08-31-2011 11:07 AM

This is one of those philosophical things.  There are mutliple ways you can achieve what you're looking for, as you've noted.  They'll all work, and none of them are technically "wrong."


My preference/suggestion is to use groups.  It's a little more work up-front, but I find it to be cleaner overall than modifying a default device behavior.


Even though the article you linked is titled "Alterting Default-Deny Behavior" it's not actually modifying the system's default-deny policy, it's again using groups to create a policy which is hit at the end of each set of security policies, which sounds like what you're looking to accomplish.  So, you are doing it in policies, you're just doing it more efficiently by using group statements rather than writing individual policies for each set of zones.


If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.