About Sven_Lieckfeldt

Sven_Lieckfeldt · ‎09-01-2015

Hi Luciano, thanks for your answer and sorry for the delay in my answer. I didn't received a notification... The article refers to PAN-OS 5, so I've double checked the version 6.1 document. And in the syslog portion it is stated that "before change detail" and "after change detail" are onyl used in the custom syslog format, not in the default one. So I've played around with it now these two informations are submitted, more or less complete. For exmaple: An application group with many apps included would be altered in the "before change detail" but the changed value is available. So one can follow the trace... Now it looks like this: palotalto.domain.com 1,2015/09/01 10:38:49,S/N,CONFIG,0,2015/09/01 10:38:49,1.2.3.4,,edit,admin,Web,Succeeded, vsys vsys1 application-group Test-Apps,4296,0x0,Test-Apps { } ,Test-Apps [ aim-file-transfer ]; Thanks for you hint!

Sven_Lieckfeldt · ‎08-24-2015

Hi Luciano, we're running PAN-OS 6.1.5. Logshipping is done via UDP; we've tried TCP with no difference in the result. CONFIG logs are successful submitted, but a portion of the content is missing; see my sample snippets. When you export Montior > Configuration to a csv file you have two fields called "before-change-detail" and "after-change-detail". Those two fields are missing in the syslog stream. Update 1: Just did a tcpdump as suggested. Data is sent, but without those two fields in question. Cheers, Sven

Sven_Lieckfeldt · ‎08-24-2015

Hi there, we're shipping our logs to a centralized syslog instance. That works great for all types of logs from the PA with the exceptions of the CONFIG logs. The CONFIG logs are submitted at all, with the problem that the interesting parts "before-change-detail" and "after-change-detail" are not delivered. Does anyone else ship CONFIG logs and if yes, do you see the same behaviour? Thanks for advice. Submitted Syslog Message 2015-02-02 10:32:59 User.Info 1.2.3.4 Feb 2 10:32:59 paloalto.domain.com 1,2015/02/02 10:32:59,123444,CONFIG,0,0,2015/02/02 10:32:59,1.2.33.4,,edit,admin-name,Web,Succeeded, vsys vsys1 rulebase security rules one-rule-to-rule-them-all,1544,0x0 Expected Syslog Message 2015-02-02 10:32:59 User.Info 1.2.3.4 Feb 2 10:32:59 paloalto.domain.com 1,2015/02/02 10:32:59,123444,CONFIG,0,0,2015/02/02 10:32:59,1.2.33.4,,edit,admin-name,Web,Succeeded, vsys vsys1 rulebase security rules one-rule-to-rule-them-all,before-change-detail,after-change-detail,1544,0x0

Sven_Lieckfeldt · ‎06-18-2015

Hi Steven, thanks for your answer! We're not logging allowed traffic to avoid logs blowing our firewall. So that would be fine. So I've the following options: - put proxy's into another zone - scan the proxy logs Cheers, Sven

Sven_Lieckfeldt · ‎06-17-2015

Hi there, we're running the following setup: trusted zone | DC zone | Internet Client/Proxy/some old DNS Server| DNS Server| Internet I see that the PA is blocking malware traffic (app DNS). But the attacker is either the proxy, asking the DNS in the DC zone, or the old DNS server, asking DNS servers in the Internet. Unforunately that way I don't get the compromised machine. What do you guys have in place to identify such computers? Put the proxy and the old DNS in a different zone? Or is the DNS sinkhole the way to go? Thanks for your suggestions. Cheers, Sven

Sven_Lieckfeldt · ‎06-11-2015

Hi ggoudr, what does the pangpa.log say? Most of the GP issues are looking similiar (it doesn't work) but having different root causes. Also, could you access the portal website? Cheers, Sven

Sven_Lieckfeldt · ‎03-18-2015

Those two cases are going more in the direction of certificate issues. In the meanwhile we got it resolved. That was a tricky one: When logging on to Windows a script is running, which is importing the proxy settings from IE to winhttp (netsh winhttp show proxy). This is necessary, because the native Windows 8 apps have trouble with a proxy server. The winhttp settings were kind of corrupt or at least incorrect, because the exceptions were missing so they were not identical with the settings from IE. The GP client is running into trouble with this. So we either had to reset the settings (netsh winhttp reset proxy) or re-import the correct settings again. Once set correctly everything has worked as expected. Very odd...

Sven_Lieckfeldt · ‎03-16-2015

Hi there, we're having some clients which are not able to connect. The odd thing is: There are only a few clients and currently there is no obvoius reason for me why this is happenig. They're even not reaching a stage, where the PA does log anything in the System log. The GP Client does require a certificate in the local computers certificate store, which is available. I see in the pangpa.log this error: "(T5664) 03/16/15 10:38:02:351 Debug(1064): HandlePortal - portal messsage with Invalid portal status received. m_nAuthTries = 1" In the pangps.log I see the following errors; I can paste the rest of the logfile if needed. When I try to attempt to visit the site on the webbrowser, it's showing up. (T2960) 03/16/15 10:38:01:976 Debug( 109): GetProxyInfo, winhttpgetproxyforurl failed, lastError=12006 (T2756) 03/16/15 10:38:02:023 Error( 120): NetUserGetInfo is unknown error (T2960) 03/16/15 10:38:02:054 Error( 857): PostRequest failed with error code 12007. (T2960) 03/16/15 10:38:02:054 Debug(3281): Failed to pre-login to the portal sg.planethome.com. Error 12007 Any help would be appreciated. Cheers, Sven

Sven_Lieckfeldt · ‎03-03-2015

Hi Satish, that is set to "on-demand" and "Use SSO" is _not_ checked. Thanks, Sven

Sven_Lieckfeldt · ‎03-02-2015

Hi mmmccorkle, sorry for my late replay - I was on vacation. Yes, they connected for the very first time with this user and on that machine. Thanks, Sven

Sven_Lieckfeldt · ‎02-20-2015

Hi Hari, I checked the logs again. But I don't see any difference from the globalprotectgateway-auth-succ Event for the users who are asked for credentials and those who are not. They all pass the same auth type: Profile. Cheers, Sven

Sven_Lieckfeldt · ‎02-20-2015

Hi there, we're piloting the GP Client with a few people. Some of them are asked for credentials when connecting (expected behaviour) and some people are not asked for their credentials, but connected successful (not expected). We definitely haven't turned on SSO. The Clients are all installed by the same software distribution task. Also, I can not see anything suspicous in the logs that leads me to the root cause of the SSO... And, as usual with such issues, I'm not able to reproduce it 😕 Have you experienced this in the past? Thanks, Sven

Sven_Lieckfeldt · ‎02-12-2015

Hi Phil, I've disabled IPv6 but the first connection after a restart is still quite slow. According to the logging of the connection establishment on PA Service and Agent it only takes a few seconds; the log on PA does show the same picture. May the SSL/TLS handshake takes that long? But why only on the first connection establishment after computer restart? Hi oklier, I don't have the impression that latency is the issue. But indeed we do have another PA als passive in our DR side. But as long as the PA is passive it shouldn't interfere, if I'm not wrong. Thanks, Sven

Sven_Lieckfeldt · ‎02-10-2015

Hi there, we're experiencing a not-really fast connection establishment from the GlobalProtect client; with client cert and user credentials for authentication. When the computer has been restarted it can take up to 25 seconds. A re-connect later takes approx. 10 seconds. Currenty we're using the CheckPoint Client for VPN (credentials only), and the connection establishment is much faster; approx 5 seconds. What is your experience with the connection establishment? Thanks, Sven

Sven_Lieckfeldt · ‎02-10-2015

Hi Hardik, thanks for your answer. Unfortunately xff doesn't solve our problem at all. We are able to map clientip to user, but that doesn't do the trick on the Citrix server; where 50 users share the same IP address. Also, with xff the User-ID Agent data is not used in the Traffic Log, which isn't really handy. The following approach seems to be feasible for us: Allowing the same websites/applications on the border from internal-lan to DMZ, as the proxy has, gives us the possibility to see who has tried to access a website. In this scenario the User-ID Agent does work, because the connection is established first by the Citrix server and after then handed over to the proxy. Regards, Sven

Member Since	‎01-30-2015 12:36 AM
Date Last Visited	‎06-19-2017 03:10 AM
Posts	16
Total Likes Received	2

Online Status	Offline
Date Last Visited	‎06-19-2017 03:10 AM

About Sven_Lieckfeldt

Re: CONFIG logs and syslog

Re: CONFIG logs and syslog

CONFIG logs and syslog

Re: PA blocks spyware - identify compromised computer

PA blocks spyware - identify compromised computer

Re: CONFIG logs and syslog

Re: CONFIG logs and syslog

Re: Pre-Logon Global Protect

Re: CONFIG logs and syslog

Re: CONFIG logs and syslog

CONFIG logs and syslog

Re: PA blocks spyware - identify compromised computer

PA blocks spyware - identify compromised computer

Re: GlobalConnect - portal messsage with Invalid portal status received

Re: GlobalConnect - portal messsage with Invalid portal status received

GlobalConnect - portal messsage with Invalid portal status received

Re: Global Protect Client not asking for passwort

Re: Global Protect Client not asking for passwort

Re: Global Protect Client not asking for passwort

Global Protect Client not asking for passwort

Re: GlobalProtect Client - connection establishment speed

GlobalProtect Client - connection establishment speed

Re: PA with proxy, user logging in traffic log

Network Security

Cloud Security

Security Operations

About Sven_Lieckfeldt