Disable interface and kill its sessions by schedule...

[LCMember4427]

Hi,

This is a boarding school situation.  By mutual agreement we close internet access to the dorms from midnight to 6AM.  Several years ago we tried to control the DormsNetZone rules by a schedule.  However as this didn't kill the active sessions it was of little use for us.  Now we interrupt the AC power to the DormsNet distribution switch to achieve a complete closedown of this network zone.

However it would be far more elegant and not so brutal to control this with our VM-100 features.

I can set a schedule from midnight to 6AM on the rules and do a "clear session all filter from DormsNetZone" from CLI but the latter must be done manually as I'm aware of no cron features in the CLI...

I assume that it would be no use to create a scheduled DENY ALL rule from DormsNetZone to UnTrust during the nights either....

Any suggestion on how to automatically 'disable an interface' in PanOS governed by a schedule is highly appreciated  🙂

[OtakarKlier]

Hello,

You can setup a schedule to do what you want on a policy. This way you can set a policy "DENY ALL rule from DormsNetZone to UnTrust during the night" and have it enable during the time frame you want.

Regards,

[aleksandar.astardzhiev]

Hey @LCMember4427 ,

That is interesting situation. However I am not sure that @OtakarKlier suggestion, for creating "deny all" rule somewhere at the top with schedule, would work. I don't have rich experience with schedules, but at the bottom of this link is mentioned that sessions that are created before the schedule start are not affected (same reason why your schedule on allow rule, does not close the existing sessions).

Have you consider using the firewall build-in API function? API allows you to send any command (that you can execute locally on the firewall), by automated script running on remote host. You can write a script that tells the firewall to either shutdown interface, or enable previously disabled "deny all" rule and commit all those changes. Then you can put the script somewhere to be executed automatically by schedule.

[PavelK]

Thank you for the post @LCMember4427

You mentioned about creating a scheduler for the security policy, but your concern is how to clear already established sessions. I would assume that "Rematch Sessions" under: Device > Setup > Sessions > Session Setting, will match new policy to deny that traffic after you enable/disable security rule you mentioned in your post.

If policy "Rematch Sessions" will not take an effect, then as a next thing, I would try to follow this KB to leverage API against System/Configuration log: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HBmqCAG

I assume that once, security policy is enabled/disabled by scheduler, there will be a system or configuration log. Note down string of the log that is being generated and use it in Step No.4, then in Step No.6/7 use: "<clear><session><all><filter>from DormsNetZone". I think you can follow that KB as it is. Follow steps 1 and 2, skip step: 3, in step 4 look for corresponding log, follow step 5 (Only use right API call to clear sessions), follow step 6 (Only use right filter), follow step 7.

If the above is not right solution, you can always create an API script, for example below and run it as a scheduled task from server with schedule for example 1 minute after scheduler takes action for your security policy.

 https://firewall/api/?type=op&cmd=<clear><session><all><filter>from DormsNetZone 

Kind Regards

Pavel

[BPry]

Either way I would use the API and a Python/Powershell script running on via Cron or a scheduled task if using Windows to accomplish this. I'd create the scheduled deny entry at the top of your rulebase as @OtakarKlier mentioned previously. Then simply schedule the script to issue the following via the api.

https://$firewall/api/?type=op&cmd=<clear><session><all><filter><from>$zone</from></filter></all></session></clear>&key=$key

Replace the $firewall with your MGMT IP, $zone with DormsNetZone to match your source zone, and $key with your API and schedule the script. This will allow the schedule to work as intended and clear all previously allowed traffic so any ongoing sessions are closed and hit the scheduled Deny rule.