- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Re: WaitCondition timed out. Received 0 conditions...
- 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
WaitCondition timed out. Received 0 conditions when expecting 1
Didn't see much on this in the support portal. This occurs 45-60 minutes after I kick off a cloudformation template for r80.10 management into a pre-existing VPC. Template #6 from sk111013 (top section -- first #6). Any recommendations on next steps?
Physical ID:arn:aws:cloudformation:us-east-1:709709569732:stack/Check-Point-Management/cefceab0-b9aa-11e7-b989-50a686e4bbe3/ReadyHandle | |||||
Client Request Token:Console-CreateStack-262cdf0a-5109-4f76-ba24-39e5272c7a4a |
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you look in the template, there is a wait condition of 3600 seconds, waiting for the instance to come up. In the boot script of the instance, there is a curl command that is supposed to trigger the wait condition to be released. There is no internet connected to any of these subnets yet as this is a highly secured environment. We will be connecting to the management and the gateways via an on-prem VPN and during the cut window we will allow access which will be ultimately guarded by the Check Point. Until that time however, no Internet access is available. Is Internet access a mandatory requirement? My guess is that since there is no Internet this wait thing requires public internet access. Is my only option allowing Internet access to this box?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The wait condition appears to be the act of allocating a Public IP address:
"ReadyCondition": {
"Type": "AWS::CloudFormation::WaitCondition",
"Condition": "AllocatePublicAddress",
"DependsOn": [
"Instance"
],
"Properties": {
"Handle": {
"Ref": "ReadyHandle"
},
"Timeout": "3600"
}
},
My guess is that you will need to modify the template so that it doesn't do this.
Also, choose a different wait condition
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just to let you know I removed the wait condition and the device provisioned as expected. Not sure what was going on with that particular AWS cloud or the template, but simply removing the wait allowed it to provision properly... Odd...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the issue is usually with internet connectivity or DNS resolve.
check it on the Gateways after deployment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Stack roll backs and deletes all the GWs or Management Server due to this WaitCondition
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you please share how did you delete the wait condition ..did you remove the entire "Type" or just deleted "Condition" ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi LostBoY,
Don't know if this is still relevant for you, but to answer your questions:
1. How to edit the template-
You can find the method to manually load a template in our GitHub page. you will need to edit the relevant .yaml file.
CloudGuardIaaS/aws/templates at master · CheckPointSW/CloudGuardIaaS · GitHub
2. The section you need to delete from the yaml file to bypass the wait condition:
ManagementReadyCondition:
Type: AWS::CloudFormation::WaitCondition
Condition: EIP
DependsOn: ManagementInstance
Properties:
Handle: !Ref ManagementReadyHandle
Timeout: 1800