R77.30 Take 205 - is it stable?

[eduardoxmunoz]

Hi everyone,

I have recently received a requirement to install the latest R77.30 Jumbo GA HFA Take_205 over several units, these firewalls have a mixture of different blades (fW, VPN, IA, App & URL Filt, etc.)

I have been reading few post with people reporting some issues with this take.

I wonder if anyone who has installed this take already can share any comments? how does it behaves? is it stable? Any important issue to highlight?

Any comment is welcome!

Thanks

Ed

[cciesec2006]

Hi everyone,

I have recently received a requirement to install the latest R77.30 Jumbo GA HFA Take_205 over several units, these firewalls have a mixture of different blades (fW, VPN, IA, App & URL Filt, etc.)

I have been reading few post with people reporting some issues with this take.

I wonder if anyone who has installed this take already can share any comments? how does it behaves? is it stable? Any important issue to highlight?

Any comment is welcome!

Thanks

Ed

I am in the same boat as you. I have to roll out about 8 gateways cluster R77.30 with JHFA 205 (it was supposed to be 14 clusters but we've decided to migrate the other 6 clusters to PaloAlto, thanks god). I still see there are lot caveats with JHFA 205 that just concerns me. According to Checkpoint, those issues are addressed in JHFA 210. These below concerns me with JHFA 205:

- Intermittent access to some web sites because in.ahttpd process constantly consumes CPU at 100%.
Refer to sk106916.

- "Error: bond_3ad_get_active_agg_info failed" in the output of "dmesg" command.
Refer to sk110344.

- Security Gateway with enabled SecureXL might crash during policy installation when SAM card is not installed.
Refer to sk114153.

- confd process consumes the CPU at almost 100% on Check Point appliance with installed LOM card.
Refer to sk115634.

- Security Gateway with enabled SecureXL might crash during policy installation.
Refer to sk111411.

- "fwd" process or "fw_full" process on Security Gateway consumes memory at high level and crashes with core dump file.
Refer to sk113736.

- Security Gateway might crash with kernel panic when connecting to some web sites.
Refer to sk113873.


the last one just scares me "might crash with kernel panic"

[eduardoxmunoz]

the last one just scares me "might crash with kernel panic"

Hi cciesec,

Thanks for pointing me to some known issues and the related SKs.

scaring indeed...

Regards

Ed

[cciesec2006]

Hi cciesec,

Thanks for pointing me to some known issues and the related SKs.

scaring indeed...

Regards

Ed

Sadly, I think there are issues with JHFA 213 as well. Checkpoint has pulled JHFA 210 from the website and replaced it with JHFA 213. They gave me the file yesterday and I installed it on my JHFA 205 gateways. After the installation and reboot, I see these messages during the boot up:

Fetching Threat Prevention policy failed
AntiMalware was not started
FireWall-1: enabling bridge forwarding
FireWall-1 started
basename: missing operand
Try `basename --help' for more information.
basename: missing operand
Try `basename --help' for more information.
basename: missing operand
Try `basename --help' for more information.

[JFerreira23]

I have had TAKE 205 Running in my non production environment for a week. Was about to roll this out globally until I saw this thread. You want to know what really, really grinds my gears at the moment?

I have just bought a 5200 Appliance, fresh out the box. We are currently running take 159, which as you know is a very stable take. I was unable to upgrade the "fresh" box to take 159. I was told there is an element, that prevented 159 from being installed on new 5200's that couldn't be uninstalled for take 159.

So I am essentially being forced to 205...... Reckon I could go to 185.

[jflemingeds]

Well, i hear what you're saying, but none of these fixes indicate which version the issue started in. My thinking is there is a good chance all those issues are in your 185 build as well. If you haven't seen them in 185 my guess is you're not going to see them in 205 either.

sk113873 is the only one i would be worried about as well, but really you could ask checkpoint for a 1 off fix for that on top of 205. Just explain that you've already certified (if you still have) 205 and go that way. A few of those issues listed my guess won't even apply to you.

Or start over with the latest which kind of stinks.

[cciesec2006]

Well, i hear what you're saying, but none of these fixes indicate which version the issue started in. My thinking is there is a good chance all those issues are in your 185 build as well. If you haven't seen them in 185 my guess is you're not going to see them in 205 either.

sk113873 is the only one i would be worried about as well, but really you could ask checkpoint for a 1 off fix for that on top of 205. Just explain that you've already certified (if you still have) 205 and go that way. A few of those issues listed my guess won't even apply to you.

Or start over with the latest which kind of stinks.

In my situation, I was able to re-produce sk111411 once.

Furthermore, in my environment, I am also using NIC bonding 802.3AD LACP Active/Active and that the Intel NIC driver on the Checkpoint appliance 13500 matches exactly which what described in sk110344:
09:00.0 Ethernet controller: Intel Corporation 82599EB 10 Gigabit Network Connection (rev 01)

I am one of those people that do not wait for problem to occur. I would like to be pro-active and prevent the problem from happening in the first place

[jflemingeds]

How did you recreate the securexl problem?

[cciesec2006]

How did you recreate the securexl problem?

Like I said, I was able to re-create the issue just once. I had to push the firewall rules to the gateways, has about 400 rules in the policy. I pushed it about 80 times. Each push took about 4 minutes. a real PITA. Out of that 80 times, one time, I saw "fwaccel stat", it went from ON to OFF.

[jflemingeds]

I hope you scripted that.

Did a dump file get created?

[jdmoore0883]

...I saw "fwaccel stat", it went from ON to OFF.

SecureXL get re-initialized on a policy install; if you can catch it quick enough, it would be expected to see it turn off then back on again.

[jflemingeds]

oh right, thanks for pointing that out.

[cciesec2006]

oh right, thanks for pointing that out.

No I did not script that and kept the dump file. I thought I didn't notice until I read the release notes.

In my case SecureXL was on prior to policy install. It was OFF after policy install. I waited for about 10 mins and nothing. Finally I gave up and simply ran "fwaccel on"

[jflemingeds]

did you turn over the dump file? the SK you brought up says its trigger is changing an interface config during policy push. Might not be that issue.

BTW fwm load is your friend.

[wayne0206]

Like I said, I was able to re-create the issue just once. I had to push the firewall rules to the gateways, has about 400 rules in the policy. I pushed it about 80 times. Each push took about 4 minutes. a real PITA. Out of that 80 times, one time, I saw "fwaccel stat", it went from ON to OFF.

YES. I have the same issue. upon research this was a bug should have fixed long ago sk100467.

[Nachtfalke]

Hi,

our goal was to install Jumbo HFA Take 205 on 50 Gateways but then we noticed many fwd coredumps in our complete environment (Take 162 installed) and we were advised to go to take 207 which should fix that.
Installed that on 7 Cluster and 3 Standalone machines, then we saw Take 209 was published and revoked, now 210.

Since we installed 207 on the above mentioned machines all bring errors like "fw_kmalloc" with every policy install.

It is so sad .... You think that Take 205 is GA and should be stable and not having so many new bugs and then they publish new Jumbo HFA and then they revoke it because of new bad code...
So at the moment I would not install any of those Takes - better wait some weeks if you are not interested in to install every three days a new JHFA.

[jdmoore0883]

You think that Take 205 is GA and should be stable and not having so many new bugs and then they publish new Jumbo HFA and then they revoke it because of new bad code...

Take 205 is indeed still the GA and suggested package, 205 has not been recalled.

Any and all reports that 205 has been recalled are false.

Please take a look at:
sk106162: Jumbo Hotfix Accumulator for R77.30 (R77_30_jumbo_hf)

[cciesec2006]

Take 205 is indeed still the GA and suggested package, 205 has not been recalled.

Any and all reports that 205 has been recalled are false.

Please take a look at:
sk106162: Jumbo Hotfix Accumulator for R77.30 (R77_30_jumbo_hf)

Here is checkpoint response: You should not be using 213 package because it is non GA. For your bonding issue, you should be using 210. So they gave me the 210 package.

Isn't package 210 "non" GA as well?

Well I installed package 210 on my gateways and I see this:

Fetching Security Policy from localhost succeeded
basename: missing operand
Try `basename --help' for more information.
basename: missing operand
Try `basename --help' for more information.
basename: missing operand
Try `basename --help' for more information.

Threat Prevention Security Policy wasn't loaded
Fetching Threat Prevention policy failed
AntiMalware was not started
FireWall-1: enabling bridge forwarding
FireWall-1 started
basename: missing operand
Try `basename --help' for more information.
basename: missing operand
Try `basename --help' for more information.
basename: missing operand
Try `basename --help' for more information.

cpstart: Starting product - FloodGate-1

FloodGate-1 is disabled. If you wish to start the service, please run 'etmstart enable'.

cpstart: Starting product - SmartView Monitor

gone back to Checkpoint TAC and they said that "we're going to try to reproduce it in the lab. If we can not re-produce the issue, the issue is with your configuration"

WTF!!!!

[wayne0206]

Hi,

Since we installed 207 on the above mentioned machines all bring errors like "fw_kmalloc" with every policy install.

I am getting this error from our 15600 cluster with take 205 too.

[wayne0206]

gone back to Checkpoint TAC and they said that "we're going to try to reproduce it in the lab. If we can not re-produce the issue, the issue is with your configuration"

WTF!!!!

I would be piss too

how is your palo alto experience so far?