Background:
The developers of a web application are unable to access one of the web servers in a spoke VPC! The last engineer somehow deleted all the network diagrams of the production environment…
Your Task:
The goal of this task is to fix the routing issues and confirm that you can successfully ping both web servers from the jumpbox.
Getting Started:
Using the outputs from the CloudFormation template, SSH into JumpBox1 and validate connectivity to both WebSrv1 and WebSrv2 with ICMP. One of these instances is not reachable
Login to the EC2 console to get the private IP addresses of WebSrv1 and WebSrv2. (Note that any other protocols outside of ICMP are not going to work at the moment).
On a side note, when you SSH into JumpBox1, you are actually using portfowarding (on external TCP port 221) through the FGT’s Elastic IP so the traffic flows through the FortiGate instance and FortiOS policy for authorization and routing to JumpBox1. You should make sure you are off corporate VPN or any environment that would block you from connecting to the demo environment over TCP port 221.
Optionally you can use the outputs from the CloudFormation template to SSH directly into the FortiGate itself (on external TCP port 22) and use FortiOS commands like below to run packet captures and check the running routing table while you generate ICMP traffic from JumpBox1.
Alternatively if you prefer to use a GUI based SSH client, once you are logged into the FortiGate you can click on the >_ icon in the upper right hand corner of your screen and run the commands.
diag sniffer packet any ‘icmp’ 4 0 l
get router info routing-table all
Hint: You can leave the sniffer running while testing traffic to help solve the task.
For additional examples of how to use the built-in packet sniffer in FortiOS, reference the KB article here kb.fortinet.com.
Inventory:
You do know that the current environment is leveraging AWS VPC Transit Gateway to setup a security VPC and two spoke VPCs. These VPCs provide a hub and spoke design for centralized traffic inspection. The security VPC is the hub for all network traffic. All ingress, egress, and east-west traffic will flow through the FortiGate NGFW deployed in the security VPC. The spoke VPCs contain a webserver each and have their default route set to direct all traffic to the TGW attachments.
Services in Use:
AWS VPC Transit Gateway route tables, and FortiGate FortiOS routing.
Task Validation:
once this task is completed successfully, the answer for this task will be provided by a lambda function that writes the answer into the file ‘task1-answer.txt’ in the S3 bucket indicated in the CloudFormation outputs. Download this file to get the answer for this task.
Miscellaneous:
On a side note, if you see this message below when using the SSH private key, you will need to change the permissions with ‘chmod 400 ~/keypair.pem’.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
To fix the TGW routing issue, follow these steps:
Your AWS VPC Transit Gateway is missing a propagation setting, the following steps correct this misconfiguration.
Open the VPC console by navigating to the VPC service in the AWS Management Console.
Click on Transit Gateway Route Tables and select the TGWSecurityRouteTable.
Select the propagation tab and click create propagation.
On the create propagation screen, select the VPC attachment for spoke2 VPC and select create.
Select the routes tab and validate that you see the VPC CIDR for spoke2 now.
To fix the FortiGate routing issue, follow these steps:
Your FortiGate is missing a static route for reaching the second spoke VPC, the following steps correct this misconfiguration.
Using the FortiGateLoginURL, Username, and FgtInitialPassword outputs from the CloudFormation template, login to the FGT GUI.
You will be prompted to change the initial password. Make sure to save your new password somewhere secure.
After logging back in with your new password, on the menu on the left, navigate to Network then Static Routes.
Click the Create New button and use 10.2.0.0/16 as the destination, port2 as the interface, and 10.0.2.1 as the gateway address, finally click OK to apply your changes. The gateway address used is the AWS intrinsic router which is the first host IP in an AWS subnet.
Finally on the menu on the left, navigate to Monitor then Routing Monitor. Validate that the route for 10.2.0.0/16 is now in the running route table.
Task Validation:
once this task has been completed successfully, the answer for this task will be provided by a lambda function creating the file ‘task1-answer.txt’ in the S3 bucket (this is in the CF template outputs as well). Download this file to get the answer for this task. Step by step directions to get the file are below.
Open the S3 console by navigating to the S3 service in the AWS Management console.
Using the S3Bucket output from the CloudFormation template, find the bucket with the same name.
Select the file ‘task1-answer.txt’ and download this to your machine.
Open the file with a text editor to see the answer you should provide for this task.
