Dynamic DNS configuration
This section describes how to configure a site-to-site VPN, in which one FortiGate unit has a static IP address and the other FortiGate unit has a domain name and a dynamic IP address.
- The following topics are included in this section: Dynamic DNS over VPN concepts
- Dynamic DNS topology
- General configuration steps
- Configure the dynamically-addressed VPN peer
- Configure the fixed-address VPN peer
- Testing
Dynamic DNS over VPN concepts
A typical computer has a static IP address and one or more DNS servers to resolve fully qualified domain names (FQDN) into IP addresses. A domain name assigned to this computer is resolved by any DNS server having an entry for the domain name and its static IP address. The IP address never changes or changes only rarely so the DNS server can reliably say it has the correct address for that domain all the time.
Dynamic DNS (DDNS)
It is different when a computer has a dynamic IP address, such as an IP address assigned dynamically by a DHCP server, and a domain name. Computers that want to contact this computer do not know what its current IP address is. To solve this problem there are dynamic DNS servers. These are public servers that store a DNS entry for your computer that includes its current IP address and associated domain name. These entries are kept up to date by your computer sending its current IP address to the dynamic DNS (DDNS) server to ensure its entry is always up to date. When other computers want to contact your domain, their DNS gets your IP address from your DDNS server. To use DDNS servers, you must subscribe to them and usually pay for their services.
When configuring DDNS on your FortiGate unit, go to Network > DNS and enable Enable FortiGuard DDNS. Then select the interface with the dynamic connection, which DDNS server you have an account with, your domain name, and account information. If your DDNS server is not on the list, there is a generic option where you can provide your DDNS server information.
Routing
When an interface has some form of changing IP address (DDNS, PPPoE, or DHCP assigned address), routing needs special attention. The standard static route cannot handle the changing IP address. The solution is to use the dynamic-gateway command in the CLI. Say for example you already have four static routes, and you have a PPPoE connection over the wan2 interface and you want to use that as your default route.
The route is configured on the dynamic address VPN peer trying to access the static address FortiGate unit.
To configure dynamic gateway routing – CLI
config router static edit 5
set dst 0.0.0.0 0.0.0.0
set dynamic-gateway enable set device wan2
next end
For more information on DDNS, see the System Administration handbook chapter.
Dynamic DNS over VPN
IPsec VPN expects an IP address for each end of the VPN tunnel. All configuration and communication with that tunnel depends on the IP addresses as reference points. However, when the interface the tunnel is on has DDNS enabled there is no set IP address. The remote end of the VPN tunnel now needs another way to reference your end of the VPN tunnel. This is accomplished using Local ID.
A FortiGate unit that has a domain name and a dynamic IP address can initiate VPN connections anytime. The remote peer can reply to the local FortiGate unit using the source IP address that was sent in the packet header because it is current. Without doing a DNS lookup first, the remote peer runs the risk of the dynamic IP changing before it attempts to connect. To avoid this, the remote peer must perform a DNS lookup for the domain name of to be sure of the dynamic IP address before initiating the connection.
Remote Gateway
When configuring the Phase 1 entry for a VPN tunnel, the Remote Gateway determines the addressing method the remote end of the tunnel uses as one of Static IP Address, Dialup User, or Dynamic DNS. There are different fields for each option.
When you select the Dynamic DNS VPN type there is a related field called Dynamic DNS. The Dynamic DNS field is asking for the FQDN of the remote end of the tunnel. It uses this information to look up the IP address of the remote end of the tunnel through the DDNS server associated with that domain name.
Local ID (peer ID)
The Local ID or peer ID can be used to uniquely identify one end of a VPN tunnel. This enables a more secure connection. Also if you have multiple VPN tunnels negotiating, this ensures the proper remote and local ends connect. When you configure it on your end, it is your Local ID. When the remote end connects to you, they see it as your peer ID.
If you are debugging a VPN connection, the Local ID is part of the VPN negotiations. You can use it to help troubleshoot connection problems.
To configure your Local ID
1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Select Advanced.
4. In the Phase 1 Proposal section, enter your Local ID.
5. Select OK.
The default configuration is to accept all local IDs (peer IDs). If you have the Local ID set, the remote end of the tunnel must be configured to accept your Local ID.
To accept a specific Peer ID
1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Select Aggressive mode.
4. For Peer Options, select This peer ID. This option becomes visible only when Aggressive mode is selected.
5. Enter the string the other end of the tunnel used for its Local ID.
6. Configure the rest of the Phase 1 entry as required.
7. Select OK.
Route–based or policy-based VPN
VPN over dynamic DNS can be configured with either route-based or policy-based VPN settings. Both are valid, but have differences in configuration. Choose the best method based on your requirements. For more information on route-based and policy-based, see IPsec VPN overview on page 1606.
Route-based VPN configuration requires two security policies to be configured (one for each direction of traffic) to permit traffic over the VPN virtual interface, and you must also add a static route entry for that VPN interface or the VPN traffic will not reach its destination. See Dynamic DNS over VPN concepts on page 1688 and Dynamic DNS over VPN concepts on page 1688.
Policy-based VPN configuration uses more complex and often more IPsec security policies, but does not require a static route entry. It has the benefit of being able to configure multiple policies for handling multiple protocols in different ways, such as more scanning of less secure protocols or guaranteeing a minimum bandwidth for protocols such as VoIP. See Dynamic DNS over VPN concepts on page 1688 and Dynamic DNS over VPN concepts on page 1688.
Dynamic DNS topology
In this scenario, two branch offices each have a FortiGate unit and are connected in a gateway-to-gateway VPN configuration. One FortiGate unit has a domain name (example.com) with a dynamic IP address. See branch_2 in the figure below.
Whenever the branch_2 unit connects to the Internet (and possibly also at predefined intervals set by the ISP), the ISP may assign a different IP address to the FortiGate unit. The unit has its domain name registered with a dynamic DNS service. The branch_2 unit checks in with the DDNS server on a regular basis, and that server provides the DNS information for the domain name, updating the IP address from time to time. Remote peers have to locate the branch_2 FortiGate unit through a DNS lookup each time to ensure the address they get is current and correct.
Example dynamic DNS configuration
When a remote peer (such as the branch_1 FortiGate unit above) initiates a connection to example.com, the local DNS server looks up and returns the IP address that matches the domain name example.com. The remote peer uses the retrieved IP address to establish a VPN connection with the branch_2 FortiGate unit.
Assumptions
- You have administrator access to both FortiGate units.
- Both FortiGate units have interfaces named wan1 and internal. (If not, you can use the alias feature to assign these labels as “nicknames” to other interfaces to follow this example.)
- Both FortiGate units have the most recent firmware installed, have been configured for their networks, and are currently passing normal network traffic.
- The branch_2 FortiGate unit has its wan1 interface defined as a dynamic DNS interface with the domain name of example.com.
- A basic gateway-to-gateway configuration is in place (see Gateway-to-gateway configurations on page 1655) except one of the FortiGate units has a static domain name and a dynamic IP address instead of a static IP address.
- The FortiGate unit with the domain name is subscribed to one of the supported dynamic DNS services. Contact one of the services to set up an account. For more information and instructions about how to configure the FortiGate unit to push its dynamic IP address to a dynamic DNS server, see the System Administration handbook chapter.
General configuration steps
When a FortiGate unit receives a connection request from a remote VPN peer, it uses IPsec Phase 1 parameters to establish a secure connection and authenticate the VPN peer. Then, if the security policy permits the connection, the FortiGate unit establishes the tunnel using IPsec Phase 2 parameters and applies the security policy. Key management, authentication, and security services are negotiated dynamically through the IKE protocol.
To support these functions, the following general configuration steps must be performed:
- Configure the branch_2 FortiGate unit with the dynamic IP address. This unit uses a Local ID string instead of an IP address to identify itself to the remote peer. See General configuration steps below.
- General configuration steps
- General configuration steps
- Configure the fixed-address VPN peer. To initiate a VPN tunnel with the dynamically-addressed peer, this unit must first retrieve the IP address for the domain from the dynamic DNS service. See General configuration steps on page 1691.
- General configuration steps
- General configuration steps
Configure the dynamically-addressed VPN peer
It is assumed that this FortiGate unit (branch_2) has already had its public facing interface, for example the wan1, configured with the proper dynamic DNS configuration.
Configure branch_2, the dynamic address side
Configuring the dynamically-addressed VPN peer includes:
- Configuring branch_2 VPN tunnel settings
- Configuring branch_2 security policies
Configuring branch_2 VPN tunnel settings
Define the Phase 1 parameters needed to establish a secure connection with the remote peer. See Phase 1 parameters on page 1624. During this procedure you need to choose if you will be using route-based or policy- based VPNs.
To configure branch_2 VPN tunnel settings
1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Enter the following information:
Name Enter branch_2, a name to identify the VPN tunnel. This name appears in Phase 2 configurations, security policies, and the VPN monitor.
Remote Gateway Select Static IP Address.
The remote peer this FortiGate is connecting to has a static IP public address.
If the remote interface is PPPoE do not select Retrieve default gateway from server.
IP Address Enter 172.16.20.1. The IP address of the public interface to the remote peer.
Enter 172.16.20.1
The IP address of the public interface to the remote peer.
Select Aggressive.
4. Select Advanced and complete the following:
Local ID Enter example.com.
A character string used by the branch_2 FortiGate unit to identify itself to the remote peer.
This value must be identical to the value in the This peer ID field of the Phase 1 remote gateway configuration on the branch_1 remote peer. See Configure the dynamically- addressed VPN peer on page 1692.
5. Open the Phase 2 Selectors panel.
Define the Phase 2 parameters needed to create a VPN tunnel with the remote peer. For details on Phase 2, see
Phase 2 parameters on page 1642.
6. Enter the following information and select OK.
Name Enter branch_2_phase2.
A name to identify this Phase 2 configuration.
Phase 1 Select branch_2.
The name of the Phase 1 configuration that you defined earlier.
Configuring branch_2 security policies
Define security policies to permit communications between the private networks through the VPN tunnel. Route- based and policy-based VPNs require different security policies. For detailed information about creating security policies, see Defining VPN security policies on page 1648.
After defining the two address ranges, select one of Creating branch_2 route-based security policies on page 1694 or Creating branch_2 policy-based security policies on page 1696 to configure the appropriate VPN policies.
Define address ranges for branch_2 security policies
Define VPN connection names for the address ranges of the private networks. These addresses are used in the security policies that permit communication between the networks. For more information, see Defining VPN security policies on page 1648.
Define an address name for the IP address and netmask of the private network behind the local FortiGate unit.
To define branch_2 address ranges
1. Go to Policy & Objects > Addresses.
2. Select Create New.
3. Enter the following information, and select OK.
Name Enter branch_2_internal. Enter a meaningful name.
Type Select Subnet.
Subnet / IP Range Enter 10.10.10.0/24.
Include the netmask or specify a specific range.
Interface Select internal. The interface that will be handling the traffic from the internal network.
Define an address name for the IP address and netmask of the private network behind the remote peer.
4. Select Create New.
5. Enter the following information, and select OK.
Name Enter branch_1_internal. A meaningful name for the private network at the remote end of the VPN tunnel.
Type Select Subnet.
Subnet / IP Range Enter 192.168.1.0/24.
Include the netmask. Optionally you can specify a range
Interface Select any.
The interface that will be handling the remote VPN traffic on this FortiGate unit. If you are unsure, or multiple interfaces may be handling this traffic use any.
Creating branch_2 route-based security policies
Define ACCEPT security policies to permit communication between the branch_2 and branch_1 private networks. Once the route-based policy is configured a routing entry must be configured to route traffic over the VPN interface.
Define a policy to permit the branch_2 local FortiGate unit to initiate a VPN session with the branch_1 VPN peer.
To create route-based security policies
1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter the following information, and select OK.
Incoming Interface Select internal.
The interface that connects to the private network behind this FortiGate unit.
Source Address Select branch_2_internal.
Select the address name for the private network behind this FortiGate unit.
Outgoing Interface Select branch_2. The VPN Tunnel (IPsec Interface).
Destination Address Select branch_1_internal.
The address name the private network behind the remote peer.
Action Select ACCEPT.
Enable NAT Disable.
Comments Route-based: Initiate a branch_2 to branch_1 VPN tunnel.
Define a policy to permit the branch_1 remote VPN peer to initiate VPN sessions.
4. Select Create New.
5. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
6. Enter the following information, and select OK.
Incoming Interface Select branch_2. The VPN Tunnel (IPsec Interface).
Source Address Select branch_1_internal. The address name for the private network behind the remote peer.
Outgoing Interface Select internal. The interface connecting the private network behind this FortiGate unit.
Destination Address Select branch_2_internal. The address name for the private network behind this FortiGate unit.
Action Select ACCEPT.
Enable NAT Disable.
Comments Route-based: Initiate a branch_1 to branch_2 internal VPN tunnel.
7. Optionally configure any other security policy settings you require such as UTM or traffic shaping for this policy.
8. Place these policies in the policy list above any other policies having similar source and destination addresses.
This will ensure VPN traffic is matched against the VPN policies before any other policies.
To create routing entry for VPN interface – CLI
config router static edit 5
set dst 0.0.0.0 0.0.0.0
set dynamic-dateway enable set device wan1
next end
This routing entry must be added in the CLI because the dynamic-gateway option is not available in the web- based manager.
Creating branch_2 policy-based security policies
Define an IPsec policy to permit VPN sessions between the private networks. Define an IPsec policy to permit the VPN sessions between the local branch_2 unit and the remote branch_1 unit.
1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information, and select OK.
Incoming Interface Select internal. The interface connecting the private network behind this FortiGate unit.
Source Address Select branch_2_internal. The address name for the private network behind this local FortiGate unit.
Outgoing Interface Select wan1. The FortiGate unit’s public interface.
Destination Address Select branch_1_internal. The address name for the private network behind branch_1, the remote peer.
VPN Tunnel Select Use Existing and select branch_2 from the drop-down list. The name of the Phase 1 tunnel.
Select Allow traffic to be initiated from the remote site.
Comments Policy-based: allows traffic in either direction to initiate the VPN tunnel.
3. Optionally configure any other security policy settings you require such as UTM or traffic shaping for this policy.
4. Place these policies in the policy list above any other policies having similar source and destination addresses.
This will ensure VPN traffic is matched against the VPN policies before any other policies.
Configure the fixed-address VPN peer
The fixed-address VPN peer, branch_1, needs to retrieve the IP address from the dynamic DNS service to initiate communication with the dynamically-addressed peer, branch_2. It also depends on the peer ID (local ID) to initiate the VPN tunnel with branch_2.
Configure branch_1, the fixed address side
Configuring the fixed-address VPN peer includes:
- Configuring branch_1 VPN tunnel settings
- Configuring branch_1 security policies
Configuring branch_1 VPN tunnel settings
Define the Phase 1 parameters needed to establish a secure connection with the remote peer. For more information, see Phase 1 parameters on page 1624.
To configure branch_1 Phase 1 VPN settings
1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Enter the following information and select OK.
Name Enter branch_1. A name to identify the VPN tunnel. This name appears in Phase 2 configurations, security policies and the VPN monitor.
Remote Gateway Select Dynamic DNS. The remote peer this FortiGate is connecting to has a dynamic IP address.
Dynamic DNS Type the fully qualified domain name of the remote peer (for example, example.com).
Interface Select wan1. The public facing interface on the fixed-address FortiGate unit.
Mode Select Aggressive.
Peer Options Select This peer ID, and enter example.com. This option only appears when the mode is set to Aggressive. The identifier of the FortiGate unit with the dynamic address.
4. Define the Phase 2 parameters needed to create a VPN tunnel with the remote peer. See Phase 2 parameters on page 1642. Enter these settings in particular:
Name Enter branch_1_p2. A name to identify this Phase 2 configuration.
Phase 1 Select branch_1.
The name of the Phase 1 configuration that you defined for the remote peer. You can select the name of the remote gateway from the Dynamic DNS part of the list.
Configuring branch_1 security policies
The branch_1 FortiGate unit has a fixed IP address and will be connecting to the branch_2 FortiGate unit that has a dynamic IP address and a domain name of example.com. Remember if you are using route-based security policies that you must add a route for the VPN traffic.
Defining address ranges for branch_1 security policies
As with branch_2 previously, branch_1 needs address ranges defined as well. See Defining VPN security policies on page 1648.
1. Go to Policy & Objects > Addresses.
2. Select Create New.
3. Enter the following information, and select OK.
Name Enter branch_2_internal. A meaningful name for the private network behind the branch_2 FortiGate unit.
Type Select Subnet.
Subnet / IP Range Enter 10.10.10.0/24. Include the netmask or specify a specific range.
Interface Select internal. This is the interface on this FortiGate unit that will be hand- ling with this traffic.
4. Define an address name for the IP address and netmask of the private network behind the remote peer.
5. Select Create New.
6. Enter the following information, and select OK.
Name Enter branch_1_internal. A meaningful name for the private network behind the branch_1 peer.
Type Select Subnet.
Subnet / IP Range Enter 192.168.1.0/24. Include the netmask or specify a specific range.
Interface Select any. The interface on this FortiGate unit that will be handling with this traffic. If you are unsure, or multiple interfaces may be handling this traffic use any.
Creating branch_1 route-based security policies
Define an ACCEPT security policy to permit communications between the source and destination addresses. See Defining VPN security policies on page 1648.
1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter the following information, and select OK.
Incoming Interface Select internal. The interface that connects to the private network behind the branch_1 FortiGate unit.
Source Address Select branch_1_internal. The address name that you defined for the private network behind this FortiGate unit.
Outgoing Interface Select branch_1. The VPN Tunnel (IPsec Interface) you configured earlier.
Destination Address Select branch_2_internal. The address name that you defined for the private network behind the branch_2 peer.
Action Select ACCEPT.
Enable NAT Disable
Comments Internal -> branch2
To permit the remote client to initiate communication, you need to define a security policy for communication in that direction.
4. Select Create New.
5. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
6. Enter the following information, and select OK.
Incoming Interface Select branch_1. The VPN Tunnel (IPsec Interface) you configured earlier.
Source Address Select branch_2_internal. The address name that you defined for the private network behind the branch_2 remote peer.
Outgoing Interface Select internal. The interface that connects to the private network behind this FortiGate unit.
Destination Address Select branch_1_internal. The address name that you defined for the private network behind this FortiGate unit.
Action Select ACCEPT.
Enable NAT Disable
Comments branch_2 -> Internal
Creating branch_1 policy-based security policies
A policy-based security policy allows you the flexibility to allow inbound or outbound traffic or both through this single policy.
This policy-based IPsec VPN security policy allows both inbound and outbound traffic
1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information, and select OK.
Incoming Interface Select internal. The interface that connects to the private network behind this FortiGate unit.
Source Address Select branch_1_internal. The address name that you defined for the private network behind this FortiGate unit.
Outgoing Interface Select wan1. The FortiGate unit’s public interface.
Destination Address Select branch_2_internal. The address name that you defined for the private network behind the remote peer.
VPN Tunnel Select Use Existing and select branch_1 from the drop-down list.
Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.
3. Place this security policy in the policy list above any other policies having similar source and destination addresses.
Testing
Once both ends are configured, you can test the VPN tunnel.
To test the VPN initiated by branch_2
1. On branch_2, go to Monitor > IPsec Monitor.
All IPsec VPN tunnels will be listed on this page, no matter if they are connected or disconnected.
2. Select the tunnel listed for branch_2, and select the status column for that entry.
The status will say Bring Up and remote port, incoming and outgoing data will all be zero. This indicates an inactive tunnel. When you select Bring Up, the FortiGate will try to set up a VPN session over this tunnel. If it is successful, Bring Up will change to Active, and the arrow icon will change to a green up arrow icon.
3. If this does not create a VPN tunnel with increasing values for incoming and outgoing data, you need to start troubleshooting:
To test the VPN initiated by branch_1
1. On branch_1, go to Monitor > IPsec Monitor.
2. Select the tunnel listed for branch_1, and select the status column.
The difference between branch_2 and branch_1 at this point is that the tunnel entry for branch-1 will not have a remote gateway IP address. It will be resolved when the VPN tunnel is started.
3. If this does not create a VPN tunnel with increasing values for incoming and outgoing data, you need to start troubleshooting.
Some troubleshooting ideas include:
- If there was no entry for the tunnel on the monitor page, check the Auto Key (IKE) page to verify the Phase 1 and Phase 2 entries exist.
- Check the security policy or policies, and ensure there is an outgoing policy as a minimum.
- Check that you entered a local ID in the Phase 1 configuration, and that branch_1 has the same local ID.
- Ensure the local DNS server has an up-to-date DNS entry for exmaple.com. For more information, see Troubleshooting on page 1826.