Category Archives: policies

Global policy count in SRX

As far as I know there is no single command to enable policy count option globally but you can do it via a group statement.
Be aware that policy count is a performance affecting feature, so think twice if your traffic volume is high. Here is how we can do it;

Once you apply this group, you can check any policy to see the policy counters;

You can see that policy statistics are enabled. When you check for other policies, you will see that it is enabled for all.

SRX for beginners

I was thinking if I should write a short article for beginners to quickly configure an SRX firewall. I don’t know how many people will find it useful but I hope it will be for those who use SRX for the first time in their life. Let’s get started.

Our topology in this tutorial is below;

srx_beginner
We will configure the followings from scratch:

  1. Loading default config and setting the root password
  2. Configuring interfaces and default route
  3. Configuring security zones
  4. Configuring address book entries
  5. Creating security policies
  6. Creating source nat for internal clients

Continue reading

Bypassing flow daemon in SRX

Under normal circumstances if you have a policy from trust zone to transit zone in a network like in the diagram and if you create traffic, packets have to be processed by flow daemon after which a session is created. What if you want to bypass this daemon and only use the packet mode for the traffic only between these nodes. Below is how I configure my SRX100 device for this. After configuring this way, I didn’t see any session created. Let’s configure;

Continue reading

allow traceroute in SRX or not

If you have a restricted policy that you have enforced for your internal clients but you want to allow traceroute requests from your internal clients towards another network you can do it as follows I suppose. You can create the following application and apply it on your security policy.

I took port range from wikipedia for traceroute. When you test from a linux client (I think windows is using icmp instead), you will see UDP requests destination port of which start from 33434. So far good. Once you set this application inside the policy, clients are allowed to use traceroute from their linux clients but should we really allow this? I think no. Look what happens in the session flow if you allow this traceroute:

In my linux client, I saw 13 hops after my traceroute which itself created 27 flow sessions in my SRX as it is UDP, session timeout is 60 seconds but anyway. It is better not to allow traceroute even from internal clients! or you can reduce the inactivity-timeout of this custom traceroute application.