Multiple types of objects in source column leading to Policy Verification Failure

[Tom_Cripps]

Hi all,

I'm wondering if anyone knows why and if there is a way around this other than creating a duplicate rule and removing the foreign objects from one rule and placing them in the duplicated rule.

Also, 

I'm curious if this is planned to be rectified in the near future?

Tom

[PhoneBoy]

Didn't realize this was a limitation.
What release are you using here?

[Tom_Cripps]

Hi Damon,

SmartConsole version 105

Gateway and Mgmt HotFix 169 on R80.10.

Tom

[PhoneBoy]

It's definitely not allowed in R80.20 either.

@Dima_M any ideas on this one?

[Dima_M]

@Tom_Cripps @PhoneBoy 

You're right, this behavior is by design, motivation is to prevent collisions.

Could you please share more details about your use case?

Access Role can represent Any User@Specific Network - do you think it will be useful in your case?

[Tom_Cripps]

Hi Dima,

Okay, that's something we also thought about internally as well and I can see the reasoning behind it. 

All I wanted to avoid was including both an access role and networks in a single rule to avoid having two identical rules apart from the source column; not a huge deal just wondered if this was a fault I'd done or was by design.

Let me know though if you have any suggestions though?

Tom

[Dima_M]

Hey Tom,

How about {Any/Any Identified Users/Machines} + {Specific Network} in access role - can it substitute the network object in your case?

[Tom_Cripps]

Hi Dima,

That could potentially work, would take a slight redesign from our current standard, but seems like a viable option.

Thanks for the tip.

Tom.

[Norbert_Bohusch]

I most often see a use case for this in the following scenario:
- Internally not using IA
- IA used only for RemoteAccess users
- RemoteAccess users are both internal employees and external contractors
- Traffic to a specific destination allowed for all internal users, which means using client network for internal clients and using Access Role for internal employees using RemoteAccess

In this case it doubles all "client to server" rules because of this limitation.

There are some possible workarounds for this:
1. create a shared layer with all client to server connections and assign it two parent rules with one having source client network, one having source access role of internal employees
2. assign RemoteAccess OM IPs differently for internal/external and use the relevant IPs for the source
3. Start using IA internally, which might be difficult because of some other limitations IA brings. Examples of such issues are: Identity Sharing via Site2Site VPN causes IPSec replay attacks in some cases, Identity Sharing between gateways managed by differend MDM domains is not that easys and so on....
4. your idea of using a Access Role limited only by network, which I must admit I wouldn't have thought off