- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
07-31-2018 11:41 AM
After upgrading from 8.0.6 to 8.0.10 our local EDL list stopped updating. The logs message states 'Unable to fetch external dynamic list. SSL connect error. Using old copy for refresh'. Anyone have any ideas on how to fix this?
I looked in the release notes from some hints and came up empty.
Thanks - Lora
08-09-2018 12:08 PM - edited 08-09-2018 12:08 PM
The TLS mismatch issue has been resolved by hosting the internally sourced EDL from a more modern web server that supports TLS1.2.
07-31-2018 01:45 PM
Hello,
Anything in the logs that might indicate that the traffic is getting blocked?
Just a thought.
08-01-2018 06:55 AM
Not that I could find anyway. I think it has to do with a new requirement in 8.0 but very strange that we didn't see it enforced until we upgraded from 8.0.6 to 8.0.10 though.
Snipet from the new requirement link above:
08-01-2018 08:08 AM
There was a slight hicup with that where you might not have noticed it directly until post 8.0.7 when that issue was addressed. That being said this would normally generate a more informative error instead of what you posted, which is rather generic. Regardless if you setup the certificate profile or set the EDL to "None" on the Server Authentication it should be able to actually pull the SSL again if that's the issue, so it should be a pretty quick thing to test.
08-01-2018 08:13 AM
We have it set to none and it's not working and that is the only log message I am able to locate 😞
08-01-2018 08:40 AM
Maybe this doesn't matter but did you do this through the CLI or the GUI. I recall an issue a while back that was specific to GUI where setting the certificate-profile to None wasn't the same on the GUI as specifying it in the CLI. Not sure if that ever got fixed or not.
08-01-2018 11:48 AM - edited 08-01-2018 02:30 PM
I tried setting the profile to none via the CLI and that didn't fix either. For those following along the CLI commands I used to set the ertificate-profile to None via the CLI on a Panroma device were:
From configure mode: set shared external-list "Name of Your List" type url certificate-profile None <enter>
then I isseud a comitt and exited configure and issued a commit-all shared-policy device-group <name>
I then watched the system logs on the firewall directly and see the same warning messages as before.
I then checked the object list entries to determine if the list had been update or not and found it was not 😞
Looks like we will need to open a case. Thanks all for the ideas!
08-01-2018 02:13 PM - edited 08-01-2018 02:29 PM
PANTAC has determined this is a TLS mismatch problem and is checking to see if there is an available work around while we determine internaly if we can upgrade the server or move the EDL to a more modern host.
For those following along (and since I could not find this command anywhere) this is what PANTAC did 😉
Set up TCPDump PCAP to capture traffic to the EDL from one CLI window
tcpdump filter "host xx.xx.xx.xx" (xx= ip of the external server hosting the EDL)
From a second CLI window; Ran a manual EDL refresh via the CLI by "request system external-list refresh type url name <name>"
We then exported the PCAP file to my workstatoin
scp export mgmt-pcap from mgmt.pcap to user@analyst_workstation_ip:./
Reviewed the PCAP using wireshark and discovered the Client Hello from the firewall showing TLS 1.2 and the Server Hello shows TLS 1.0, then the firewall sends a fatal error protocol version message.
Lastly to view the local logs from the CLI instead of the GUI, you can issue a command such as this:
tail follow yes mp-log ms.log from one terminal window while re-issuing the request system external-list refresh type url name <name> commands from a second window. In this particular case the raw logs were not more helpful than the GUI logs though - they both just stated "Unable to fetch external dynamic list. SSL connect error. Using old copy for refresh."
More to come when we finally resolve the issue.
08-09-2018 12:08 PM - edited 08-09-2018 12:08 PM
The TLS mismatch issue has been resolved by hosting the internally sourced EDL from a more modern web server that supports TLS1.2.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!