About gwesson

You may want to double-check the formatting of the list file. Ensure that the same carriage return/line feed character is being used for both addresses.   Try a couple troubleshooting steps: Add a 3rd subnet, see if it takes the bottom two or only the last one. Swap the order to see if the problem follows the location or the address. If you've got a header in the file, remove that and start only with the first address. Try using a range to see if that works (10.0.1.0-10.0.1.254)   ... View more

When using a public CA, the chain is vitally important to get right. It can be done wrong, and cause some issues. Here's a doc I wrote a few years that goes into the details:   https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Install-a-Chained-Certificate-Signed-by-a-Public-CA/ta-p/55523 ... View more

A couple things could help clear it up if you can repost the screenshot:   Remove or hide the SNR and Rate columns in Wireshark. Reduce the sizes of the IP columns to expand the other columns that have "..." so we can see the full data. I assume the "delta" column is delta time between displayed frames, but expanding that field could help (or change your time display format to "Seconds since previous displayed packet". Grab a packet capture of a working client to compare the flow.   It looks like we see two sets of three-way handshakes here, both on destination port 2048. Both handshakes are complete, and there seems to be an exchange of data (client sends PSH flags on frames 11-12, 13-14, and 15-16; the server sends a reply in frames 17-18).   If the traffic is known to Wireshark, you can also decode it as the known traffic (if it's TLS for example, right-click on any frame and choose Decode As..., and specify port 2048 to be whatever the actual traffic is). ... View more

It's actually even more straightforward than that:   Classified = count of connections per second for a source IP. Aggregate = count of connections per second for all source IPs combined.   There's a doc here that briefly covers it: https://live.paloaltonetworks.com/t5/Learning-Articles/Differences-between-DoS-Protection-and-Zone-Protection/ta-p/57761   Another one that goes into more detail specifically about DoS: https://live.paloaltonetworks.com/t5/Featured-Articles/How-to-Set-Up-DoS-Protection/ta-p/71164   Hope that helps! Greg ... View more

Are you seeing problems with the uninstall? I verified mine is set to the same (/I not /x) and the uninstall works fine.  ... View more

Unless you have a specific reason to only allow http-video on port 80, just remove the "application-default" service. This is the transition between a traditional port-based firewall to the next generation firewall you have. Ports really don't matter much, it's the application that you're really trying to control.   Your rule seems to indicate that you do want http-video (plus other apps) to be allowed, and if you don't really care about the port, just set the service to any. ... View more

@Jacopo_Vigano afraid not. It's not something I've seen before, but because you're getting an error I could recommend opening a case as @reaper mentioned. I'd reference this thread as well since you provided so much detail.   Best regards, Greg ... View more

2 things to check:   1. Do you have a valid GlobalProtect Gateway license (you said a GP license, but there used to be a Portal license and a Gateway license, only the Gateway is valid and will work for GP Clientless VPN). 2. Check your ms.log file when trying to get the update. You can run:   tail follow yes mp-log ms.log --or-- less mp-log ms.log (shift+g to go to the end of the file) That will tell you exactly what's happening beyond the error presented in the CLI. There tend to be a bunch of lines for each request (DNS lookup of the update site, connection, downloading, etc.) so you may need to do some scrolling.   You should see something along the lines of "File successfully downloaded" if it's there.  ... View more

@justynfortenberry   A lot has changed in the 4.5 years since the most recent post on this thread. You may be better off starting a new thread with the details of what you have (hardware, PAN-OS version, content version, etc.). ... View more

Awesome, the screenshot helps.   Notice that the underline bold items are full IPs, but the normal items contain subnets.   My browser doesn't make any distinction in the UI between them, but what's probably happening is that there's something in the browser that recognizes the link as an IP and is underlining/bolding it. I even tried to make a bunch of rules with different types of addresses but nothing makes mine look like your system. I'm still on 8.0.0, so that also may be a difference as well.   Try it in a couple other browsers, it's probably just something specific to that. ... View more

A screenshot would help if you could upload one.   Could one color be manually-typed IP addresses and the other color be address objects? Or maybe some have subnets and others are just raw IPs?   On my firewall I don't have any that are always underlined, but I'm also running 8.0.0 so it may be different as well. Could be differences in browser (plus any plugins you may have). ... View more

@TranceforLife      Edit: If you were asking how I separated the lines before formatting them, I knew it was output from the logs and that each line started with 2017. I just used a text editor to replace "2017" with "\r\n2017". The \r\n was just a newline, but I don't think that comes over well in the forums.   ... View more

As the initiator, you won't see much detail. This is by design of IPSec - you don't want to give an attacker a bunch of details why it didn't work so they can figure out the right things that will work.   See if you can initiate from the other side, or see the other side's logs if only you can do the initiating.    Here are your logs with wrapping and monospace font: 2017-02-01 10:26:42 [PROTO_NOTIFY]: ====> IKEv2 IKE SA NEGOTIATION STARTED AS INITIATOR, non-rekey <==== ====> Initiated SA: 202.141.210.58[500]-213.152.246.225[500] SPI:fb7749a0549253cf:0000000000000000 SN:251 <==== 2017-02-01 10:26:42 [PROTO_WARN]: 251:202.141.210.58[500] - 213.152.246.225[500]:0x82fcc40:vendor id payload ignored 2017-02-01 10:26:42 [PROTO_WARN]: 251:202.141.210.58[500] - 213.152.246.225[500]:0x82fcc40:vendor id payload ignored 2017-02-01 10:26:42 [INFO]: CR hash (3) ignored, no match found. 2017-02-01 10:26:42 [PROTO_WARN]: 251:202.141.210.58[500] - 213.152.246.225[500]:0x82fcc40:vendor id payload ignored 2017-02-01 10:26:42 [PROTO_NOTIFY]: ====> IKEv2 CHILD SA NEGOTIATION STARTED AS INITIATOR, non-rekey <==== ====> Initiated SA: 202.141.210.58[500]-213.152.246.225[500] message id:0x00000000 parent SN:251 <==== 2017-02-01 10:26:42 [PROTO_WARN]: 251:202.141.210.58[500] - 213.152.246.225[500]:0x82fcc40:received notify type AUTHENTICATION_FAILED 2017-02-01 10:26:42 [PROTO_NOTIFY]: ====> IKEv2 IKE SA NEGOTIATION FAILED AS INITIATOR, non-rekey <==== ====> Failed SA: 202.141.210.58[500]-213.152.246.225[500] SPI:fb7749a0549253cf:e7fffa7ae266483c SN 251 <==== 2017-02-01 10:26:42 [INFO]: 251:202.141.210.58[500] - 213.152.246.225[500]:(nil):aborting IKEv2 SA jdp-p1:251 2017-02-01 10:26:44 [INFO]: sadb_acquire_callback: seq=0 satype=141 sa_src=202.141.210.58[0] sa_dst=0.0.0.0[0] samode=137 tid=1 selid=137354744 2017-02-01 10:26:45 [INFO]: sadb_acquire_callback: seq=0 satype=141 sa_src=202.141.210.58[0] sa_dst=0.0.0.0[0] samode=137 tid=3 selid=135963664 2017-02-01 10:26:46 [INFO]: sadb_acquire_callback: seq=0 satype=141 sa_src=202.141.210.58[0] sa_dst=213.152.246.225[0] samode=137 tid=10 selid=135964440 2017-02-01 10:26:46 [PROTO_NOTIFY]: ====> IKEv2 IKE SA NEGOTIATION STARTED AS INITIATOR, non-rekey <==== ====> Initiated SA: 202.141.210.58[500]-213.152.246.225[500] SPI:bcfa6b296e75a946:0000000000000000 SN:252 <==== 2017-02-01 10:26:46 [PROTO_WARN]: 252:202.141.210.58[500] - 213.152.246.225[500]:0x8190b20:vendor id payload ignored 2017-02-01 10:26:46 [PROTO_WARN]: 252:202.141.210.58[500] - 213.152.246.225[500]:0x8190b20:vendor id payload ignored 2017-02-01 10:26:46 [INFO]: CR hash (3) ignored, no match found. 2017-02-01 10:26:46 [PROTO_WARN]: 252:202.141.210.58[500] - 213.152.246.225[500]:0x8190b20:vendor id payload ignored 2017-02-01 10:26:46 [PROTO_NOTIFY]: ====> IKEv2 CHILD SA NEGOTIATION STARTED AS INITIATOR, non-rekey <==== ====> Initiated SA: 202.141.210.58[500]-213.152.246.225[500] message id:0x00000000 parent SN:252 <==== 2017-02-01 10:26:47 [PROTO_WARN]: 252:202.141.210.58[500] - 213.152.246.225[500]:0x8190b20:received notify type AUTHENTICATION_FAILED 2017-02-01 10:26:47 [PROTO_NOTIFY]: ====> IKEv2 IKE SA NEGOTIATION FAILED AS INITIATOR, non-rekey <==== ====> Failed SA: 202.141.210.58[500]-213.152.246.225[500] SPI:bcfa6b296e75a946:9dd1de2ab91b7f21 SN 252 <==== 2017-02-01 10:26:47 [INFO]: 252:202.141.210.58[500] - 213.152.246.225[500]:(nil):aborting IKEv2 SA jdp-p1:252 ... View more

1. RSA is good for backward compatibility, but ECDSA is higher security and newer tech. If your users are largely going to be clients using browsers, I'd opt for ECDSA.   2. Either is fine, there is no functional difference. Some admins prefer to separate the duties of the certificates (finer control but more management) and others prefer simplicity. There is no difference at all. It's worth saying that you can use a public CA for the GP gateway and portal as long as you're using hostnames instead of IPs, and that makes the deployment easier as there's nothing needed to push to the clients.   3. I'd push both. There's no reason to not include every CA in the chain when pushing it. However, if your GP portal & gateway certs are signed by a public CA you won't need to push anything to the clients as they'll automatically trust them.   ... View more