Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two seperate issues for mxfirewallcontrol.py #29

Closed
pblais-bowlero opened this issue Dec 30, 2021 · 7 comments
Closed

Two seperate issues for mxfirewallcontrol.py #29

pblais-bowlero opened this issue Dec 30, 2021 · 7 comments

Comments

@pblais-bowlero
Copy link

pblais-bowlero commented Dec 30, 2021

First issue is when appending fw rules with it adds a default rule automatically and doesn't remove it.

python mxfirewallcontrol.py -k -o -f "type:network, name:Center*" -c insert-file:15:firewall-rules-3851.txt -m commit

image

Second Issue: I lost connectivity to cloud due to VPN suspending with my company due to time out. When I went in and attempted to restore the backup using the insert-folder method because there were a lot of them and I knew that it would add it twice to the other devices firewall rules again. It started looping through the same ones over and over again with the next Center's firewall rules. So basically, if Line 2 and Line 3 are specific source-ip like 10.20.76.0 /24 but another center's source-ip should be 10.28.10.0 /24, this one will have the 10.20.76.0 /24 in it. Then when it goes to the next center's fw rule to restore it they will go back through 10.20.76.0/24 and add the new line 2 and line 3's source-ip to all the other centers already completed. Is there a way to keep this from happening?

Original Firewall Rule was before updating:
image

After starting the restore using the insert-folder command it is:
image

@mpapazog
Copy link
Contributor

Thank you for your feedback. I will take a look at these.

On the second issue: are you asking for the script to verify if the line it is going to insert is the same as the one that already exists in the same position and skip that appliance if true?

@pblais-bowlero
Copy link
Author

Thank you for your feedback. I will take a look at these.

On the second issue: are you asking for the script to verify if the line it is going to insert is the same as the one that already exists in the same position and skip that appliance if true?

Hopefully, I can communicate it better. Sorry for the confusion. What is happening is, It does not go to each backup file and restore to file for each meraki. It actually is taking the first backup file and restoring it to the other Meraki MX devices. So is acting like one backup file for all MX appliances. So it changes the source IP addresses to the wrong backup file. Does that make sense?

@mpapazog
Copy link
Contributor

mpapazog commented Feb 4, 2022

I think I fixed the second issue you reported. Please have a look at the latest version of the script, which has moved here: https://github.com/meraki/automation-scripts/tree/master/mx_firewall_control

I will do some testing on the other issue next week.

The script has also been updated to use API v1 and now has the option to fetch the API key from an environment variable.

@pblais-bowlero
Copy link
Author

Thank you for getting this completed. I will test and let you know what I find. It is a great script for Outbound Firewall rules changes on the Meraki MX devices.

@mpapazog
Copy link
Contributor

mpapazog commented Feb 8, 2022

Please check the latest version of the script. It should no longer duplicate "allow any" default rules.

Note that if the ruleset you are inserting ends with an "allow any", the script will not strip it, unless it ends up being positioned as the last rule of the merged ruleset. Inserting an "allow any" in between other rules can be intentional, for example to disable processing part of the ruleset without removing it. To prevent inserting the "allow any" in this scenario, modifying the source ruleset is the way to go.

Let me know how your tests go.

@mpapazog
Copy link
Contributor

Closing due to inactivity. If the problem persists in the latest version, please reopen this issue.

@pblais-bowlero
Copy link
Author

Sorry for the delay in responding. I have finally tested and the two issues have been resolved successfully. Thanks for getting it done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants