About kenvizena

Then have someone fix the expedition-beta install package? I ran it after upgrading expedition from 1.1.28 or 1.1.29 and running it afterward fixed the remediation error in the web gui. I will go through the package to see where it is failing when I have time, but we haven't had much time to use Expedition as of late.    Remediation: Execute the following command in CLI : sudo apt-get install expeditionml-dependencies-beta   I rolled back the machine to an earlier version to get the error I received.    ---------------------- Setting up expeditionml-dependencies-beta (0.1.1) ... Allow firewall ports for reporting sudo firewall-cmd --permanent --add-port=5140-5150/tcp sudo: /usr/bin/firewall-cmd: command not found sudo firewall-cmd --permanent --add-port=4060-4070/tcp sudo: /usr/bin/firewall-cmd: command not found sudo: firewall-cmd: command not found /var/lib/dpkg/info/expeditionml-dependencies-beta.postinst: line 9: /opt/Spark/postScripts/getCPUs.sh: No such file or directory /var/lib/dpkg/info/expeditionml-dependencies-beta.postinst: line 10: /opt/Spark/postScripts/unpackPackages.sh: No such file or directory dpkg: error processing package expeditionml-dependencies-beta (--configure): subprocess installed post-installation script returned error exit status 127 Setting up expedition-beta (1.1.38) ... Checking for old projects and Devices what are not Encrypted sudo: /usr/bin/firewall-cmd: command not found sudo: /usr/bin/firewall-cmd: command not found cp: cannot create regular file '/opt/Spark/log4j.properties': No such file or directory its recommended to run after install: apt-get -y -f install its recommended to run after install: sudo apt-get autoremove Errors were encountered while processing: expeditionml-dependencies-beta E: Sub-process /usr/bin/dpkg returned an error code (1) ---------------------     ... View more

The first time it ran that was my order, but it failed on the dependencies.    I ran it the second time with the dependencies first and it was successful.  ... View more

This worked for me.   sudo apt-get update (do not do apt-get upgrade) sudo apt-get install expeditionml-dependencies-beta sudo apt-get install expedition-beta ... View more

There was an update this morning when I logged into the cli. I apt upgraded to 1.1.27 and no longer get the error.  ... View more

You are likely running into the same bug a few of us are experiencing. I just blew everything away to provide my project file to PA. Although, I did notice that this morning there was a new version, nonetheless if it is still broken I will be sending my project file to them. Ken ... View more

Yep, I will do it in the morning.    Thanks for the help! ... View more

I have removed all devices and projects about fifteen times on the current release and the policies don't show up. If I manually enter a non-Panorama firewall it works. I have tried with about twenty different Panorama managed dg's, none of them show up. I have expanded the dg's and imported them and the Panorama dg's do not show polices, but nat, pbf, and all other objects show up.          ... View more

In prior versions if I had a Panorama connected dg I could see it in security policies. I can see nat and all of the other elements, but not policies. Occasionally when loading I will see a brief flash of the policies and then a blank screen. No weird errors in the logs.    I use Expedition for fifty or sixty ha pairs and selectively choose log export since most of our firewalls generate 15-50gb of logs per day. I don't see any form of resource constraint since our primary VM is in a server farm.  I loaded it on a vm at my house on a 1.1.24 and it works as expected. I can see the policies, so did I miss something in the release notes?   Anyhow, thanks for the help!  ... View more

I have the same issue, it worked until I upgraded to the latest version. The odd thing is when I choose the device group, nat rules and everything else shows up, but not security policies.    Weird, I am sure there will be an update to fix whatever was broken.  ... View more

This has popped up two or three times for me, in the first two it was running a fw that was a higher version than Panorama. My most recent example was running an older version of 8.0.x log collectors against a 8.1.x Panorama and 8.1.x FW.    I would do a show logging-status to see if there is a misconfiguration and make note of the addresses.    Take the results from the prior command:   show netstat all yes | match 10.x.x.x   It should look something like this:   tcp your.firewall.com:50000 10.x.x.x:pan-panorama establshed   If that looks fine, then I would logon to the Panorama CLI and run this command:   show netstat all yes | match 3978 (may be 3798, not at a console)   If it shows an active connection and you are running the exact same version on the fw, panorama or log collectors I would open a case with PA.    I would verify the the time on all devices match and if using log collectors to make sure the dynamic updates are working and all are the same version, otherwise collation will not allow the logs to be processed.   You can try and run this from Panorama to see if it can restart the connection.    request log-fwd-ctrl device SERIALNUMBER start-from-lastack request log-fwd-ctrl device SERIALNUMBER action stop request log-fwd-ctrl device SERIALNUMBER action live request log-fwd-ctrl device SERIALNUMBER action start   https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClFCCA0 https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClXACA0     ... View more