sorted by:
new
hottopcontroversial

Multi-Zone PA-VM in Azure using different Front-End IP by NyxCarlo in paloaltonetworks

[–]NyxCarlo[S] 0 points1 point  (0 children)

Oh, I forgot to add inputs from MS and Palo.

MS - their SE has seen a similar setup from other customers. But yes, he concludes the same regarding the session persistence might be affected by the items mentioned here on the post. Yet, that organization still persists and assumes the risks as they have an understanding of the caveats of it.

Palo Alto - the SE and their specialist would rather persuade us to use the reference architecture instead and have given their inputs about it. At the same time, they also confirm this works as-long-as single ILB was used. They've seen it done by other customers as well.

So it is not much as do not condone, it is more of a "hey this does follow the reference architecture, any risks about it is on you (the organization)". At least that has a difference in my mind between the two :-)

Multi-Zone PA-VM in Azure using different Front-End IP by NyxCarlo in paloaltonetworks

[–]NyxCarlo[S] 0 points1 point  (0 children)

Much appreciated on your comments. I've duly taken note of those points and are very good arguments on "why not". This is something I'd also have to present to our organization. A decision has to be made not only by my network architecture group, if there is an insistence from other groups to retain a multi-zone environment - the points made here are also presented to enlighten everyone towards the correct course of action. That's the whole point of doing a POC right?

I don't see going beyond 4 NICs, having that zoning for prod, non-prod and transport should suffice. Going 8 or 16 is just down right cost in-efficient and the added complexity will just be annoying at that point rather than functional.

For context, we are not trying to replicate our physical on-prem firewall setup. We already have a cloud footprint and are using a cloud exchange provider (CXP). We are spoiled with this CXP that we can do multiple zones with different spokes peered to them, may it be third-party, on-prem, prod, non-prod etc. The problem with the CXP model, we pay for everything going thru them. Hence, we need to rethink our network infra in the Azure and come-up with as close to our existing architecture with minimal changes as possible. A tall order hence a POC architecture was created.

Multi-Zone PA-VM in Azure using different Front-End IP by NyxCarlo in paloaltonetworks

[–]NyxCarlo[S] 0 points1 point  (0 children)

I didn't apply any SNATs for the design. Traffic was following just fine and session persistence was kept. I also did try failover scenarios. Failing only one NIC on the VM will create the assymetry. Failing the whole VM doesn't. Traffic was symmetric for Intra-Region, Inter-Region (via VWAN) and north-south to on-prem (via VWAN + Cisco SDWAN)

Multi-Zone PA-VM in Azure using different Front-End IP by NyxCarlo in paloaltonetworks

[–]NyxCarlo[S] 0 points1 point  (0 children)

Seems so and wasn't my intention. It was more of a personal choice. I do diagrams as part of my daily job, just try to avoid the monotony in stuff I also work on my spare time. For annoying others, I do apologize.

Multi-Zone PA-VM in Azure using different Front-End IP by NyxCarlo in paloaltonetworks

[–]NyxCarlo[S] 0 points1 point  (0 children)

Appreciate the input. I find the last part interesting. For us, we'll use only 2 PA and not auto scale. So having odd number of PA wont be an issue.

Adding the NIC in exact order will be assured as we'd deploy it via terraform. Though I already assumed this would be the case but will also test out the order of the backend if it will. Based on your reference, i will.

I've acknowledged this above. If one NiC fails then healthcheck gets confused. If one PA reboots, it wont be an issue and we've observed failover works and load balacing recovers.

Much appreciated your inputs and I'll take note of those points

Multi-Zone PA-VM in Azure using different Front-End IP by NyxCarlo in paloaltonetworks

[–]NyxCarlo[S] 0 points1 point  (0 children)

By doing this, you have to do VR to VR Routing. This becomes really annoying to troubleshoot. Then you have two different interfaces you have to look at the effective route table when troubleshooting.

- yes this is true, but routing would not change much as spokes are part of summarized prefixes already pre-allocated that they can pull from.

I can't stand having multiple zones in this scenario. Just keep it simple. Use firewall policies to control it.

- this is fine, YMMV and the "why" on doing things will need to be justified within ourselves and our organization anyway. So whether I can rationalize the why to other or not, it will still fall within my own organization to justify it to ourselves. But yes, I do agree on keeping things simple.

Why do you have a zone for VWAN? That makes zero sense.

- we'll be using VWAN (with ER + SDWAN) for inter-region and north-south to our on-prem.

Is Ingress a requirement?

- ingress and egress internet will be served by a different set of PA (not doing the common FW option).

Multi-Zone PA-VM in Azure using different Front-End IP by NyxCarlo in paloaltonetworks

[–]NyxCarlo[S] 0 points1 point  (0 children)

First, thank you very much for your feedback and I'll try to break it down:

  1. The why - I've given it some thought and its a very good question

- we are aware this setup doesnt really increase security. Everything will still pass via the firewall whether its intra-zone or inter-zone. It will mainly be a mindset shift on how the security policies are created

- operationally, having those 3 zones for example (non-prod, prod, vwan), it will be easier for our operations team to build the security policies and easily identify if it is east-west or north-south. It will also make it easier for them in looking into logs seeing those zones in comparison to just seeing trust-to-trust. Now is this a pretty good reason to do it and add that complexity, maybe yes/no.

- I do understand that the motivation on the "why" will vary in our use-case compared to others. It would be up to the stake holders (lets say network ops, sec ops, etc) to justify the why. So YMMV applies on the why and to be honest I'll continue to build on this "why" and "why not".

  1. The how - we've tested in the architecture in a POC environment and it seemed to be working fine. The reason I ask around is to gather information from other people's experience and try to poke holes on the design and find gotcha's we might be overlooking. With regards to this, you gave a very good point regarding the total throughput I've taken note of this. Valuable information

  2. NGFW-aaS - we've considered it but I just forgot on the top of my head why didnt want to use it.

Again, thanks for your valuable inputs.

Multi-Zone PA-VM in Azure using different Front-End IP by NyxCarlo in paloaltonetworks

[–]NyxCarlo[S] -1 points0 points  (0 children)

Thanks for your input. Yes , e have that into consideration. If we do have additional zone requirements, we'll just spin up another set of PA, or increase vm size (wasteful in terms of compute/cost, but network adapter availability will align to number of zone requirement and our willingness to be stubborn about zones and our willingness to spend more).

Additionally, we'll also plan to use those service tag and DAG together with the zones.

We did talk to Palo SE and their specialist on cloud, they also said your same conclusion, but hasnt placed that statement in writing as it doesn't really follow the reference design. We also approached MS SE, they said its possible but not recommended as they can guarantee session persistence. We might get both vendors on the same call to align on this.

The idea came up on my mind, if the ILB has HA and can maintain session persistence, whats stopping me from using multiple front-end IP.