About ddelcourt

This is going to be so much fun, can't wait for next week! ... View more

Thanks to all that helped pull this together and a special thanks in advance to those who will participate next week! 🙂 I'm looking forward to all the questions and interaction with our customers and partners! ... View more

I would agree with @RobinClayton @OtakarKlier @jeremy.larsen here... this is not simply getting rid of a switch but also redesigning your outbound traffic layer... today, specific traffic (SIP/VoIP) is directed via some kind of route engineering (I assume) to go thru the PA220 and the rest is engineered to go thru CP and bypass the PA220... the proposed design now puts the PA220 in line with the CP and capacity issues aside you still need a common L2 north/south of the CP FWs for HA to work and pushing that to the PA220 is just moving the same functionality to a new spot...   If full resiliency is required, you have HA on the CP FWs, then having redundant L2 switches north/south gets you there as a failure on either switch means use lose outbound connectivity regardless of the HA on the CP FWs.   On the capacity front it would be recommended to understand the traffic load/rates currently going thru the CP FWs and add that to what the PA220 is currently doing to see if it can handle the additional load, you still would have a SPOF as the PA220 is not in HA...   Lots of things to consider, perhaps reaching out to your SE to have a more detailed conversation on this would be a good next step. ... View more

@RobinClayton so, I think the issue you are having is that you are trying to prestage the PA220 by creating the second interface in the same subnet before you deprecate the existing one... if this is the case that explains the error as PANOS will not let you do that in the same VR IIRC.   As for removing the L2 switch and directly connecting that should be OK, based on what we know at this point, so long as your upstream CP FW is not in HA and doesn't need a common L2 to accommodate...    Assuming below is a simple representation:   The L2 switch should not be needed... could you just leave the configs as-is and directly connect the CP/PA FWs directly? ... View more

@MrDMartins well crafted description of your scenario!   At the end of the day there are many layers to an HA configuration meant to provide physical system (FW) resiliency within your environment... the HA configuration is specific to each FW in the HA pair and with the exception of FW specific IPs must match timer/other settings, a couple things to consider:   - HA Preempt Configure this only if you are comfortable with the fact that the problem that caused the HA fail-over to occur is or doesn't have the potential to be intermittent as that could cause bouncing of the HA pair unnecessarily... general rule of thumb is to NOT enable HA Preempt so that you can control when to fail-back, if desired, after resolving whatever issue caused the initial fail-over.   - HA Link Monitoring This is the best first step in enhancing your HA configuration as you want to control, via Link Groups, the fail-over behavior at the physical layer where you have a failed interface/cable. In this case, if there is an interface/cable issue with the directly connected L2 switch then this configuration will help fail-over appropriately... don't forget to include all your traffic bearing/forwarding links... 😉   - HA Path Monitoring If you only have one logical path out, in this case a single upstream ISP router/link, then Path Monitoring thru that will not be very fruitful and lead to the scenario described by @lrangra so probably not worth configuring. If you have multiple downstream (internal) paths then you could investigate setting up Path Monitoring for those.   Couple good links if need be: https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/high-availability/ha-concepts.html https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGNCA0   hth! ... View more

@dmodi I have a Windows10 system and opened a CMD window, typed "dir > list.txt" and it dumped the output of dir into that file... from there you can view whats in the file in your favorite text editor or type "type list.txt" and it showed me what was in the file...   By the way, if you use ">>" then it will append whatever you want to that existing file... for example, typing "dir >> list.txt" will append another directory listing to the end of list.txt.   This is very similar to *NIX commands albeit far less options... hth! ... View more

@NisterioHD I am certainly not an authority of all vendor FW platforms, but in general *most* security devices will drop aged out connections silently...    I did a quick google search and found this KB article: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClUvCAK   Not a lot of detail, but it looks like the only way you can have the FW send a TCP Reset is if it triggers a Security Profile (threat) setting where this is an option... not everything yer looking for, but at least confirmation of what to expect... ... View more

This is an age old discussion around application behavior... a couple things to consider, not all applications behave the same and I'm sure we all have war stories of sending a TCP-RST caused an application to blow up 🙂 so, no perfect answers for everything which is why if there is no traffic seen during the defined session timeout period it will be aged out and future traffic not starting with the appropriate TCP handshake will be dropped.   If the FW terminates a session then the reason it does so should be captured in the log at session end as described in this thread, see https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/monitoring/use-syslog-for-monitoring/syslog-field-descriptions/traffic-log-fields for a run down (PANOS 8.1) of how the log is broken down. It is a little cryptic, but there is a parameter tracked for "aged out" of a session as a "reason" for session end.   As to what can I do? The first thing to check is to see if there is an App-ID for the application, Application Research Center would be the place to start.   If not, then you could create a custom App-ID for that specific flow and manage the timeout and other characteristics.   If all of that is too much to do right now then depending on your version of PANOS you can create a custom Service Object and manage the timeout value, https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-web-interface-help/objects/objects-services.html. This Service object could then be used in the specific security rule for that source(s)/destination(s) requiring the different timeout and/or other characteristics.   In general, changing the default UDP/TCP timeout is not a good idea as that becomes pervasive across everything which is probably not desired nor is it generally good security hygiene... hth ... View more

@JermaineScott, what @SteveCantwell is saying is that there is no MS AD Syslog parser because we don't do general Syslog scraping for MS AD. PAN-OS actually talks natively to the DC to gather the information as it is much more effective and efficient. In short, take a look at the User-ID documentation, https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/user-id.html is PAN-OS 9.0 doc, as there is some great information on how to configure User-ID to talk to your AD DCs and gather the appropriate information.   There are special Syslog parsers, as identifed, that have been created to look for specific information from these specific sources because that is the only way to gather information needed to do IP Mapping. It is also then leaning on receiving Syslog messages, not the most reliable mechanism.   If you have further questions after reviewing the documentation please do post, a lot of smart folks out here... 🙂 ... View more