What are some workarounds / fixes for UTM/IDP on Junos 12.1X44-D10.4 for SRX Series branch devices

juniperjuniper-srx

The JNCIP / JNCIE-SEC latest courses use 12.1X44-D10.4 as the recommended Junos version. I setup a 30-day evaluation on my home SRX device to study JIPS, based on 12.1. At this point, I'm guessing that my problem is that trial licenses for 12.1X44-D10.4 might be equivalent to 12.2, 12.3, or entirely not supported. Here's what I'm trying now:

netops> request security idp security-package download full-update    
Will be processed in async mode. Check the status using the status checking CLI

root> request security idp security-package download status         
In progress:SignatureUpdate_tmp.xml.gz                          100 % 2034681 Bytes/ 2034681 Bytes

root> request security idp security-package download status    
Done;File applications.xml.gz is corrupt - MD5 hash match failed

Since the license installed properly (but not the IDP signatures), I was also going to manually request a download with the proper URL parameters (mentioned in KB19502)

I've had no luck on Juniper.net, but here are my planned next steps:

  • Sniff the traffic / figure out which version it's trying to download
  • Manually request a download, eg. https://services.netscreen.com/cgi-bin/index.cgi?device=jsrx650&feature=idp&os=10.3&detector=10.4.160100823&from=1817&to=1805&type=update
  • Talk to my Juniper rep this week (and yes, I'm adding support on this device). Edit: opened a Customer Care ticket with Juniper, as it's a new device. Will follow up with resolution.
  • I'm reading through the techpubs/documentation to see if there are any additional steps that could be causing this to fail, but I've tried the usual suspects like name resolution, system time/NTP, etc. etc.

Edit: downgrading to 12.1R5.5 did not fix the issue, and I'm still getting corrupt/md5 hash match failed. This does not appear to be due to lack of storage, which could cause weird errors like this.

Best Answer

It appeared this was an easy fix (I also tried 12.1R6.5 and 12.1X44-D11.5, to no avail).

First, I looked at the version of the signature DB that it's trying to download (2263):

 netops> request security idp security-package download check-server    
 Successfully retrieved from(https://services.netscreen.com/cgi-bin/index.cgi).
 Version info:2263(Detector=12.6.160130325, Templates=2263)

Then, I decided that this is possibly an actual bad md5 checksum (per what Junos expects), and I downloaded the previous version, 2262:

 netops> request security idp security-package download version full-update 2262    
 Will be processed in async mode. Check the status using the status checking CLI

It worked! I've had to do something similar on Netscreen, but it's been a while. I turned off automated updates, and I can get back to studying.

 netops> request security idp security-package download status    
 Done;Successfully downloaded from(https://services.netscreen.com/cgi-bin/index.cgi).
 Version info:2262(Tue May 14 16:27:00 2013 UTC, Detector=12.6.160130325)

Now that the download is finished, everything is installing properly:

 netops> request security idp security-package install          
 Will be processed in async mode. Check the status using the status checking CLI

 netops> request security idp security-package install status 
 In progress:performing DB update...

 netops> request security idp security-package install status    
 In progress:performing DB update for an xml (groups.xml)

 netops> request security idp security-package install status
 In progress:performing DB update for an xml (applications.xml)

 etc.

 netops> request security idp security-package install status    
 Done;Attack DB update : successful - [UpdateNumber=2262,ExportDate=Tue May 14 16:27:00   2013 UTC,Detector=12.6.160130325]
 Updating control-plane with new detector : successful
 Updating data-plane with new attack or detector : not performed
  due to no active policy configured.

I'm thinking that this is either a bug in SRX110H-VA, a combination of hardware/software release, or bad signature updates on services.netscreen.com. I'm pretty sure that I could just look through the XML, and figure out where the bad md5sum is (and fix it by hand), but I'll follow up once I hear back from Juniper.

Newest edit: I also had to manually download the policy template from Juniper, extract it with gzip -d templates.xml.gz, and place it in /var/db/idpd/sec-download/sub-download/. Once that was done, I was able to install it. The issue here is that the request security idp security-package install policy-templates command does not take a 'version', like the other idp commands. This will always be an issue when the head IDP policy has md5 errors, although I would hope that this isn't a frequent occurrence at Juniper.

 netops> request security idp security-package install policy-templates 
 Will be processed in async mode. Check the status using the status checking CLI

 netops> request security idp security-package install status              
 Done;policy-templates has been successfully updated into internal repository
 (=>/var/db/scripts/commit/templates.xsl)!
Related Topic