About mikand

Because a webproxy usually can only work in two modes: * Transparent, meaning that requests that passes it looks like: GET / HTTP/1.1 Host: www.example.com which also means that the webproxy on its own doesnt do any dns resolving (since its transparent, the dstip of this flow is already set to the real dstip (in your case the ip of www.youtube.com or whatever)). * Non-transparent, used for forward-proxy situations which also means that the requests passing it (well sent to it from the clients) looks like: CONNECT http://www.example.com/ HTTP/1.0 which means that the webproxy will do a dns resolving to find out which ip www.example.com has and then connect to it, which also means that on the inside the packet have dstip = proxyip and on the outside the dstip = ip of www.example.com (at the same time as the payload of the packet is changed from CONNECT http:// into GET / and so on). The transparent mode can be used for destination-nat situations aswell meaning that the proxy will accept a connection on lets say TCP8000 and then statically forward it to ip of www.example.com TCP80 (statically in terms of that the webproxy doesnt read the actual contents, it knows beforehand what the dstip should be changed into). Here is the problem (I believe) in your case since www.youtube.com isnt just a single ip and the streaming servers use a bunch of ip ranges. If Youtube always would use lets say 8.8.8.0/24 then you could of course in your L3-core just make a static route for 8.8.8.0/24 so this traffic will be sent to your webbproxy (which acts in transparent mode) while the other traffic would be sent to your PAN device. Since Google (who owns Youtube) use its own AS (AS15169) you could route just their current ranges through your transparent webbproxy. This way you would for at least 99% probability (or so) send Youtube traffic through your webproxy (with the downside that all other Google related traffic would pass it too). This could be done through some BGP router magic or by statically put Google (or Youtube) ranges in your L3-core to force them go through your webproxy - downside here (another one) is that AS15169 uses plenty of ranges: http://www.robtex.com/as/as15169.html#bgp So I think you have found yourself a spot which isnt that easy to get out from in order to make one solution that cover all cases. To sum it up (in case I misunderstood something): 0) Your demand is that Youtube traffic is sent through your webproxy while all the other traffic is sent through your PAN device. 1) You dont want to send all Internet traffic through your webproxy, my  guess due to performance issues (you would need to get a bigger webproxy  first?). 2) You cant use PBF based on appid since appid is detected after the flow is initated and when PBF then kicks in and sends your Youtube traffic to your webproxy then your webproxy will become a drama queen since the incoming flow is missing a SYN packet. 3) You cant configure the clients to use their browser with forward-proxy settings (so the client on its own would send its traffic through the webproxy when needed) since many of them are single boxes (not part of your AD structure). 4) You cant setup just a few static routes in your L3-core to force Youtube traffic to go through your webproxy (while the other Internet traffic goes through your PAN) since Youtube doesnt use just a few of ip ranges (they use plenty of various IP ranges). Which gives given the options and your demands option 4 above is the one which will be closest to your needs (with the drawback that other non Youtube traffic (but on the other hand only Google related traffic) will be sent through your webbproxy. You would also need to maintain these L3 routes (like take a peak at the BGP table every now and then) in case Google adds/removes routes. This can somewhat be handled by in your PAN device setup a deny for youtube traffic (this way you would get support cases if something changes in case you didnt already notice this). Unless I completely misunderstood your case? :smileysilly: Hopefully someone else in here might have ideas on how to resolve your problem. ... View more

If the client is using a browser it should see the block page which informs the client of why access have been blocked. Dont forget to enable ssl-termination in order to inspect (and block) bad stuff using https. You can also make custom block pages if you wish (for example if you wish to use a different design/layout or for that matter use a local language). Check the PA-4.1_Administrators_Guide.pdf for more info (search for "block page"). ... View more

In my opinion you shouldnt rely entirely on appid but rather appid + service (service is the PAN name for ports). Preferly using custom service but using "default" should be fine too. The point here is to setup your PA device like a SPI firewall and then add application identification to go into the NGFW mode. The reason for this is that in order to successfully identify an application the firewall must let some (or more) packet(s) through. If you set "service:any" this means that ALL ports will be forwarded to your device you try to protect and if you are really unlucky this single packet (or these few packets before the flow is successfully identified) will do bad stuff to your device. At first it might seem like climbing mount everest in order to go through 550 rules but I think its still doable. Take them in batches and take short breaks in between and you should be able to go through them all in a day or two 🙂 To make it easier to maintain in future a good idea might be to organize your rules by destination ip/network. So rules regarding server X are bundled close to each other. This also means that, depending on taste, it might be good to avoid aggregate too many rules into one. For example src:NMS dst: server1, server2, server3 appid: snmp service:default src:Admins dst: server1, server2, server3 appid: ssh service:default vs. src:NMS dst: server1 appid: snmp service:default src:Admins dst: server1 appid: ssh service:default src:NMS dst: server2 appid: snmp service:default src:Admins dst: server2 appid: ssh service:default src:NMS dst: server3 appid: snmp service:default src:Admins dst: server3 appid: ssh service:default ... View more

The tricky part is that there are shitloads of Youtube servers out there so you would need to use an address object with an initial wildcard such as "*.youtube.com" - or if you can figure out which ip addresses youtube uses and setup your PBF to trigger on the destination IP. The second tricky part is that the FQDN (to my knowledge but this might have been altered) is looked up when you perform the commit and transformed into the ip address which then is being load into the asic/fpga for the dataplane. So in theory your best option would be to use a PBF based on appid however the admin guide strongly suggest you to NOT do this simply because the initial packets of a flow will not be identified as appid:youtube and once it is the flow is already setup. If your proxy now suddently receives this burst of packets identified as youtube it will start to complain that it didnt receive a SYN packet (if its TCP-traffic) and the drama occurs. I wonder if it wouldnt be a better option to setup the magic along with a dns-resolver? So when your clients asks for *.youtube.com you return the ip of the proxy. However your proxy will then need to know which of the youtube-servers it should forward the traffic to so I guess this wont work either. Cant your clients use your proxy as a forward-proxy instead? This way clients who didnt setup forward-proxy settings in their browser wont be able to reach youtube (appid:youtube in your PA = deny) while the clients who needs to reach youtube must configure a forward-proxy in their browser? ... View more

Personally I wouldnt put the core of my security into the hands of some foreigner, no matter if that foreigner is spelled "Verisign" or something else (on the other hand you are putting your security into the hands of PAN but still :P). Setting up your own CA is pretty simply. There is TinyCA (http://tinyca.sm-zone.net/) and also bootable usb-drives who can act as CA (I forgot its name) unless you wish to do this manually with openssl on a ubuntu box or whatever you prefer. The main thing is then to protect your CA. Make sure you never connect it to any network and keep it locked up in a safebox when you are not around and it will be a better option than to use stuff from Verisign or any other public CA for your Global Protect needs. For added security make sure to use communication one way only (like dont use usb-drives to export the certs/keys, better to burn it on a blanc cdr or such). Then if you want to do this for real you can check the PCI compliance guidelines and stuff like that. ... View more

I think this is in total. VSYS in PAN (and most other devices for that matter) is just to segment the dataplane. You still have a single mgmtplane and its the mgmtplane who does the User-ID Agent identification and stuff. ... View more

Speaking of which... is it possible to have active / passive / passive / passive setup (regarding your example of 4 boxes with the same groupid) ? I cant figure out of any good example for one would like to have such setup but still :smileysilly: ... View more

The technote for Netflow-Fields.pdf says the same thing: " Overview  PAN-OS can generate and export Netflow Version 9 records with unidirectional IP traffic flow information to an outside collector. Netflow export can be enabled on any ingress interface in the system. Separate template records are defined for IPv4, IPv4 with NAT, and IPv6 traffic, and PAN-OS specific (enterprise specific) fields for App-ID and User-ID can be optionally exported. This feature is available on all platforms, except the PA-4000 Series. For more information about Netflow, refer to the Palo Alto Networks Administrator’s Guide. " It would be interresting to get a comment from PAN why the 4000-series is lacking the netflow option? My best guess is that 2000-series and below uses FPGA which PAN can programme themselfs on how they should operate while 4000-series uses ASIC which didnt include the netflow feature - but this is just a guess. If this is correct, does the 5000-series use an ASIC or FPGA (and does the 5000-series support Netflow)? ... View more

Also note that if you are using Captive Portal for a internetaccess network (well any network for that matter but as an example) I would strongly suggest you to use Protected VLAN along with DHCP Snooping (with Option82) in your access-layer. With Protected VLANs the clients are separated from each other (otherwise one client could steal another clients credentials so the wrong person is being blamed at, for example for pr0nsurfing or filesharing or whatever) - dont forget to use Private VLAN on the aggregations to keep the isolation between clients all the way until the PA box. The point of DHCP Snooping (with Option82) is to block rouge dhcp-servers but also to get a log of the physical location of the client (which switch and which interface on the switch that this particular client was connected to). ... View more

I hope someone could improve the manual so all columns from show commands are described. I was looking at "show pbf" (page 407 in the cli manual for panos 4.1) where "KA sent" and "KA got" is mentioned in a sample output - but not a single word of what these columns actually referes to 😞 I can compare with manuals from Allied Telesis who bring details into each row and column which the show commands can produce. For example: " Table 8-15: Parameters in output of the show switch counter command Parameters        Meaning Packet DMA counters Receive                          Counters for packets received. Packets                         The number of packets received by the CPU from the switch chip. Discards                         The number of packets received from the switch chip that were discarded because either the receive queue was greater than 4096, or because the free buffers in the switch were below BufferLevel3, or because there were no data bytes in the packet. TooFewBuffers                 The number of packets received from the switch chip that were discarded because the free buffers in the switch were below BufferLevel3. DescriptorsExhausteds    The number of times the switch chip reported that it could not transfer a packet by DMA to a switch buffer because there were no more receive buffer descriptors. QueueLength                   The number of packets received from the switch chip waiting to be processed by the CPU. " and so on. ... View more

Would be interresting to know if this is a false positive and if this false positive have anything to do with previous false positive regarding trojan.redirector? https://live.paloaltonetworks.com/message/12730#12730 ... View more

Perhaps this could be added to the footer or such? 1k = 1024bytes, 1M = 1048576 bytes ... View more

I assume the release notes are generated automagically through SQL or such from a database. In that case why not always release two release notes? 1) Release Notes (as today, for those who doesnt want the complete list) 2) Release Notes Full (ALL caseid's fixed with description of what is being fixed) ... View more

What does your traffic log identify the blocked flows as? TCP995 I think should be regular SSL (thats what Google uses at least), which should be appid:ssl unless you use ssl-termination (because then the appengine should be able to identify what flows within the ssl). I see that gmail has its own app so perhaps ssl is included there too. TCP510 already exists as an appid:firstclass which should apply for your case (there are other apps using the same port so perhaps appid is misfiring in your case?). You can also search for which apps uses the ports by just typing the portnumber and hit search: http://apps.paloaltonetworks.com/applipedia/ ... View more