This website uses Cookies. By clicking Accept, you agree to the storing of cookies on your device to enhance your community and translation experience. Read our Privacy Policy.
Click Preferences to customize your cookie settings.
Accept
Reject
Preferences

About darren_g

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
darren_g
‎09-24-2024
since ‎09-16-2012
L4 Transporter
User Activity
User Profile
Latest posts by darren_g
View All
User Badges
Community Statistics
Member Since ‎09-16-2012 09:05 PM
Date Last Visited ‎09-24-2024 07:23 PM
Posts 287
Total Likes Received 57

Why do "incomplete" sessions show as "allowed"

by in General Topics
‎02-26-2013 04:36 PM
1 Kudo
‎02-26-2013 04:36 PM
1 Kudo
Hi. I've got some pretty specific firewall rules for machine in our DMZ, and I noticed some intriguing log entries while checking into an (unrelated) issue today. I get a log entry which reads like this 02/27 11:42:30      end     outside     DMZ     <source_ip>     <destination_ip>     1433      incomplete     allow     <rule_name>     152 (I've obfuscated the IP addresses etc). Why doesn't this show as a "deny" when the application doesn't match one on the permitted list for this rule? Even the port doesn't match one covered by any of the allowed applications in the rule. It's not effecting anything, I'm just curious. ... View more
Labels:

Re: PA2020 High CPU utilization "useridd" 100% management plane

by in General Topics
‎02-26-2013 03:50 PM
‎02-26-2013 03:50 PM
No, it's definitely present in 4.1.11 (and the supposed "hotfix" 4.1.11-h1 breaks other things) - and as far as I'm aware you can't do agent-less userID on v4. ... View more

Re: PA2020 High CPU utilization "useridd" 100% management plane

by in General Topics
‎02-26-2013 02:14 PM
‎02-26-2013 02:14 PM
This is on version 4, or version 5? I'm holding off on upgrading to V5 from past experience with Palo Alto's .0 release history! I won't upgrade to it until I hear from the learned denizens of these august forums that it appears stable. ... View more

Re: PA2020 High CPU utilization "useridd" 100% management plane

by in General Topics
‎02-26-2013 01:38 PM
1 Kudo
‎02-26-2013 01:38 PM
1 Kudo
And rolling back *again* after installing the "hotfix" 4.1.11-h1 because it bloody breaks the HA sync between my peers. This is beyond a joke, Palo Alto. Does *nobody* QA these things in all possible environments before release? ... View more

Re: Is there a reason to hide hotfixes in Software Update?

by in General Topics
‎02-26-2013 01:35 PM
1 Kudo
‎02-26-2013 01:35 PM
1 Kudo
Because then Palo Alto don't get embarrassed by everyone when a hotfix fixes one bug, and introduces another one! I just installed 4.1.11-h1 to supposedly fix the high management CPU issue - which it does. But now I can't sync my config between my HA partners no matter what I try! Second time in two days I've had to roll back from an "update". Ridiculous. ... View more

Re: PA2020 High CPU utilization "useridd" 100% management plane

by in General Topics
‎02-25-2013 04:00 PM
‎02-25-2013 04:00 PM
> PA: How does this stuff get past the QA process? More to the point - if it's a known issue which is being reported by lots of people, why do you have to log a fault to get access to the hotfix? Why doesn't PAN just release the hotfix for general distribution with a release note which specifies that it's only to fix the issue listed? This jumping through hoops to get fixes for known, impact-inducing bugs is extremely annoying. And when I *did* log a case, the first thing I get back from the support partner is "We've escalated it to PAN for release of the hotfix, but why don't you update to 5.0.1 instead"? ... View more

Re: Virus install high CPU on Active, not standby?

by in General Topics
‎02-25-2013 02:50 PM
‎02-25-2013 02:50 PM
Never mind. I found other discussions which indicate this is a bug in 4.1.11 - rolling back to 4.1.10 now. Thank god for HA pairs. ... View more

Re: PA2020 High CPU utilization "useridd" 100% management plane

by in General Topics
‎02-25-2013 02:44 PM
‎02-25-2013 02:44 PM
Well, you just answered my question - rolling back to 4.1.10 as I type. ... View more

Re: high management CPU

by in General Topics
‎02-25-2013 02:36 PM
‎02-25-2013 02:36 PM
I'm seeing this on 4.1.11 - is there anything reported on this release? I can't see any one process in the system resources which is chewing up all the CPU, yet the management interface tells me the management CPU is running at 100% top - 09:32:45 up 8 days, 21 min,  1 user,  load average: 8.15, 9.01, 9.49 Tasks:  98 total,   2 running,  96 sleeping,   0 stopped,   0 zombie Cpu(s): 24.0%us, 36.4%sy,  3.2%ni, 35.9%id,  0.1%wa,  0.0%hi,  0.3%si,  0.0%st Mem:    995888k total,   868512k used,   127376k free,    13708k buffers Swap:  2008084k total,   320776k used,  1687308k free,   310732k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 2394       20   0  169m  36m  32m S  182  3.8  11730:01 useridd 12802       30  10  3896 1276 1092 R    5  0.1   0:06.13 genindex.sh 13886       20   0  4468 1032  800 R    3  0.1   0:00.05 top 2387       20   0  273m  63m 1616 S    2  6.5  19:46.28 logrcvr     1       20   0  1836  564  536 S    0  0.1   0:02.30 init     2       20   0     0    0    0 S    0  0.0   0:00.00 kthreadd     3       RT   0     0    0    0 S    0  0.0   0:02.85 migration/0     4       20   0     0    0    0 S    0  0.0   0:00.03 ksoftirqd/0     5       RT   0     0    0    0 S    0  0.0   0:02.78 migration/1     6       20   0     0    0    0 S    0  0.0   0:00.08 ksoftirqd/1     7       20   0     0    0    0 S    0  0.0   0:00.39 events/0     8       20   0     0    0    0 S    0  0.0   0:00.08 events/1     9       20   0     0    0    0 S    0  0.0   0:00.03 khelper    12       20   0     0    0    0 S    0  0.0   0:00.00 async/mgr   112       20   0     0    0    0 S    0  0.0   0:00.00 sync_supers   114       20   0     0    0    0 S    0  0.0   0:00.00 bdi-default   115       20   0     0    0    0 S    0  0.0   0:02.19 kblockd/0   116       20   0     0    0    0 S    0  0.0   0:01.28 kblockd/1   125       20   0     0    0    0 S    0  0.0   0:00.00 ata/0   126       20   0     0    0    0 S    0  0.0   0:00.00 ata/1   127       20   0     0    0    0 S    0  0.0   0:00.00 ata_aux   132       20   0     0    0    0 S    0  0.0   0:00.00 khubd   135       20   0     0    0    0 S    0  0.0   0:00.00 kseriod   154       20   0     0    0    0 S    0  0.0   0:00.00 rpciod/0   155       20   0     0    0    0 S    0  0.0   0:00.00 rpciod/1   167       20   0     0    0    0 S    0  0.0   1:13.35 kswapd0   168       20   0     0    0    0 S    0  0.0   0:00.00 aio/0   169       20   0     0    0    0 S    0  0.0   0:00.00 aio/1   170       20   0     0    0    0 S    0  0.0   0:00.00 nfsiod   723       20   0     0    0    0 S    0  0.0   0:00.06 octeon-ethernet   741       20   0     0    0    0 S    0  0.0   0:00.00 scsi_eh_0   743       20   0     0    0    0 S    0  0.0   0:00.00 scsi_eh_1   750       20   0     0    0    0 S    0  0.0   0:01.23 mtdblockd   773       20   0     0    0    0 S    0  0.0   0:00.00 usbhid_resumer   812       20   0     0    0    0 S    0  0.0   0:34.67 kjournald   865       16  -4  2008  392  388 S    0  0.0   0:01.34 udevd 1713       20   0     0    0    0 S    0  0.0   0:01.68 kjournald 1714       20   0     0    0    0 S    0  0.0   0:00.00 kjournald 1800       20   0     0    0    0 S    0  0.0   0:32.48 flush-8:0 1859       20   0  2008  640  572 S    0  0.1   0:00.62 syslogd 1862       20   0  1892  332  328 S    0  0.0   0:00.02 klogd 1870 rpc       20   0  2084  492  488 S    0  0.0   0:00.01 portmap 1888   20   0  2116  652  648 S 0  0.1   0:00.06 rpc.statd 1957   20   0  6852  492  412 S 0  0.0   0:00.01 sshd 2005   20   0  6788  404  400 S 0  0.0   0:00.00 sshd 2014   20   0  3280  616  612 S 0  0.1   0:00.01 xinetd 2033   20   0 0 0 0 S 0  0.0   0:00.00 lockd 2034   20   0 0 0 0 S 0  0.0   1:10.63 nfsd 2035   20   0 0 0 0 S 0  0.0   1:11.76 nfsd 2036   20   0 0 0 0 S 0  0.0   1:14.73 nfsd 2037   20   0 0 0 0 S 0  0.0   1:16.72 nfsd 2038   20   0 0 0 0 S 0  0.0   1:18.89 nfsd 2039   20   0 0 0 0 S 0  0.0   1:08.08 nfsd 2040   20   0 0 0 0 S 0  0.0   1:08.19 nfsd 2041   20   0 0 0 0 S 0  0.0   1:07.54 nfsd 2044   20   0  2360  676  576 S 0  0.1   0:02.35 rpc.mountd 2107    0 -20 62228 4596 1936 S 0  0.5  21:25.51 masterd_core 2117    0 -20 26132 1372 1004 S 0  0.1   0:35.20 masterd_manager 2124   15  -5 38576 5244 1268 S 0  0.5 279:50.74 sysd 2126    0 -20 30324 4828 1072 S 0  0.5  28:22.05 masterd_manager 2130   20   0 90584 7148 1896 S 0  0.7   3:07.52 dagger 2131   30  10 38772 3600 1672 S 0  0.4  25:30.28 python 2132   20   0 76744 3128 1700 S 0  0.3   2:47.90 cryptod 2133   20   0  164m 1932 1332 S 0  0.2   4:57.28 sysdagent 2147   20   0  7212  872  868 S 0  0.1   0:00.08 tscat 2150   20   0 69768 1092  948 S 0  0.1   2:30.10 brdagent 2151   20   0 30080 1156  976 S 0  0.1   1:24.66 ehmon 2152   20   0 45560 1156 1012 S 0  0.1   0:03.49 chasd 2317   20   0 0 0 0 S 0  0.0   0:07.30 kjournald 2349   20   0  2896  624  572 S 0  0.1   0:00.21 crond 2357   20   0  520m 211m 4284 S 0 21.7  82:23.88 mgmtsrvr 2378   20   0  386m  70m  10m S 0  7.3  24:08.62 devsrvr 2386   20   0 90052 2648 1500 S 0  0.3   1:13.27 ikemgr 2388   20   0 97216 2524 1596 S 0  0.3  33:34.36 rasmgr 2389   20   0 97020 1588 1148 S 0  0.2  23:40.02 keymgr 2390   20   0  199m 1912 1224 S 0  0.2   8:14.65 varrcvr 2391   17  -3 54472 1812 1260 S 0  0.2   0:41.29 ha_agent 2392   20   0 84852 1420 1120 S 0  0.1   0:01.00 sslmgr 2393   20   0 55288 1628 1144 S 0  0.2   0:01.62 dhcpd 2395   20   0 73356 1760 1180 S 0  0.2   0:02.43 dnsproxyd 2396   20   0 72588 1512 1084 S 0  0.2   0:02.48 pppoed 2397   20   0  133m 2944 1780 S 0  0.3   1:29.95 routed 2398   20   0  131m 4900 3360 S 0  0.5  76:31.29 authd 2741   20   0 21324 1200  832 S 0  0.1   0:00.19 sshd 2801 darren 20   0 21460 1020  656 S 0  0.1   0:00.09 sshd 2802 darren 20   0 95072  11m 2464 S 0  1.2   0:04.66 cli 2978 nobody 20   0  206m  37m 4340 S 0  3.8 140:35.43 appweb3 2990   20   0 25520 1720 1408 S 0  0.2   0:30.59 snmpd 3889 nobody 20   0  191m  19m 3232 S 0  2.0 517:48.40 appweb3 3902 nobody 20   0  113m 1912 1396 S 0  0.2   0:32.93 appweb3 8993   20   0  1824  448  444 S 0  0.0   0:00.01 agetty 11476   20   0  3744 3624 2756 S 0  0.4   0:00.00 ntpd 12756   20   0  2960  500  412 S 0  0.1   0:00.00 crond 12758   20   0  3720 1116  988 S 0  0.1   0:00.01 genindex_batch. 12765   20   0 31688 4908 2884 S 0  0.5   0:00.41 masterd_batch 13880 darren 20   0  2976  668  564 S 0  0.1   0:00.04 less 13883   20   0  3832 1192 1056 S 0  0.1   0:00.05 sh 13887   20   0  1940  540  464 S 0  0.1   0:00.00 sed ... View more

Virus install high CPU on Active, not standby?

by in General Topics
‎02-25-2013 02:28 PM
‎02-25-2013 02:28 PM
Hi. Configuration : 2 x PA2020, Active/passive, running 4.1.11, trying to install AV release 957-1328 I noticed today while pushing a virus definition update that the active node in my active/standby takes an absolute age to install/update, with the management CPU running at 100% for most of the process, but the standby node not only finishes faster, it doesn't have nearly the CPU utilisation while this process is running. For example, from today's job logs. Standby node Enqueued                ID        Type Status Result Completed -------------------------------------------------------------------------- 2013/02/26 08:50:48     35   Antivirus  FIN OK 09:03:05 2013/02/26 08:48:23     34     Install  FIN OK 08:50:48 2013/02/25 12:08:48     33     HA-Sync  FIN OK 12:10:42 2013/02/25 10:57:48     32     HA-Sync  FIN OK 10:59:42 2013/02/23 20:20:40     31   Antivirus  FIN OK 20:32:48 2013/02/23 20:18:58     30     Install  FIN OK 20:20:41 Active node Enqueued                ID        Type Status Result Completed -------------------------------------------------------------------------- 2013/02/26 08:48:19     42   Antivirus  ACT   PEND   45% 2013/02/26 08:16:14     41     Install  FIN OK 08:48:20 2013/02/26 08:15:12     40      Downld  FIN OK 08:15:27 2013/02/25 12:01:13     39      Commit  FIN OK 12:08:58 2013/02/25 10:50:10     38      Commit  FIN OK 10:57:55 2013/02/23 20:18:55     37   Antivirus  FIN OK 20:49:49 2013/02/23 20:00:49     36     Install  FIN OK 20:18:55 2013/02/23 20:00:34     35      Downld  FIN OK 20:00:46 Notice the difference in times - the passive node runs the install in about 15 minutes, the active node has now been running (time is approx 09:25:00) more than 35 minutes and is only at 45%. Is anyone else seeing this? Is it expected behaviour? I can;t say I've ever seen the virus update take this long before I installed 4.1.11 - is this an issue in this release? I can roll back if necessary. EDIT: I've just noticed that it's apparently not the virus install job causing this - the job is now finished, and the management CPU is still running at 100%. Any ideas? I can reboot, but I'd rather not just to fix a high management CPU use if I can avoid it. Thanks ... View more
Labels:

Re: User authentication - Global Protect

by in General Topics
‎01-23-2013 01:48 PM
‎01-23-2013 01:48 PM
Yeah, I got it right eventually. It was a rather contorted process, and the documentation I found is somewhat dated and doesn't apply properly to current versions, but with some help from people here I got it working. It came down to two configuration options I had wrong In the LDAP server profile, you need to make sure you have your domain in the "Domain" section of the configuration - the documentation indicated I could leave that blank, but this is *not* the case. In the Authentication profile group list, you need to enter your group in domain\group format, not in DN string format (which the firewall defaults to) - so instead of cn=<group>,dc=<domain>,dc=<suffix> format you need to put domain\group - you will likely need to manually enter this in the correct format. There's a whole bunch of CLI troubleshooting you can do - if you can't get it working, do a search on discussions started by me with the title "LDAP Authentication not matching user groups", and you should find more hints. Cheers. ... View more

Re: Site to site VPN issue

by in General Topics
‎01-21-2013 05:01 PM
‎01-21-2013 05:01 PM
Never mind, found the issue - had to tweak the Cisco end a bit to get it to accept the additional time frame parameters. All good now. No more excessive log entries! ... View more

Re: Moving from Global Protect 1.1.6 -> 1.1.7

by in General Topics
‎01-21-2013 04:44 PM
‎01-21-2013 04:44 PM
Sorry, can you just clarify this for me please? You said > if you are using a FQDN as the CN in the cert, the FQDN must the interface of the firewall the client connects to The FQDN must WHAT the interface of the firewall the client connects to? I connect my clients via a registered FQDN in my domain name (vpn.domain.com) in the GP client. My current certificate has the name as "vpn.domain.com", but the CN as the IP address of the interface. Do I need to generate a new certificate with vpn.domain.com for name **and** CN?? thanks ... View more

Site to site VPN issue

by in General Topics
‎01-21-2013 04:24 PM
‎01-21-2013 04:24 PM
Folks. I have an issue with some site-to-site configurations that is bugging the cr*p out of me, and I thought I'd post it here. I run some site-to-site VPN's (Palo Alto to Cisco 887 routers) which come up fine, but which seem to defy *all* configuration with respect to IpSec SA lifetime. As far as I can tell, I've configured a 12 hour (43200 second) lifetime, yet when the IPSec is negotiated, I get this in the logs. IPSec key installed. Installed SA: www.xxx.yyy.zzz[500]-aaa.bbb.ccc.ddd[500] SPI:0x8AA8C96C/0x49847307 lifetime 3600 Sec lifesize 4608000 KB. Note the "3600 Sec" lifetime - which is only 1 hour. Now, this is not a real big deal - apart from adding extra lines into my logs, it's not a real hassle - but it's just peeving me off that I can't solve it. Is there anywhere else I should look for lifetime settings besides the "IPSec Crypto" setting int he network configuration? Thanks ... View more
Labels:

Re: LDAP authentication not matching user groups

by in General Topics
‎11-20-2012 08:06 PM
‎11-20-2012 08:06 PM
Yee Ha! Found it! And what's more, it works! Login via the web portal *and* the GlobalProtect client works!! You're a legend, Kevin! Thanks so much for your input! ... View more
Register or Sign-in
Contact Me
Online Status
Offline
Date Last Visited
‎09-24-2024 07:23 PM
Likes Given To
LEGAL NOTICES
RESOURCES
Khoros awards 2022
Copyright 2007 - 2025 - Palo Alto Networks