- Newest
- Most votes
- Most comments
Hello.
Have you set a route to communicate to the CIDR of subaccount 2 in the Fortinet EC2 routing settings?
Please configure the routing settings not only from the AWS route table but also from the Fortinet EC2 UI.
Also, disable "source/destination checks" in Fortinet EC2's ENI.
If you do not configure this setting, you will be configured to only receive packets whose source or destination is the EC2 IP.
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck
Hi Riku,
confirming the route table in Fortinet GUI is where i have updated. 10.0.0.0/24 on interface SSL-VPN, matching the same config as account 1. confirming this IP range is also in AWS VPC Route Table pointing to the peering connection.
whats interesting, and i am unsure of this config on how its exactly working. When i connect via client VPN, i am given the IP Rage of 10.212.134.200 - 10.212.134.240
however, there is no route config on account 1, or security group rules within this IP range that allows comms to account 1, so i am not entirely sure how the account 1 is reachable in the first place.
Account 1 ip range 192.168.0.0/24 account 2 IP Range 10.0.0.0/24
AWS Route table shows 192.168.0.0/24 to local and 10.0.0.0/24 to peering connection
EC2 security group on account 1 shows inbound 192.168.0.0/24 all ip/ports open inbound 10.0.0.0/24 all ip/ports open.
same config for sub account 2.
so no mention of the VPN IP range in AWS Route table or EC2 security groups, yet account 1 i have access, and can ping all EC2 instances in account 1.
Hi Riku,
the youtube video is pretty much exactly how i have it configured, and i can communicate fine to other resources within the same account. all of my EC2 are not part of NAT, the subnet routes to IGW.
as i am not using NAT in the VPC, do i still disable the source / destination check?
Nat is enabled in fortinet firewall rule.
Fortinet instance only has 1 ENI + elastic IP. Comms to VPC is working fine, so unsure why i need 2 ENI?
is there any method in AWS or Fortinet that might show where it is getting blocked?
just confirming, i think i first need to understand ip range 10.212.134.200 - 10.212.134.240 and how this is allowing me to communicate within the same account even though no routes / security groups mention this range?. Is it due to the NAT on the firewall, and is actually using the local IP of the Fortinet EC2 instance which is part of the route table and security groups.
i am looking into VPC Flow Logs at the moment to get this configured, hopefully this can assist.
yes route table is set in both accounts, as i can communicate ok from ec2 in account 1 to ec2 in account 2. it is only when i am connected to client VPN / fortinet GUI where i am unable to communicate to account 2.
Relevant content
- Accepted Answerasked a year ago
- asked 5 months ago
AWS OFFICIALUpdated 9 months ago- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 8 months ago
I believe this is the default CIDR distributed to Fortinet's SSL-VPN clients. https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-monitor-the-link-health-for-SSL-VPN/ta-p/263576
Therefore, I think it is probably necessary to configure NAT settings for the VPN user in order to communicate with the resources of subaccount 2. I think you can configure NAT settings in the firewall policy, so try setting the VPN user as the source and enabling NAT. Also, don't forget to configure the following documents. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck
I think the following YouTube video will help you with the settings. https://www.youtube.com/watch?v=St-sHcH9nUM
Just to be sure, are Fortinet EC2 configured with an ENI for SSL-VPN and an ENI for communicating within the VPC? To communicate within the VPC, you need to attach not only the SSL-VPN ENI but also the internal communication ENI to EC2.
I wouldn't know for sure unless I took a packet capture using something like "tcpdump", but I thought it was probably being NATed.
If EC2 is not set as a gateway router, I think it is okay to not disable it.
I think that in the YouTube video, two ENIs are set to EC2. Based on this, I decided that it was necessary. However, I thought it was unnecessary if communication was possible within the VPC.
You may be able to enable something like VPC Flow log to see where you are being blocked. https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-cwl.html#flow-logs-cwl-create-flow-log
Also, is the route to the CIDR of account 1 set in the VPC route table of subaccount 2? If this route is not set, I don't think communication will be able to return to account 1.
Just to be sure, do the EC2 security group settings for subaccount 2 allow connections from account 1?