About mikand

A common setup seems to be to set Critical, High and Medium to block while Low and Informational is set to alert. Unless you are paranoid like me and prefer to set them all to block :smileysilly: The problem with the later case is that you will need to hunt down the false positives in order to whitelist those cases (since Low and Informational seems to contain a a higher grade of false positives than the other categories). ... View more

Is ECMP on the roadmap or is it highly unlikely that it will show up with current hardware models (200, 500, 2000, 4000 and 5000 series)? ... View more

Direction is set to "server-to-client" which means that you need to check in the traffic log to find out who is the "server" and who is the "client" for this connection. The "client" is the one who initiated the connection. Edit: Meaning that the client tried to download something from the server which then was blocked. ... View more

Start with creating a drawing and publish it here with ip-ranges attached (you can use faked ip's but so we have something to discuss around). As I see it you have 3 types of "sites": * Client-site (x number of them) * West-site (DC1) * East-site (DC2) Each client-site have two IPSEC tunnels, one to DC1 and one to DC2. The range at client-site is CLIENT/24 (or whatever size you use), range at west-site is DC1/16 and east-site DC2/16 (the size is just an example). The client-site then have the following routing: DC1/16 nexthop tunnel1 DC2/16 nexthop tunnel2 0.0.0.0/0 nexthop tunnel1 0.0.0.0/0 nexthop tunnel2 (im not sure if PA supports ECMP (Equal Cost Multipath), if not you can use different metrics so client-sites located to the west use DC1 as primary and DC2 as secondary while client-sites located to the east use DC2 as primary and DC1 as secondary). Now at DC1 you have the following routing setup (tunnel999 is the site-to-site (DC1-DC2) tunnel): CLIENT1/24 nexthop tunnel1 metric 1 CLIENT1/24 nexthop tunnel999 metric 2 CLIENT2/24 nexthop tunnel2 metric 1 CLIENT2/24 nexthop tunnel999 metric 2 ... DC2/16 nexthop tunnel999 0.0.0.0/0 nexthop INTERNETFW_DC1 and the opposite at DC2: CLIENT1/24 nexthop tunnel1 metric 1 CLIENT1/24 nexthop tunnel999 metric 2 CLIENT2/24 nexthop tunnel2 metric 1 CLIENT2/24 nexthop tunnel999 metric 2 ... DC1/16 nexthop tunnel999 0.0.0.0/0 nexthop INTERNETFW_DC2 Downside here is that defgw towards Internet is only available locally. In order for this to work it would be great if you can setup your Bluecoat webproxy as a non-transparent proxy. Meaning that anything that needs/wants to reach Internet must use the inside-ip of your Bluecoat as "forward-proxy". If you have a loadbalancer such as F5 or similar you can setup a virtual ip-range which is the ip that the client/servers use as forward-proxy and then the loadbalancer at each site will forward the traffic to the Bluecoat which is currently the best option. The point here is that in your core you will only have RFC1918 addresses and could setup an IDS to set off an alarm in case a non-RFC1918 ip address shows up (or if you have your PA as core let the PA sound this alarm). If you do so then you wont need these routes at each client-site: 0.0.0.0/0 nexthop tunnel1 0.0.0.0/0 nexthop tunnel2 This way stuff at DC1 should be able to reach DC2 and the other way around along with clients reaching both DC's. The above can be optimized by using a dynamic routing between DC1 and DC2 in order to avoid routing loops (if CLIENT2/24 disconnects the packets for CLIENT2/24 would with static routing need to burst between the sites until the TTL hits 0) but on the other hand you would then need to rely on that the dynamic routing protocol is always functional. Another risk with dynamic routing is that you could accidently pass all traffic through a poor client-site in case the DC1-DC2 connection breaks. ... View more

What does your traffic log tell you? ... View more

Ehm... is it possible for someone from PAN to disable this magic SMTP interaction which this forum seems to have since autoreplies are posted directly into the threads (for obviously no use)? ... View more

Checkout if: can be of any help (specially example3 DMZ server outbound to Internet)? If im not mistaken the security rule is applied before SNAT happens which means you should use the real ip of the server and not the SNATed ip (compared to DNAT who happens before security rules are checked which means that security rules must act on the DNATed ip). ... View more

Also I think kwarner23 missplaced the /29 and /30 networks in the first post. The /30 (if we speak IPv4) has 4 ip addresses (2 usable) and is in these situations often refered to as the "linknet" (or "link network"). Not uncommon that the linknet is using a private ip range (RFC918 - which means that it isnt (or shouldnt be) accessible from another ISP). While the /29 has 8 ip addresses (6 usable) and is often called the "routed network". Not uncommon that this routed network is a set of public ip addresses so it is accessible from other ISPs. This gives that in your router (well PAN in your case) you setup it to use ip 10.1.76.6 mask 255.255.255.252 (/30) with 10.1.76.5 as defgw. And your ISP will set 10.1.76.6 as nexthop for 10.0.194.112/29 (which then they announce in their network as a valid range and to which distrouter it belongs to). So if your linknet is using public ip addresses then I would use the PAN ip address to terminate the incoming encryped VPN-tunnels (unless you use a dedicated box for this sitting on a DMZ but then you would use one of the routed addresses for this). Otherwise you could (I think) setup one of the /29 addresses as localinterface with mask /32 and let the other VPN hosts connect to this ip (this way the PAN will still handle the VPN-connections - again unless you use a dedicated box for this in a DMZ). Also I guess that 10.0.194.112/29 was just an example from your side since this range aint routable over the Internet (on the other hand perhaps it isnt the Internet you are connected to)? If the /29 is a range of public addresses I would avoid using NAT if possible (on the other hand you would then lose 2 addresses as net/broadcast if you for example use 10.0.194.112/30 as DMZ and 10.0.194.116/30 as outgoing SNAT addresses for surfing or whatever).. ... View more

Looks like currently not that many others believes this is malicious either :S Only 2 out of 42 AV-vendors: https://www.virustotal.com/file/7987ac38f870cd5bbb090393651a5981ffd6568c314254a1c5413c13a4fa76a0/analysis/1333985448/ ... View more

As you see in the nat-rule there is a small header of "original packet" vs "translated packet". The "original packet" is what the PA should look for, and "translated packet" is what to do when the packet is found. The security rule then acts on the "translated packet" in this case. You can check the PAN Packet Flow document for details on how the packets are being mangled in the dataplane: https://live.paloaltonetworks.com/docs/DOC-1628 ... View more

So this means that if you setup service:default-service and have 2 or more applications all applications in the same security rule can use each other ports? Because one can get the impression that if you setup: appid: app1,app2 service: port1,port2 then of course app1 can use both port1 and port2. But when setting it up as: appid: app1, app2 service: default at least I would imagine (at first) that app1 can only use its own default ports (lets say port1) and app2 can only use whatever default ports it got assigned (lets say port2). What are the odds that if one file this as a feature request (lock each app to its own serviceports) that it can be fixed (of course one can file any feature request but its also good to know the probability that it can be fixed aswell)? ... View more

Regarding security risk... Cant you limit an account to only view the dashboard (or similar) as a role? ... View more

I had missed that currently only 4000 and 5000 series support aggregated interfaces. ... View more

oops... ... View more