Relevance to exclude specific subnet ranges from a deployment

Hi All,

Please can someone help me with the relevance statement to exclude multiple subnets from a deployment.

Regards,

How about something like …
not (set of ("10.1.2.0";"10.1.3.0";"10.1.4.0") contains (registration subnet address of client) as string)

Can we specify the range in slashed format here e.g: 10.1.2.0/10

Also, if a workstation reports multiple results in the subnet fields how do we exclude those or find out what is causing that and find the actual subnet realtime?

Our requirement is to exclude any VPN subnets from this deployment. However, when a client switches from LAN to VPN the status update in IEM is not realtime and rather inconsistent. The IP address reflects multiple results one being the VPN IP address and the other NIC/WiFi but the subnet information doesnt change. Anybody knows what could be causing this ? and how can we plan this deployment to exclude the VPN subnet.

So if a client switches to the VPN, then activity should stop and resume when the VPN disconnects?

Or are you saying you want to deploy an action to only endpoints not connected via VPN?

Also, everything that happens within BigFix is ultimately determined by the Client based upon the instructions provided by the server. If a client goes offline, the server will not know what the current IP info is, but the client does. Relevance can be written that detects changes in IP that the client will respect even if the server doesn’t know anything about it yet.

It would be helpful if you could provide more information and details about what you are trying to accomplish.

If a client switches to VPN then the action should go not relevant and when connected to LAN he should get the package. The Action should run only when the client is not connected to LAN and VPN should be excluded. How can I write a relevance to detect the latest IP address or Active NIC/ Connection IP address?

Please do let me know if you need any further information.

This is sort of the opposite of what you are looking for, but the concept can be used in your case:

https://bigfix.me/fixlet/details/743

This was a task that detected when the VPN connected and then forced the Symantec AV client to check in to the managed server that could only be reached over the VPN.

This is the relevance I used to detect when the VPN was connected:

exists adapters whose (address of it as string != "0.0.0.0" AND description of it as string as lowercase contains "Cisco Systems VPN Adapter" as lowercase) of network

The relevance you need for your specific VPN will be different, but the concept applies. If you wanted to detect when the VPN was not connected, you could just put a NOT in front of that.

Thanks for getting back JG!

This was getting all the more complex as the systems weren’t reporting the realtime status at all and to refresh the subnet information it was taking longer. So I took a different approach. I queried the keys that change in registry when the user connects to VPN and that when he switches back to LAN, and set a relevance in the package to run only when the registry key for LAN exists.Other times the package would just say Not Relevant. This is now working and i am fine tuning it :smile:

You misunderstand about how the system works. It is almost real time, but not in the console. It is the endpoint that ultimately determines the relevance status. The console only reflects the most recent report from the endpoint. The data in the console is much less real time than how things actually work.

If you want to deploy something only when the user is NOT connected to the VPN, then you should deploy the action targeting by property or group or something. Once the endpoint gets the action, it will evaluate the relevance. If it is relevant, then it will run right away. If it is not, then it will wait until it is. It will determine that the VPN has disconnected or reconnected within the time of a single evaluation loop, which could be as short as a few minutes.

You should not deploy an action with this type of relevance to specific computers. This is not the right method. This is where you are getting the machines reporting not relevant.