Description
This article describes how to use the new FQDN VIP type inside the Amazon AWS infrastructure.
The AWS resiliency is implemented based on domain names. Most services are defined inside the cloud structure just by their domain name and their real IP can unpredictably change. In this case, a regular VIP type cannot be used as IP definition is not scalable in this setup. Regular design where FQDN VIPs should be deployed will look similar to the following diagram:
The AWS resiliency is implemented based on domain names. Most services are defined inside the cloud structure just by their domain name and their real IP can unpredictably change. In this case, a regular VIP type cannot be used as IP definition is not scalable in this setup. Regular design where FQDN VIPs should be deployed will look similar to the following diagram:
Scope
FortiOS-AWS, FortiOS v5.4 and later.
Solution
The new FQDN VIP type was added to address this issue. Under the VIP configuration, an external public IP is defined but as a mapped IP, the DNS name of the AWS ELB is defined.
Example configuration in the CLI:
Example configuration in the CLI:
- Define new FQDN object under the firewall object table.
config firewall address
edit "customer24.elb.aws"
set type fqdn
set fqdn "customer24.elb.aws"
next
edit "customer24.elb.aws"
set type fqdn
set fqdn "customer24.elb.aws"
next
- Configure VIP as a mapped address where the FQDN object is used.
config firewall vip
edit "ELBAWS_vip"
set type fqdn
set extip 1.1.1.2
set extintf "port7"
set mapped-addr "customer24.elb.aws"
next
end
edit "ELBAWS_vip"
set type fqdn
set extip 1.1.1.2
set extintf "port7"
set mapped-addr "customer24.elb.aws"
next
end
Note regarding FQDNs that resolve to multiple IP addresses:
When using an FQDN that resolves to multiple IP addresses, the VIP will perform some basic load-balancing. More specifically, the load-balancing is handled by calculating the modulo of the client's Source IP and the number of IP addresses that the FQDN resolves to. Consider the following scenario:
- Client Source IP is 192.168.1.99
- VIP External IP is 192.168.1.200
- VIP Mapped FQDN is community.fortinet.com, which resolves to the following IP addresses.
- 52.84.162.7
- 52.84.162.26
- 52.84.162.65
- 52.84.162.79
When 192.168.1.99 sends traffic to the VIP external address of 192.168.1.200, the FortiGate must choose one of the four destination IP addresses that should be used. To determine which entry is chosen, use the following procedure:
- Remove the decimal points in the Source IP address to produce a number (i.e. 192.168.1.99 becomes 192168199)
- Count the number of IP addresses that the FQDN resolves to, then assign each entry a number starting from 0:
- FQDN community.fortinet.com has 4 entries in total. Hover over the Address Object on the FortiGate to determine the order that the FortiGate will use:
- 52.84.162.7 <- ID 0
- 52.84.162.26 <- ID 1
- 52.84.162.65 <- ID 2
- 52.84.162.79 <- ID 3
- Calculate the modulus of the Source IP by the number of resolved IP entries. The result will determine which Destination IP address the FortiGate will send the traffic to.
- For example: calculate 192168199 mod 4, which equals to 3.
- Entry #3 is 52.84.162.79, so traffic sourced from 192.168.1.99 going to the external VIP address of 192.168.1.200 will always be translated to 52.84.162.79 (for this FQDN address object).
It's also important to note that VIPs do not have health-check capabilities, and that the traffic from a given Source IP always goes be translated to the same destination address, regardless of the traffic protocol/port (i.e. if 52.84.162.79 is not responding then 192.168.1.200 will not be able to reach community.fortinet.com, even if other clients can).
Related document:
