fortinetsolutions / aws-cloudformationtemplates

AWS Cloud Formation Templates for Fortinet Solutions

AWS - Cloud Formation Templates

Cloud Formation Templates for getting you started in AWS with Fortinet.

https://www.fortinet.com/aws/

Support

Please contact your Fortinet representation for any comments, questions, considerations, and/or concerns.

License

Copyright © 2017 Fortinet, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS OR FORTINET SUPPORT (TAC) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

aws-cloudformationtemplates's Issues

Terraform autosale file not found

Hello,

I'm trying to test the terraform script to install fortigate in autoscaling process, however, i'm getting a no such file for tpl files : fortigate-userdata.tpl and endpoint-userdata.tpl.

Thanks for your help.

Default routes are not updated after initial FortiGate deployment

When deploying FortiGate VMs to an existing VPC in an Auto Scale configuration, worker node cannot find the routing table FortiGate subnet/interface is associated to and doesn't update the default route to the FortiGate ENI.

Reason of the issue is the RouteTableCheck function in Fortigate.py, which expects the default route to be pointing to an IGW:

if igwbool is True

There are lots of scenarios where this might not be true: default route is pointing to a NAT Gateway, default route is empty (private subnet talks only to subnets propagated from a VPG), etc. As a result, deployment might or might not succeed, depending on how existing VPC routing tables are configured.

The easiest way to fix this is probably to remove this check and change default route to FortiGate VM ENI regardless of how routing tables are configured.

instance type not supported

Hi,
The CF templates allow for c4.* instances to be chosen as a parameter. Attempting to create the stack using a c4.* instance type fails with an error that the instance type isn't supported by the AMI.

Likewise, t2.small is not an available option in the templates even though the AWS Marketplace for FortiGate shows that t2.small is supported.

Unable to Access Firewall

Hi,

I have run the scripts, seems all the setting like routing, internet gateway, and Security Group looks fine. But still, I am not able to access the Firewall.

I Have checked the standard configuration which is required to access the Firewall. But still, I am not able to access the firewall.
AWs_Cloudformation_Issue.docx

Best
Karan Sarvaiya

Question: Transit VPC Updating AMI?

Would updating the transit-vpc primary account template to use the newest version in the marketplace? (4.5.5)cause any issues with the lambda main or worker lambda functions?

Null reference in VerifyRouteAssociation

VerifyRouteAssociation function from the worker node's Fortigate.py script fails with the following error:

caught: SubnetId with VerifyRouteAssociation()

The reason for the error is an implicit empty route table association in every main VPC route table. Here is an example from "aws ec2 describe-route-tables":
...

            "Associations": [
                {
                    "RouteTableAssociationId": "rtbassoc-3533bb53", 
                    "Main": true, 
                    "RouteTableId": "rtb-97009ff0"
                }, 
                {
                    "SubnetId": "subnet-4c56e52b", 
                    "RouteTableAssociationId": "rtbassoc-918b01f7", 
                    "Main": false, 
                    "RouteTableId": "rtb-97009ff0"
                }
            ],

...

Implicit route rtbassoc-3533bb53 will have no subnet associated with it, which will lead to null reference in the following line:

subnet_association = r['Associations'][0]['SubnetId']

This is an example of the dictionary "r" in this case, where the first record does not have a "SubnetId":

{u'RouteTableAssociationId': 'rtbassoc-3533bb53', u'Main': True, u'RouteTableId': 'rtb-97009ff0'},
{u'SubnetId': 'subnet-4c56e52b',u'RouteTableAssociationId': 'rtbassoc-918b01f7', u'Main': False, u'RouteTableId': 'rtb-97009ff0'}

This issue occurs only when customer deploys FortiGate in an existing VPC and uses the main route table (which is not best practice). Non-main route tables do not have an implicit empty route table association.

Corresponding template that deploys the solution (including worker node):

ExistingVPC_Fortigate542_Autoscale_ELB_WorkerNode.template

getting error from another account spoke vpc

An error occurred (403) when calling the HeadObject operation: Forbidden: ClientError
Traceback (most recent call last):
File "/var/task/spokevgw_function.py", line 31, in spokevgw_handler
s3.Object(TransitS3Bucket, 'transitvpc.txt').load()
File "/var/task/boto3/resources/factory.py", line 505, in do_action
response = action(self, *args, **kwargs)
File "/var/task/boto3/resources/action.py", line 83, in call
response = getattr(parent.meta.client, operation_name)(**params)
File "/var/task/botocore/client.py", line 253, in _api_call
return self._make_api_call(operation_name, kwargs)
File "/var/task/botocore/client.py", line 544, in _make_api_call
raise error_class(parsed_response, operation_name)
ClientError: An error occurred (403) when calling the HeadObject operation: Forbidden

Code version

I've been helping a client to set this up in there production AWS environment. We attempted to update the firewall to the latest 5.6.6 and also to 6.0.3. Both times resulted in the firewall winding up in a state of rebooting itself over and over again. We also attempted to rollback by restoring an AWS snap shot and the firewalls again would just reboot repeatedly.

Has anyone ran into any behavior like that? We've ran into this multiple times and have installed from scratch to fix it.