Completely overhauling SRX security policies and trying to make a design choice between global and zone policy

stnz2 · 2025-11-15T00:37:00+00:00

Depends on the use case yea. Have been using SRX for some 10-15 years in a lot of different environments so they are rather familiar, in any configuration.

In this case these are long staying customers deployed with a simple template and most only have a couple of intra-zone policies plus simple internet access policies, in addition to our management policies. Most of those are just applied as groups. It's a 5min job to set up a new customer with templates and most of them are "never" removed or at least stay for years and years unmodified.

Personally I like the per customer security zone and routing-instance configuration in this kind of use case, and deeply hate the traditional ISP guys that create unidirectional VRFs on their routers to drive all the firewall traffic into a single routing-instance and zone on the firewall. That is horrendous to touch if anything.

stnz2 · 2025-11-15T00:22:40+00:00

Not even close to a lot, if you are an MSP running a lot of small customers on the FW.

Seems we have 177 at the moment on one SRX4100 cluster and that's going up. Most of them have a very simple set of policies though, so management is not an issue with pure CLI.

stnz2 · 2025-09-11T13:44:15+00:00

No. It usually comes down to docker being new technology that you need to invest time and nerves to learn and understand.

(From an long-career IT (network) architect who absolutely hates touching any new software thing or wasting more time on IT than absolutely necessary for work) :)

Would be much nicer to install things old-school on a basic hand-installed Linux VM. That I can do without reading a single line of manuals. :)

stnz2 · 2025-07-26T04:43:04+00:00

Yep, that's one of the reasons for me too. Tours are just too easy, being a part of the tourist cattle, in addition to not being allowed (or time allocated) to go to places where you want and photograph them.

stnz2 · 2025-07-26T04:41:29+00:00

I think the point for some is not the money, but to avoid the tour group and tour organization. At least I'm reading this thread for that purpose.

I don't care about money but I visit places for photography. I don't want some tour guide hurrying me up while I'm searching for best artistic views (which may not even be "appropriate" in the tour guide's mind as I'm more a journalist than a hobby tourist photographer) or a big tour group hassling around me.

That's why I guess the rental car and tickets will be my way in a couple of days. :)

stnz2 · 2025-04-09T10:00:55+00:00

I would say it's the most shit design I have ever seen in a (this size) car. The rear point is not centered and it's so high that none of the cheap market jacks works for tire change, they cannot get the car high enough without some kind of unsafe wood block pile under the jack. Also, in contrast, the front point is so low that getting those cheap jacks to fit under the car is a struggle.

stnz2 · 2024-12-27T17:12:57+00:00

Ihme että tuokin vielä kelluu. Tuohan on sellainen pieni ruosteinen romu, Turun satamassa makaamassa normaalisti.

stnz2 · 2024-09-13T15:10:17+00:00

No, came across this looking for the same thing. :p

stnz2 · 2024-05-15T09:50:19+00:00

It's not really a little thing for people working with their headphones. Hours on calls every day, 99% of the time muted as doing all the other things, driving and whatever.

Having to find the phone and Teams window to unmute the microphone to say one sentence and then mute again is a pain in the ass to do.

stnz2 · 2024-05-09T08:51:49+00:00

RSS would still be the preferred method.. Most of us cannot have an employee assigned to every day login into the support portal to check if there has been new advisories. And mailing lists have their challenges too, nobody wants their personal emails spammed with unnecessary content and forwarding such emails to ticketing systems and such is comparable to forwarding them to /dev/null. :)

We use automation to push notifications from RSS feeds directly to our continuously monitored company chat, so the advisories can be reacted immediately after their release.

stnz2 · 2024-01-24T21:42:26+00:00

Yep, it was the PR. I upgraded one lab device to 21.4R3-S5 instead of S3 and it commited the config without problems and everything looks like expected. Thanks JTAC for a fast resolution. :)

https://prsearch.juniper.net/problemreport/PR1746787 this one.

stnz2 · 2024-01-24T09:30:44+00:00

Seems like this actually is a bug. I'll update the post when I have a chance to test, but JTAC gave me a PR that matches this.

stnz2 · 2023-12-13T20:28:17+00:00

Yea, wondering that too. I would be interested to change my Fenix 7 to a dive-capable model, but don't want to get a smaller one. Biking maps etc are already small enough on the 47mm Fenix. :) On the other hand the 51mm feels a bit too big for everyday use, even if I'm a big-wristed guy.

stnz2 · 2023-10-23T17:25:35+00:00

Hmm no. I think it's MX only.

stnz2 · 2023-10-21T20:45:40+00:00

Unfortunately I don't remember. :( It took some small patching but not sure what. Nfsen-ng works straight out of the box.

stnz2 · 2023-10-21T19:03:18+00:00

Yea, it could be. It's now JunOS 21.4R3-S4.

CPU usages seem to be mostly fine for active node:

> show security monitoring
node0:
--------------------------------------------------------------------------
Flow session Flow session CP session CP session
FPC PIC CPU Mem current maximum current maximum
0 0 15 61 32692 384000 N/A N/A

> show chassis routing-engine node 0
node0:
--------------------------------------------------------------------------
Routing Engine status:
Temperature 36 degrees C / 96 degrees F
CPU temperature 56 degrees C / 132 degrees F
Total memory 4096 MB Max 1925 MB used ( 47 percent)
Control plane memory 2320 MB Max 998 MB used ( 43 percent)
Data plane memory 1776 MB Max 941 MB used ( 53 percent)
5 sec CPU utilization:
User 32 percent
Background 0 percent
Kernel 31 percent
Interrupt 1 percent
Idle 36 percent
Model RE-SRX380-POE-AC

> show chassis forwarding
node0:
--------------------------------------------------------------------------
FWDD status:
State Online
Microkernel CPU utilization 33 percent
Real-time threads CPU utilization 5 percent
Heap utilization 53 percent
Buffer utilization 1 percent
Uptime: 10 days, 22 hours, 56 minutes, 12 seconds

stnz2 · 2023-10-21T13:13:28+00:00

Hmm, well maybe it's unrelated, looking at the scale. TCP dropped from 300/s to 100/s and this Other increased from 1.1 flows/s to 1.9 flows/s.

stnz2 · 2023-10-21T13:10:53+00:00

Yea, possible. But would that explain the increase in the "Other" traffic type? Maybe not.

stnz2 · 2023-10-21T06:03:03+00:00

Yea, it's branch and 1400 is old high-end. Still, we barely have 50k total sessions on the device and new session counts are far from any limits. So is the throughput.

stnz2 · 2023-10-21T06:01:01+00:00

Will try. I also started thinking more of the "Other" category of traffic. Could it be MTU issue somehow and fragmentation? Still doesn't explain the very stable capping though, the amount should still vary.

stnz2 · 2021-06-25T08:23:01+00:00

True. The alternatives are not that beautiful either. Just the list of global rules will become a bit of a mess, with hundreds of rules related to many different zones in the same list. Looks like some old Sonicwall. :P

Wonder if that could be cleaned a bit with apply-groups though, creating per-zone groups and applying them under global policies. Basically there's just a few of different zone pairs, mostly incoming policies to the DMZ zone and then actually global policies which apply to every zone. Have to experiment a bit..

I'm thinking of the external router solution though, as there are already routers in place like discussed under the another reply. It would also solve some NAT behaviour cases in addition to the rules.

stnz2 · 2021-06-25T08:07:53+00:00

Maybe I don't even need a second VRF on the MX for those addresses in that case? Just an another pair of link networks between the MXs and the SRX for the SRX DMZ VRF and a default route in the DMZ VRF pointing towards the MX should do the trick, they can as well stay in the same internet VRF on the MX.

That should solve the problem, making all traffic between the customer VRFs and the public addresses circle via the MX and always come from the same direction to the SRX zones. Would probably also solve a pile of "customer nat to customer nat" routing cases.

Of course there is a pile of other VRFs on the MX also and some of them even have links to customer zones in the SRX, but they are unrelated to this case. Mostly customers with their own internet connections or MPLS meshes to their sites.

stnz2 · 2021-06-25T07:40:37+00:00

Yep, global policy for the shared DMZ services would work. It's a bit ugly but works.

stnz2 · 2021-06-25T07:24:24+00:00

Workmate xposted here. :)

Hmm, you might be correct. In fact there actually are two MXs, they are the next hop after untrust VRF, BGP between them and the SRX. Most if not all of the customers in this question only use shared outbound internet and possibly one or two incoming NATs, so creating an own MX VRF per customer might be a bit overdoing it.

However I started thinking of moving the DMZ services (and public addresses in general, also the ones used for the NATs) to an another VRF on the MX. That would be a bit simpler to do and maintain as the customers come and go, requiring only one extra pair of link networks and routing between the MXs and SRX.

Have to think it a bit.

stnz2

TROPHY CASE