- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Re: CheckPoint Cluster R80.10 in AWS - Standby FW ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CheckPoint Cluster R80.10 in AWS - Standby FW unable to reach Metadata169.254.169.254 or Internet
Dear Team,
I have run into below situation and need suggestions.
CheckPoint R80.10 Cloudguard Cluster HA running inAWS.
Active member is fine and able to reach Internet, Metadata(169.254.169.254), also "$FWDIR/scripts/aws_ha_test.py" successful.
Standby member unable to reach the above. No internet reachable or Metadata info.
When running the above script -
---------------------------------------------------------------
[Expert@gw-0d0656:0]# $FWDIR/scripts/aws_ha_test.py
Testing if DNS is configured...
Primary DNS server is: 172.16.0.2
Testing if DNS is working...
DNS resolving test was successful
Testing metadata connectivity...
Traceback (most recent call last):
File "/opt/CPsuite-R80/fw1/scripts/aws_ha_test.py", line 149, in test
region = get(META_DATA + 'placement/availability-zone')[:-1]
File "/opt/CPsuite-R80/fw1/scripts/aws_ha_test.py", line 62, in get
text = subprocess.check_output(cmd)
File "/etc/fw/Python/lib/python2.7/subprocess.py", line 219, in check_output
raise CalledProcessError(retcode, cmd, output=output)
CalledProcessError: Command '['curl_cli', '-s', '-f', '-g', '-L', 'http://169.25 4.169.254/2014-02-25/meta-data/placement/availability-zone']' returned non-zero exit status 7
Error: Failed in metadata connectivity test
Verify that outgoing connections over TCP port 80 (HTTP) to 169.254.169.254 are allowed by the firewall security policy.
---------------------------------------------------------------
Per Firewall Logs, getting Accept and "fw monitor" shows o,O which is fine and no drop in zdebug on Active/Standby command.
Due to this when Standbymember comes as Active - All production stops due to No internet from this member.
I have "exact" similiar setup in other Region with same JHF Latest(Take272) which both members test for .py script passed and all fine for both members getting Internet and able to reach/get Metadata info.
Any idea?
Regards, Prabu
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Prabulingam_N1,
In most cases it is a NAT problem. If you are using "automatic hide NAT behind the gateway", NAT will be performed on the secondary IP (representing the VIP). If you now perform an access from the standby gateway to the internet, the return packet is sent to the active gateway. So you will not see a packet at the "i" fw monitor inspection point.
Add a manual hide NAT rule for the external IP of the standby gateway and test it again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Prabulingam_N1,
In most cases it is a NAT problem. If you are using "automatic hide NAT behind the gateway", NAT will be performed on the secondary IP (representing the VIP). If you now perform an access from the standby gateway to the internet, the return packet is sent to the active gateway. So you will not see a packet at the "i" fw monitor inspection point.
Add a manual hide NAT rule for the external IP of the standby gateway and test it again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Heiko,
Yes, just compared working location Cluster and Non working location Cluster.
Seems the Public facing Subnet was given HideNAT which is not needed.
Removed the Hide NAT on Public facing Subnet and now both Active/Standby member able to each Internet and able to reach Metadata.
Thanks for quick suggestion and it did worked.
Regards, Prabu
![](/skins/images/4BAE0211AB62E3B2F85E95CA468FEED0/responsive_peak/images/icon_anonymous_message.png)