We recently purchased a pair of PA-5050s, and had a VAR implement the design recommended by our Palo SE. This design has lead to many challenges and issues, and I'm now questioning wether we made the right design choice.
Prior to purchasing the Palo, we've been using a Cisco ASA, impletmented in the traditional manner, placed on the perimeter with a trusted LAN, Untrusted WAN, and DMZ. The Palo SE recommeneded that we place the Palo as the center of the network, with a Vwire between our collaped core and Nexus datacenter switches, a Vwire between the core and access layer switches, a Vwire between our MPLS CE router for remote offices and the Core, and with our wireless zone directors terminating at the Palo. With this, ALL traffic traverses the Palo, including all client/server traffic, and 6 security zones have been created, with egress rules created for each.
While I see the benifit of this design, we've experianced many issues as a result. The most recent example of this is that all traffic is now subject to the TCP timeout on the Palo, the default being 3600 seconds. This has caused problems with applications that require long running TCP sessions, such as MAPI and CIFS, prematurely terminating, requiring either implementing very long timeouts or putting TCPKeepAlives in place, that wern't required before. There have been many other issues that we've dealt with as well, including some off hours packet loss to our WAN sites that was not an issue before, and which we've yet to pinpoint and resolve.
Anyhow, being very new to Palo, I have no idea wether this design is commonplace. Can anyone share if this is most common method of deployment, and what experiances and challenges you've experienced? I'm wondering if we should just deploy the Palo on the perimeter, with a single trusted zone, and IPS only on the perimeter ingress, and a tap zone off the core for IDS, or if it would be best to stay the course. We're a relatively small environment and I'm wondering if this may have been over engineered. What are the most common designs your seeing out there? Is everyone really putting the palo between their access layer and data center?
Thanks in advanced for taking the time to read this and for any guidance!
I udnerstand the frustration from going from a ASA to a PAN, however I will do it any day of the week. I think the reason your SE recommended that setup is because it would require a lot less netowrking/vlan changes to drop it in. If you are having specific issues, like you mentioned, I would reach out to the SE for assistance and/or guidance, tech support is also a good option.
As for changing the setup, I personally would leave it the way it is since it is secure and segmentated into different zones. The protection you gain is very high compared to what you had before. Stay the course, it is much better and more secure in the long run.
Hope this helps.
While I dont think your setup is atypical I would also not be the best person to say it is the most common approach. Like stated before I think it was the easiest/quickest deployment (with the limited info we have) for your environment. Another way would have been to create new vlans and zones and segregate the servers that way. This however creates a lot more work to move stuff around. I prefer (not saying its the best approach) to use the multi vlan approach since it can reduce the number of physical interfaces used (based on segregation, i.e. each vlan on its own interface or some interfaces with multiple sub interfaces, however this is just my opinion, I hope others can chime in and provide theirs.
V-wires are really cool (in my opinion) as they allow you to protect a device/sever without a lot of networking/topology changes. https://www.paloaltonetworks.com/documentation/71/pan-os/pan-os/networking/virtual-wire-deployments#...
I do have some in my enviroment along with the multi/vlan approach. I guess it just all depends on your environment and what makes the most sense.
Hope this helps.
I would add that the tcp timeout settings are NOT related to you using v-wire mode but the result of the migration from the ASA to a more modern firewall with RFC standard timouts enforced for the session tables. This issue will occur with pretty much any move off of older firewall firmware styles to any newer model for pretty much any manufacturer.
Part of the application on-boarding process has to be to discover the actual behavior expected from the transiting applications. Ideally the app provider will be adjusting their settings and programs to operate within RFC timeout specifications. But this if frequently not the case so custom timeouts will need to be made for specific applications when required.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!