# Security Zone Unexpected Behaviour

**URL:** <https://forum.inductiveautomation.com/t/security-zone-unexpected-behaviour/73752>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [May 15, 2023, 10:35pm UTC](https://forum.inductiveautomation.com/t/security-zone-unexpected-behaviour/73752 "2023-05-15T22:35:04Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mitchell\_Knights](https://avatars.discourse-cdn.com/v4/letter/m/e68b1a/32.png) [@Mitchell\_Knights](https://forum.inductiveautomation.com/u/Mitchell_Knights)\
**Post date:** [May 15, 2023, 10:35pm UTC](https://forum.inductiveautomation.com/t/security-zone-unexpected-behaviour/73752/1 "2023-05-15T22:35:04Z")

</div>

Hi all,

I'm currently developing my first Ignition Perspective project after years of working extensively with CitectSCADA and I've came across some unexpected behaviour when trying to implement a security zone for a rail loadout.

I've setup a security zone on the loadout gateway, with an IP range of 172.24.8.100-101. Which corresponds to the loadout IP range on the network that should have full control.

 ![Global var diffs44](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/3/b39ec1b2f3afb8cfe48b5c0e01a3cfb3750ad8c4.png)

I've set the loadout zones security services to have a higher priority than the default zone, with full control permissions for all services. I've set the default zone to be read only for all services and disabled the alarm ack/shelve permissions.

 ![Global var diffs43](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/b/3ba21b710b2924d843955ecd22a912e1534df5da.png)

The security zone works as expected when accessing the loadout through a remote tag provider from the main plant server 172.24.8.18, read only error received when trying to write to tags, unable to acknowledge alarms.

But when a Perspective session is launched from outside the zones IP range, via a web browser 172.24.8.5 or Perspective workstation 172.24.8.119, directly to the loadout server, I still have full control of the loadout?

 ![Global var diffs41](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/6/d6599dedce9d6ceec41352a97a9d564b70e3463f.png)

Am I missing an additional step to setup the zone correctly? The only way I've managed to get it to accept some form of security is by setting the realtime tag providers tag write permission to the loadout security zone. But I can still acknowledge and shelve alarms, which isn't ideal.

Appreciate any input.

Thanks Mitch

---

<div class="post-metadata">

**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\
**Post date:** [May 16, 2023, 2:50pm UTC](https://forum.inductiveautomation.com/t/security-zone-unexpected-behaviour/73752/2 "2023-05-16T14:50:59Z")

</div>

Did you apply the Security Level Rules to your Perspective Project?

---

<div class="post-metadata">

**Author:** ![Mitchell\_Knights](https://avatars.discourse-cdn.com/v4/letter/m/e68b1a/32.png) [@Mitchell\_Knights](https://forum.inductiveautomation.com/u/Mitchell_Knights)\
**Post date:** [May 18, 2023, 2:02am UTC](https://forum.inductiveautomation.com/t/security-zone-unexpected-behaviour/73752/3 "2023-05-18T02:02:29Z")

</div>

Thanks for getting back to me.

Are you meaning under Project Properties \> Perspective \> Permissions?

 ![Global var diffs46](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/a/3a1d758925f5f6db2f04c9056cc7aee029f2b230.png)

If not where else am I supposed to assign project security levels? Somewhere else in the Gateway?

Thanks Mitchell

---

<div class="post-metadata">

**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\
**Post date:** [May 18, 2023, 4:13pm UTC](https://forum.inductiveautomation.com/t/security-zone-unexpected-behaviour/73752/4 "2023-05-18T16:13:11Z")

</div>

Assuming the screenshot above is the settings for the `NWE_TLO` Security Zone, and the latter screenshot is the saved permissions required for your project, you shouldn't even have been able to successfully open a session from the `172.24.8.5` or `172.24.8.119` IPs. If you're confident that all of you settings have been applied and saved you'll want to reach out to our Support team; they're better equipped to handle situations like this where Corporate Networking could possibly be coming into play.

---

<div class="post-metadata">

**Author:** ![Mitchell\_Knights](https://avatars.discourse-cdn.com/v4/letter/m/e68b1a/32.png) [@Mitchell\_Knights](https://forum.inductiveautomation.com/u/Mitchell_Knights)\
**Post date:** [May 21, 2023, 3:02am UTC](https://forum.inductiveautomation.com/t/security-zone-unexpected-behaviour/73752/5 "2023-05-21T03:02:54Z")

</div>

Yes, you're correct. With the NWE\_TLO security zone selected in the perspective permissions, I'm prohibited from accessing the project completely from either of those IP addresses. I was more asking the question if this was what you were suggesting, as I'd already came to the conclusion this wasn't the desired outcome. I've got it working by setting the realtime tag providers tag write access to SecurityZones/NWE\_TLO and set the enableAcknowledge binding on the alarm status table to isAuthorized(false, SecurityZones/NWE\_TLO). I'll reach out to support and confirm what is the best practice to implement the security zone requirements we have. Thanks for your help.

Mitchell
