About mikand

Thanks for the followup ... View more

I disagree, looking at what kind of bugs actually passed the QA department of PA recently even you should start to wonder wtf is going on there (at the QA department)? If the QA department have too much to do then there is another reason for why _NOT_ letting bogus software pass and hit the production lines. For example the appid cache pollution bug is something I could appologize the QA department for not spotting (however it would be far better if they spotted this instead of the Checkpoint marketing department who then went ranting about it during the xmas holidays) - while the QoS bug in 5.0.0 and 5.0.1 is a good example that the QA process is failing big time. First that the QoS bug wasnt spotted (I mean its there in front of your face - its not some obscure "do these 500 odd stuff to your configuration before the bug shows up", and then when the bug was said to be fixed it took just minutes to find out that it actually wasnt. Which at least for me raises some questions on what did the QA department actually test regarding this QoS bug? And of course, there can be other malfunctions within PA so perhaps I shouldnt blame on the QA department team too much but rather the QA process within PA (because if we take the QoS example perhaps the QA team wasnt involved at all - then there need to be a change within PA so bugs such as this (and specially when its claimed to be fixed) doesnt hit the production lines). From my experience the difference between a good and a bad vendor is how problems are dealt with when shit hits the fan. Of course there will be bugs but acting on a market where PA gear isnt exactly cheap stuff and there are competitors that will happily be ranting about things as soon as they get a chance (no matter if the ranting is true or false) then having a high quality QA process would be like a "company firewall" of bringing a good product to their (PA's) customers. ... View more

Perhaps the quality assurance people finally had to do their work properly? 😉 ... View more

44k is 44000 bytes (or 45056 bytes depending on if you count k as 1000 or 1024)... meaning contains several 1500 bytes packets already if thats what you mean - of course unless the test performed forced to use smaller packets? Jambulo: Could you paste the config used so the community forum can take a peak in case there is something in there which (for performande reasons) isnt properly setup? Also verify so you dont have bad interfaces or bad cabling which could end up with resends which of course will get you lower values. The 2050 is speced for: (1) Gbps firewall throughput (App-ID enabled1) 500 Mbps threat prevention throughput 300 Mbps IPSec VPN throughput 250,000 max sessions 15,000 new sessions per second With the note of: (1) All performance and capacities are measured under ideal testing conditions using PAN-OS 5.0. where it previously was written that the test (to get the performancenumbers) was using a specific size of http-transmissions (if I recall it correctly). Looking at other performance tests you could try a payload of 1megabyte to see if you can reach topspeed, however number of transactions per second will drop compared to lets say when using 64k payload (which will have far more transactions per second but only slighly lower throughput counted in Mbit/s). To max out transactions per second you can go down to 4k payload which will drop the Mbit/s but show you peak in transactions per second (or even down to 512 bytes I think). Another thing to test is to enable jumboframes (both on the PA device and on the loadgenerator) and see how that will affect transactions per second and throughput for a given payloadsize. Yet another thing to test is to use a single download but lets say 1gigabyte of payloadsize and see which throughput you get with that. So to max out throughput numbers a test something like this could be performed: 1) Use a single security rule that is setup like: srczone: any dstzone: any srcip: any dstip: any appid: any service: any threat: none selected (like no IPS, AV, FILE, URL etc). options: none select (like no logging etc). 2) Verify that both ends are up with 1Gbit/s full duplex (or 10Gbit/s if you use such interfaces) - connect directly to the PA device (like no switch or such in between). 3) Enable jumboframes on both the PA device and the loadgenerator. 4) Perform the test with a single transaction but with 1Gbyte (or more) as payloadsize. If the above doesnt get you close or above the numbers presented in the datasheet I would contact support to verify that there is nothing wrong with the particular PA unit (like RMA or such). If I recall it correctly NSS Labs got optimal performance numbers of 115% above the one stated in the datasheet - these numbers will of course vary or for that matter go down if you have smaller payloadsize etc. ... View more

*keeps fingers crossed* ... View more

There is a setting somewhere if unknown traffic should be captured or not by default. The reason is to have a sample to send for analysis if needed (or investage on your own) - for example in order to create a custom appid (either on your own or by support from PaloAlto). The packetcapture can also be setup for various IPS and (I think) AV signatures - same here to have a sample in case false positive occurs or such. ... View more

hmm, I guess that will be a doable workaround - thanks again! ... View more

Panorama is mentioned in 3.1, 4.0 and 4.1 (and of course latest 5.0) MIB modules: https://live.paloaltonetworks.com/community/documentation/content?filterID=content~category[enterprise-snmp-mib] ... View more

Doh! there it was, thanks! Page 232 in the PA-5.0_Administrators_Guide.pdf (for further references). Is it possible to have the srcport being used displayed in the security policy list? ... View more

App-IDs are still cached but the function has been modified. Look at this video from Checkpoint (somewhat biased but still interresting): Palo Alto Networks vs. Check Point - Did PAN "fix" the Firewall - YouTube The point is the way App-ID works, depending on which App-IDs you have allowed, one or more packets will be let through the firewall in order to successfully (with low falsepositive rate) identify the application being used. This can of course be bad if the packet(s) contain some vuln which the IPS currently doesnt have a signature for (given that you enabled IPS for these flows) - or for other reasons where you dont expect to see packets let through your firewall unless they are approved. By using "service:application-default", or if possible, manually define which port is expected such as "service:TCP80" the packet must match the basics such as (srczone, dstzone), srcip, dstip and dstport before being inspected further to identify the application being used. This precheck is defined in the workflow of what the PANOS will do to a packet that arrived to a PA box: http://media.paloaltonetworks.com/documents/techbrief-app-id.pdf If you use "service:any" this precheck will always fail (for the particular flow(s)) and exposing the service you actually is trying to protect. Or for that matter leak information in any direction. The above is also confirmed by the security bulletin released due to the App-ID cache pollution case last xmas: https://live.paloaltonetworks.com/docs/DOC-4315 " App-ID Cache Pollution Avoidance Recommendations  Do not use “any” as the service for allowed applications:  It is Palo Alto Networks recommendation to use “application-default” or specific ports in the service field of the security policies. This prevents applications from running on unusual ports and protocols, which if not intentional, can be a sign of undesired application behavior and usage. Many of the evasion variants observed using the App-ID cache pollution would be addressed if “application-default” had been used in the security policies. All security rules with “any” in the service field should be double-checked and in most cases, should be modified to use a specific port or “application-default”. Note that the device still checks for all applications on all ports, but with this configuration, applications are only allowed on their default ports/protocols. " ... View more

Speaking of ports, what about srcport - how to define that in a security rule in PA? ... View more

NEVER use "service:any", at least use "service:application-default" or if possible manually define the port/port-ranges to be used. ... View more

Sorry for late response, I meant ssl decryption yes. The one where the PA will terminate the ssl session and create another one towards Internet - the client must have the CA the PA device will use for the ssl session between PA box and the client as a trusted CA. However some applications refuses to have their SSL traffic terminated or inspected (like windowsupdate among others). I dont know if this is the case for mega aswell. The PA can do a light edition of inspection (or just logging that is) for ssl it cannot terminate (decrypt) and that is by looking at the CN record of the cert being used (used for url-filtering when ssl decrypt is not active). The best is to try to enable ssl decrypt and see how that works with mega (because then you can do stuff like IPS, AV, filetypes etc)... ... View more

But that sounds like that dynamic block list I linked to earlier or is it the same feature? ... View more