Where to Write Security Policies with a Site-to-Site VPN

[JoshVogel0]

Hello,

We have a pair of 3200s on our main site, and have added an 820 at a remote site to bring up an IPSec tunnel between the two.

When I initially set the remote site up, I decided to have all the security policies controlling what access the remote site would have to the main site on the 820 side. I could see arguments for doing it on either end, but I decided on doing this since it's closer to the source and will block denied traffic before it traverses our tunnel (with limited bandwidth) and because I thought it'd make management easier to have a remote site with the few rules it needs and not clutter up the main site with them. The obvious downside being now I had a separate set of rules to maintain (and it looks like we won't be maintaining our Threat Prevention license on the 820...).

Now we're adding two more remote sites which will also be set up the same way-- with a site-to-site tunnel back to my 3200s-- which would mean having four sets of security policies to keep up with, so I'm starting to really question this choice.

What's best practice (and common practice) in managing the access of remote sites over a tunnel? Should I move the policies to my 3200s and just add the new remote site IPs to these policies as the sites are brought up? Do I keep setting the policies on each remote PAN and push to get Panorama to make maintaining these extra rulesets easier?

Thanks

[BPry · Accepted solution]

@JoshVogel0,

So, kind of not sanctioned and not favored by Palo Alto, but if you can't get approval for Panorama and have any experience scripting just setup a Jinja2 template for your remote offices and some build scripts and you can duplicate rules incredibly easily and only update them in one place. It means you have to push up the XML file and load it onto the firewall, but again if you script that process you can automate all of it. Panorama uses Jinja2 on the backend, so you're essentially duplicating what you could just buy. It works, and it doesn't take incredibly long to build out for simple deployments. 

As for your primary question, I've seen people do it both ways. Personally I take the approach that the traffic that is exiting locally will be managed directly on the remote office firewalls. So for us, anything that is simply accessing public resources that doesn't traverse the tunnel is built out and handled locally on the remote office side of things. These all go in a templated security rulebase so that I only have to modify one file and can use it across all remote offices. 

Anything that traverses the tunnels are handled on the other side of things. So the remote offices are allowed to attempt to send anything they want through the tunnel, but the perimeter firewalls that they terminate on are going to decide if the traffic is actually allowed to pass. I personally find it easier this way as it means, for the most part, my guys only have to look at the local firewalls for the vast majority of communication issues. It also means that my lower level staff don't need access to the remote office firewalls directly. 

Seriously though if you actually get used to doing the day to day configuration in the XML file instead of the GUI you can the benefit of being able to template all of this without Panorama, the use of Git for managing those files, and the API allows you to do this all really easily. Just be warned that if you build this out you likely won't be able to justify Panorama going forward, as one of the major selling points of Panorama you've already spent time building. 

[JoshVogel0]

Thanks for your input. I had been leaning towards moving the rules but wanted to justify the effort, which you helped to do. Took a few hours, but at least now I know any new remote sites will be simple to bring up in this respect.

That's very interesting about Jinja2. I'm reluctant to suggest Panorama anyway since it seems so frequently riddled with CVEs and bugs, and individual management isn't too cumbersome yet. I'll look into Jinja if management ever starts to balloon out of control. We also have SolarWinds NCM which is pulling configs off the firewalls, so I could probably leverage that to push too. I have some experience working with the XML since I used it to copy the policy configs from an existing remote site to a new one.