Inside switch in above diagram is single point of failure. Wonder whether you can connect palo-alto switch to right hand side edge switches using different vlan than DMZ vlan. By doing that, you will have network isolation, plus edundancy links to palo-alto firewall, even though that FW still potential single point of failure (can be enhanced in the future)
In addition, not sure whether your server support redundancy NIC. If server can do that, you can connect your right hand side server farm directly to edge switches; and connect your left hand server farm to redundant server switches (existing one plus inside switch).
If I were redesigning the network, I would remove the Palo Alto firewalls and the Inside switch from the direct traffic path. The new ASAs are more than sufficient to handle the security needs of the small network. The Palo Alto firewall and inside switch are both unnecessary single points of failure. On top of that, the Palo Alto firewall increases operational complexity for both troubleshooting and change requests of firewall rules that would need to be entered in both the ASA and Palo Alto.
If the only reason the Palo Altos are still useful is the built-in network monitoring apps, I would investigate the possibility of moving them away from direct traffic flow, unless the apps need to be inline with traffic flows to work. If there are political pressures to keep the Palo Alto (like maybe an important someone who bought it is embarassed that it didn't get long enough of a life cycle), I would still try and sell the customer on the fact that the new ASAs will add redundancy and other benefits that the company needs, and since they are there, the Palo Alto would make things more difficult.
Message was edited by: dshield53 Using equipment just because it would be a shame to "waste" it is not a good business or technical decision. Its a sunk cost. Time to move on.
In looking at this design there are a lot of single points of failure. But this May or may not be acceptable based on customer requirements. Besides that , the main question really is around the Palo Alto firewall. You really need to find out why it was purchased, such as features or political reasons. Also did they buy just one Palo Alto or did they buy two? You need to be careful when trying to push a customer in a direction just because you like this or that. We all tend to move in a direction we are comfortable with but there may be reason that the customer want what they want and pushing what you want just because you are comfortable with product X can cause the customer to resist more and possibly cause a strains relationship. When designing you need to take into account internal/external politics as well as many other things. Telling a customer that what they have purchased is a wash without hard facts will only harm you in the end. When creating designs there are many constraints. Try to design based on requirements without a preconceived notion that you must use vendor Y or vendor X. This way if you have to use Palo Alto in this case you can easily place it in your design without having to place things into your design that are not necessary, like a firewall that not needed. I would also look at your HSRP setup with the firewalls in the DMZ in regards to traffic forwarding in a failure scenario or two.
Posted from my mobile device.
Introducing a second vendor for security is not an uncommon practice, (Actually required in certain government use cases) The premise being that vulnerabilities in one vendors implementation does not reflect through to the other vendors. akin to Swiss cheese if you have two layers and the holes do not align it helps prevent the bad guys from getting through. A common aproach to this methodology could be the Cisco Firewalls in L3 mode with standard security policy configured and PAN firewalls in Bump in the wire mode between your security perimiter (Cisco ASA) and the end user's where the policy configuration could leverage Application L7 controlls and user identity type functions.