topic Unexpected new behavior of the AWS vSEC in Cloud Firewall

Unexpected new behavior of the AWS vSEC

Vladimir — Thu, 19 Oct 2017 21:41:18 GMT

I'm not sure if anyone have seen this, but building AWS vSEC cluster today, I am seeing this:

Nope, it was not defined manually.

Additionally, when failing over from active to standby members, secondary IPs are no longer moving to the new active member:

5 minutes later:

It may be a coincident, but the Check Point SE working on one of my previous cases (Inconsistent behavior of vSEC in AWS ) was able to repeatedly reproduce the issue last week. but can no longer do so today.

If someone can get an update from CP about any changes that may have transpired in the past week, please let me know.

Thank you,

Vladimir

Re: Unexpected new behavior of the AWS vSEC

Vladimir — Thu, 26 Oct 2017 14:32:20 GMT

For those looking at this thread:

The issue was replicated by TAC and forwarded to R&D.

Service Request # 1-9861861391

I'll update the thread when I'll get anything from them.

Re: Unexpected new behavior of the AWS vSEC

Vladimir — Fri, 27 Oct 2017 00:50:16 GMT

Confirmed bug in the current release of the vSEC AMI (ogu-13-233.raw).

From Check Point:

We have found the issue with the failover within WAS for version ogu-13-233.raw.

[Expert@gw-addef0:0]# cat /etc/in-aws

ogu-13-233.raw

The fix is to vi the files listed below and add the "shell=True" to lines 373 and 376 on the aws_had.py file and lines 40 and 43 on the aws_ha_test.py file

To get the line numbers, after you run the vi <file_name> and are in vi, enter the : and set number <enter> and the lines numbers will show.

$FWDIR/scripts/aws_had.py

371 if proxy_address != '' and proxy_port.isdigit():

372 conf['proxy'] = proxy_address + ':' + proxy_port

373 subprocess.call('fw ctl set int fw_os_proxy_port ' + proxy_port, shell=True)

374 else:

375 conf['proxy'] = None

376 subprocess.call('fw ctl set int fw_os_proxy_port 0', shell=True)

$FWDIR/scripts/aws_ha_test.py

38 if proxy_address != '' and proxy_port.isdigit():

39 HTTP_PROXY = proxy_address + ':' + proxy_port

40 subprocess.call('fw ctl set int fw_os_proxy_port ' + proxy_port, shell=True)

41 else:

42 HTTP_PROXY = None

43 subprocess.call('fw ctl set int fw_os_proxy_port 0', shell=True)

Please let me know if you have any questions.

I beleive R&D will provide a new image to AWS, but in the meantime, this is the workaround for this image and we will publish an SK.

After modifying the files, you will need to run the following command to reconfigure the files:

Expert@HostName]# $FWDIR/Python/bin/python $FWDIR/scripts/aws_ha_cli.py reconf

Reboot vSEC for changes to take effect.

Re: Unexpected new behavior of the AWS vSEC

Vladimir — Thu, 02 Nov 2017 20:07:00 GMT

Check Point pulled the problematic AMI and had it replaced.

From Check Point:

We have removed that image from AWS (take-013.233).

There was a new image released on Oct. 31 - take-013.240.

-------------------------------------------

Re: Unexpected new behavior of the AWS vSEC

Joe_DeMichele — Thu, 04 Jan 2018 19:13:04 GMT

More issues with AMI take-013.233. The recent sk121885 addresses the vSEC controller but does not fix the aws_had.py script on the gateway. If you enable debugging for this process you will see failover cannot work due to CURL cert validation failures. My workaround was to add -k to line 53.

cmd = ['curl_cli', '-s', '-f', '-g', '-k', '-L']

Hope this helps.