Solved: Variable Set Failed Validation

Christopher Bell · ‎02-22-2016

Hello,

Last Friday I took the time to upgrade our FMC to 6.0 from 5.4.1.5. The SFRs are all still running 5.4.1.5 code. After the upgrade I found the policies had to be reapplied to each of the devices under the "Deploy" button at the top now (this took me a while to figure out). When I tried to apply the policies as they were in 5.4.1.5, I got warnings for each of my rule sets that said "Variable Set Failed Validation". On a 5506 we have in a test environment I was able to push past the warnings and apply the policies anyway. This resulted in all the policies being removed completely. For the production devices (5525, 5545, 5515) I'm not able to push past the warning - FMC wants the issues resolved before it will allow you to reapply the policies.

Any ideas on where to look or what may be causing this? We aren't using any custom variables. Filtered screenshot attached from FMC and two of the rules in one policy for one device.

If this posts answers your question or is helpful, please consider rating it and/or marking as answered.

Aastha Bhardwaj · ‎02-24-2016

Issue seen on 6.0.0 , upgrade to 6.0.0.1 resolved the issue.

Regards,

Aastha Bhardwaj

View solution in original post

Christopher Bell · ‎02-23-2016

Nobody has seen this?

If this posts answers your question or is helpful, please consider rating it and/or marking as answered.

Marvin Rhoads · ‎02-23-2016

I haven't seen it.

I've done about four upgrades to 6.0 so far, both on-box (ASDM-based) and with FMC.

I'd open a TAC case - the TAC "Sourcefire" team is really quite good.

Aastha Bhardwaj · ‎02-24-2016

Issue seen on 6.0.0 , upgrade to 6.0.0.1 resolved the issue.

Regards,

Aastha Bhardwaj

Christopher Bell · ‎02-24-2016

Thanks Astha, I can confirm that. Thanks for all your help. The problem now is that our IP to username mapping seem to be broken as well. I've restarted the SFUA and that didn't help. I'm wondering if that needs to be upgraded as well?

If this posts answers your question or is helpful, please consider rating it and/or marking as answered.

Aastha Bhardwaj · ‎02-24-2016

Hi,

Most likely you are running into below mentioned bug :

https://tools.cisco.com/bugsearch/bug/CSCux39125/?reffering_site=dumpcr

Regards,

Aastha Bhardwaj

Rate if that helps!!!

Christopher Bell · ‎02-24-2016

That didn't help.

If this posts answers your question or is helpful, please consider rating it and/or marking as answered.

Dennis Perto · ‎03-09-2016

Does it relate to this?
https://popravak.wordpress.com/2015/11/23/fixing-error-fetching-groups-after-upgrade-sourcefire-to-6-0/

Christopher Bell · ‎03-09-2016

I had actually seen that particular article and that certainly was an issue, but not the issue. Thanks dennisperto. This ended up being a problem with the way the two of the default variable sets were configured after the upgrade. I'm assuming the upgrade process changed them somehow because I've never used custom variable sets.

If you go to Objects --> Object Management --> Variable Set and open the default set you will find EXTERNAL_NET and HOME_NET. These two variables were not correctly defined in my default-set.

If this posts answers your question or is helpful, please consider rating it and/or marking as answered.

deyster94 · ‎04-13-2016

I have a client pushing out 6.0.1 because of this vulnerability in 6.0:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160330-fp

I noticed the mentioned issue and will do the workaround. Glad I could find a fix for it quickly.

evan.chadwick1 · ‎05-02-2016

If i'm not mistaken one should be really careful when editing variable sets as it could completely remove snort from inspecting certain traffic if you put the wrong information into a variable. Updating your Home_NET to include internal addresses and possibly company owned public ips (?) is what I have seen as recommended.

Marvin Rhoads · ‎05-02-2016

Evan,

That's correct.

Most of the shared object rules and standard text rules that the FirePOWER system provides use predefined default variables to define networks and port numbers. For example, the majority of the rules use the variable $HOME_NET to specify the protected network and the variable $EXTERNAL_NET to specify the unprotected (or outside) network.

evan.chadwick1 · ‎05-02-2016

Thanks Marvin, Would you recommend company owned public ips to be put into HOME_NET?

Marvin Rhoads · ‎05-03-2016

Evan,

Re the company-owned public IPs it would be a case by case decision depending on where the IPS is architecturally. If they were "inside" the network (from the perspective of the IPS) then yes. If not, then no.

evan.chadwick1 · ‎05-04-2016

Thanks Marvin, gotcha