FortiOS 6 – IPSEC Hub-and-spoke configurations

Hub-and-spoke configurations

This section describes how to set up hub-and-spoke IPsec VPNs. The following topics are included in this section:

Configuration overview

Configure the hub

Configure the spokes

Dynamic spokes configuration example

Configuration overview

In a hub-and-spoke configuration, VPN connections radiate from a central FortiGate unit (the hub) to a number of remote peers (the spokes). Traffic can pass between private networks behind the hub and private networks behind the remote peers. Traffic can also pass between remote peer private networks through the hub.

Example hub-and-spoke configuration

The actual implementation varies in complexity depending on:

Configuration overview

l Whether the spokes are statically or dynamically addressed l The addressing scheme of the protected subnets l How peers are authenticated

This guide discusses the issues involved in configuring a hub-and-spoke VPN and provides some basic configuration examples.

Hub-and-spoke infrastructure requirements

  • The FortiGate hub must be operating in NAT mode and have a static public IP address.
  • Spokes may have static IP addresses, dynamic IP addresses (see FortiGate dialup-client configurations on page 137), or static domain names and dynamic IP addresses (see Dynamic DNS configuration on page 115).

Spoke gateway addressing

The public IP address of the spoke is the VPN remote gateway as seen from the hub. Statically addressed spokes each require a separate VPN Phase 1 configuration on the hub. When there are many spokes, this becomes rather cumbersome.

Using dynamic addressing for spokes simplifies the VPN configuration because then the hub requires only a single Phase 1 configuration with “dialup user” as the remote gateway. You can use this configuration even if the remote peers have static IP addresses. A remote peer can establish a VPN connection regardless of its IP address if its traffic selectors match and it can authenticate to the hub. See Configuration overview on page 94 for an example of this configuration.

Protected networks addressing

The addresses of the protected networks are needed to configure destination selectors and sometimes for security policies and static routes. The larger the number of spokes, the more addresses there are to manage. You can l Assign spoke subnets as part of a larger subnet, usually on a new network or

l Create address groups that contain all of the needed addresses

Using aggregated subnets

If you are creating a new network, where subnet IP addresses are not already assigned, you can simplify the VPN configuration by assigning spoke subnets that are part of a large subnet.

Aggregated subnets

All spokes use the large subnet address, 10.1.0.0/16 for example, as:

  • The IPsec destination selector l The destination of the security policy from the private subnet to the VPN (required for policy-based VPN, optional for route-based VPN)
  • The destination of the static route to the VPN (route-based)

Each spoke uses the address of its own protected subnet as the IPsec source selector and as the source address in its VPN security policy. The remote gateway is the public IP address of the hub FortiGate unit.

Using an address group

If you want to create a hub-and-spoke VPN between existing private networks, the subnet addressing usually does not fit the aggregated subnet model discussed earlier. All of the spokes and the hub will need to include the addresses of all the protected networks in their configuration.

On FortiGate units, you can define a named firewall address for each of the remote protected networks and add these addresses to a firewall address group. For a policy-based VPN, you can then use this address group as the destination of the VPN security policy.

For a route-based VPN, the destination of the VPN security policy can be set to All. You need to specify appropriate routes for each of the remote subnets.

Authentication

Authentication is by a common pre-shared key or by certificates. For simplicity, the examples in this chapter assume that all spokes use the same pre-shared key.

Configure the hub

At the FortiGate unit that acts as the hub, you need to:

hub

l Configure the VPN to each spoke l Configure communication between spokes

You configure communication between spokes differently for a policy-based VPN than for a route-based VPN. For a policy-based VPN, you configure a VPN concentrator. For a route-based VPN, you must either define security policies or group the IPsec interfaces into a zone.

Define the hub-spoke VPNs

Perform these steps at the FortiGate unit that will act as the hub. Although this procedure assumes that the spokes are all FortiGate units, a spoke could also be VPN client software, such as FortiClient Endpoint Security.

Configuring the VPN hub

  1. At the hub, define the Phase 1 configuration for each spoke. See Phase 1 parameters on page 46. Enter these settings in particular:
Name Enter a name to identify the VPN in Phase 2 configurations, security policies and the VPN monitor.
Remote Gateway The remote gateway is the other end of the VPN tunnel. There are three options:

Static IP Address — Enter the spoke’s public IP Address. You will need to create a Phase 1 configuration for each spoke. Either the hub or the spoke can establish the VPN connection.

Dialup User — No additional information is needed. The hub accepts connections from peers with appropriate encryption and authentication settings. Only one Phase 1 configuration is needed for multiple dialup spokes. Only the spoke can establish the VPN tunnel.

Dynamic DNS — If the spoke subscribes to a dynamic DNS service, enter the spoke’s Dynamic DNS domain name. Either the hub or the spoke can establish the VPN connection. For more information, see Dynamic DNS configuration on page 1.

Local Interface Select the FortiGate interface that connects to the remote gateway. This is usually the FortiGate unit’s public interface.
  1. Define the Phase 2 parameters needed to create a VPN tunnel with each spoke. See Phase 2 parameters on page 66. Enter these settings in particular:
Name Enter a name to identify this spoke Phase 2 configuration.
Phase 1 Select the name of the Phase 1 configuration that you defined for this spoke.

IPsec VPN in ADVPN hub-and-spoke

IPsec VPN traffic is allowed through a tunnel between an ADVPN hub-and-spoke.

CLI syntax:

config vpn ipsec phase1-interface edit “int-fgtb” … set auto-discovery-sender [enable | disable] set auto-discovery-receiver [enable | disable] set auto-discovery-forwarder [enable | disable] …

next

end

config vpn ipsec phase2-interface edit “int-fgtb” …

set auto-discovery-sender phase1 [enable | disable] …

next

end

Define the hub-spoke security policies

  1. Define a name for the address of the private network behind the hub. For more information, see Defining policy addresses on page 1.
  2. Define names for the addresses or address ranges of the private networks behind the spokes. For more information, see Defining policy addresses on page 1.
  3. Define the VPN concentrator. See To define the VPN concentrator on page 99.
  4. Define security policies to permit communication between the hub and the spokes. For more information, see Defining VPN security policies on page 1.

Route-based VPN security policies

Define ACCEPT security policies to permit communications between the hub and the spoke. You need one policy for each direction.

Adding 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 these settings in particular:
Incoming Interface Select the VPN Tunnel (IPsec Interface) you configured in Step 1.
Source Address Select the address name you defined in Step 2 for the private network behind the spoke FortiGate unit.
Outgoing Interface Select the hub’s interface to the internal (private) network.
Destination Address Select the source address that you defined in Step 1.
Action Select ACCEPT.
Enable NAT Enable.

hub

Incoming Interface Select the VPN Tunnel (IPsec Interface) you configured inStep 1.
Source Address Select the address name you defined in Step 2 for the private network behind the spoke FortiGate units.
Outgoing Interface Select the source address that you defined in Step 1.
Destination Address Select the hub’s interface to the internal (private) network.
Action Select ACCEPT.
Enable NAT Enable.

Policy-based VPN security policy

Define an IPsec security policy to permit communications between the hub and the spoke.

Adding policies
  1. Go to Policy & Objects > IPv4 Policy and select Create New.
  2. Enter these settings in particular:
Incoming Interface Select the hub’s interface to the internal (private) network.
Source Address Select the source address that you defined in Step 1.
Outgoing Interface Select the hub’s public network interface.
Destination Address Select the address name you defined in Step 2 for the private network behind the spoke FortiGate unit.
VPN Tunnel Select Use Existing and select the name of the Phase 1 configuration that you created for the spoke in Step 1.

Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

In the policy list, arrange the policies in the following order:

l IPsec policies that control traffic between the hub and the spokes first l The default security policy last

Configuring communication between spokes (policy-based VPN)

For a policy-based hub-and-spoke VPN, you define a concentrator to enable communication between the spokes.

To define the VPN concentrator

  1. At the hub, go to VPN > IPsec Concentrator and select Create New.
  2. In the Concentrator Name field, type a name to identify the concentrator.
  3. From the Available Tunnels list, select a VPN tunnel and then select the right-pointing arrow.
  4. Repeat Step 3 until all of the tunnels associated with the spokes are included in the concentrator.
  5. Select OK.

Configuring communication between spokes (route-based VPN)

For a route-based hub-and-spoke VPN, there are several ways you can enable communication between the spokes:

l Put all of the IPsec interfaces into a zone and enable intra-zone traffic. This eliminates the need for any security policy for the VPN, but you cannot apply UTM features to scan the traffic for security threats. l Put all of the IPsec interfaces into a zone and create a single zone-to-zone security policy l Create a security policy for each pair of spokes that are allowed to communicate with each other. The number of policies required increases rapidly as the number of spokes increases.

Using a zone as a concentrator

A simple way to provide communication among all of the spokes is to create a zone and allow intra-zone communication. You cannot apply UTM features using this method.

  1. Go to Network > Interfaces.
  2. Select the down-arrow on the Create New button and select Zone.
  3. In the Zone Name field, enter a name, such as Our_VPN_zone.
  4. Clear Block intra-zone traffic.
  5. In the Interface Members list, select the IPsec interfaces that are part of your VPN.
  6. Select OK.

Using a zone with a policy as a concentrator

If you put all of the hub IPsec interfaces involved in the VPN into a zone, you can enable communication among all of the spokes and apply UTM features with just one security policy.

Creating a zone for the VPN
  1. Go to Network > Interfaces.
  2. Select the down-arrow on the Create New button and select Zone.
  3. In the Zone Name field, enter a name, such as Our_VPN_zone.
  4. Select Block intra-zone traffic.
  5. In the Interface Members list, select the IPsec interfaces that are part of your VPN.
  6. Select OK.
Creating a security policy for the zone
  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 settings: and select OK.
Incoming Interface Select the zone you created for your VPN.

spokes

Source Address Select All.
Outgoing Interface Select the zone you created for your VPN.
Destination Address Select All.
Action Select ACCEPT.
Enable NAT Enable.

Using security policies as a concentrator

To enable communication between two spokes, you need to define an ACCEPT security policy for them. To allow either spoke to initiate communication, you must create a policy for each direction. This procedure describes a security policy for communication from Spoke 1 to Spoke 2. Others are similar.

  1. Define names for the addresses or address ranges of the private networks behind each spoke. For more information, see Defining policy addresses on page 1.
  2. Go to Policy & Objects > IPv4 Policy and select Create New.
  3. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
  4. Enter the settings and select OK.
Incoming Interface Select the IPsec interface that connects to Spoke 1.
Source Address Select the address of the private network behind Spoke 1.
Outgoing Interface Select the IPsec interface that connects to Spoke 2.
Destination Address Select the address of the private network behind Spoke 2.
Action Select ACCEPT.
Enable NAT Enable.

Configure the spokes

Although this procedure assumes that the spokes are all FortiGate units, a spoke could also be VPN client software, such as FortiClient Endpoint Security.

Perform these steps at each FortiGate unit that will act as a spoke.

Creating the Phase 1 and phase_2 configurations

  1. At the spoke, define the Phase 1 parameters that the spoke will use to establish a secure connection with the hub.

See Phase 1 parameters on page 46. Enter these settings:

Remote Gateway Select Static IP Address.
IP Address Type the IP address of the interface that connects to the hub.

 

Configure the spokes

  1. Create the Phase 2 tunnel definition. See Phase 2 parameters on page 66. Select the set of Phase 1 parameters that you defined for the hub. You can select the name of the hub from the Static IP Address part of the list.

Configuring security policies for hub-to-spoke communication

  1. Create an address for this spoke. See Defining policy addresses on page 1. Enter the IP address and netmask of the private network behind the spoke.
  2. Create an address to represent the hub. See Defining policy addresses on page 1. Enter the IP address and netmask of the private network behind the hub.
  3. Define the security policy to enable communication with the hub.

Route-based VPN security policy

Define two security policies to permit communications to and from the hub.

  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 these settings:
Incoming Interface Select the virtual IPsec interface you created.
Source Address Select the hub address you defined in Step 1.
Outgoing Interface Select the spoke’s interface to the internal (private) network.
Destination Address Select the spoke addresses you defined in Step 2.
Action Select ACCEPT.
Enable NAT Enable
Incoming Interface Select the spoke’s interface to the internal (private) network.
Source Address Select the spoke address you defined in Step 1.
Outgoing Interface Select the virtual IPsec interface you created.
Destination Address Select the hub destination addresses you defined in Step 2.
Action Select ACCEPT.
Enable NAT Enable

Policy-based VPN security policy

Define an IPsec security policy to permit communications with the hub. See Defining VPN security policies on page 1.

  1. Go to Policy & Objects > IPv4 Policy and select Create New.
  2. Enter these settings in particular:

spokes

Incoming Interface Select the spoke’s interface to the internal (private) network.
Source Address Select the spoke address you defined in Step 1.
Outgoing Interface Select the spoke’s interface to the external (public) network.
Destination Address Select the hub address you defined in Step 2.
VPN Tunnel Select Use Existing and select the name of the Phase 1 configuration you defined.

Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

Configuring security policies for spoke-to-spoke communication

Each spoke requires security policies to enable communication with the other spokes. Instead of creating separate security policies for each spoke, you can create an address group that contains the addresses of the networks behind the other spokes. The security policy then applies to all of the spokes in the group.

  1. Define destination addresses to represent the networks behind each of the other spokes. Add these addresses to an address group.
  2. Define the security policy to enable communication between this spoke and the spokes in the address group you created.

Policy-based VPN security policy

Define an IPsec security policy to permit communications with the other spokes. See Defining VPN security policies on page 1. Enter these settings in particular:

Route-based VPN security policy

Define two security policies to permit communications to and from the other spokes.

  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 these settings in particular:
Incoming Interface Select the virtual IPsec interface you created.
Source Address Select the spoke address group you defined in Step “Configure the spokes ” on page 101.
Outgoing Interface Select the spoke’s interface to the internal (private) network.
Destination Address Select this spoke’s address name.
Action Select ACCEPT.
Enable NAT Enable
  1. Select Create New, leave the Policy Type as Firewall and leave the Policy Subtype as Address, and enter these settings:
Incoming Interface Select the spoke’s interface to the internal (private) network.
Source Address Select this spoke’s address name.
Outgoing Interface Select the virtual IPsec interface you created.
Destination Address Select the spoke address group you defined in Step 1.
Action Select ACCEPT.
Enable NAT Enable

Policy-based VPN security policy

  1. Go to Policy & Objects > IPv4 Policy and select Create New.
  2. Enter the following:
Incoming Interface Select this spoke’s internal (private) network interface.
Source Address Select this spoke’s source address.
Outgoing Interface Select the spoke’s interface to the external (public) network.
Destination Address Select the spoke address group you defined in Step 1.
VPN Tunnel Select Use Existing and select the name of the Phase 1 configuration you defined.

Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

Place this policy or policies in the policy list above any other policies having similar source and destination addresses.

Dynamic spokes configuration example

This example demonstrates how to set up a basic route-based hub-and-spoke IPsec VPN that uses preshared keys to authenticate VPN peers.

 

Example hub-and-spoke configuration

In the example configuration, the protected networks 10.1.0.0/24, 10.1.1.0/24 and 10.1.2.0/24 are all part of the larger subnet 10.1.0.0/16. The steps for setting up the example hub-and-spoke configuration create a VPN among Site 1, Site 2, and the HR Network.

The spokes are dialup. Their addresses are not part of the configuration on the hub, so only one spoke definition is required no matter the number of spokes. For simplicity, only two spokes are shown.

In an ADVPN topology, any two pair of peers can create a shortcut, as long as one of the devices is not behind NAT.

The on-the-wire format of the ADVPN messages use TLV encoding. Because of this, this feature is not compatible with any previous ADVPN builds.

Configure the hub (FortiGate_1)

The Phase 1 configuration defines the parameters that FortiGate_1 will use to authenticate spokes and establish secure connections.

For the purposes of this example, one preshared key will be used to authenticate all of the spokes. Each key must contain at least 6 printable characters and best practices dictates that it only be known by network administrators. For optimum protection against currently known attacks, each key must consist of a minimum of 16 randomly chosen alphanumeric characters.

Define the IPsec configuration

  1. At FortiGate_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). Define the Phase 1 parameters that the hub will use to establish a secure connection to the spokes.
Name Enter a name (for example, toSpokes).
Remote Gateway Dialup user
Local Interface External
Mode Main
Authentication Method Preshared Key
Pre-shared Key Enter the preshared key.
Peer Options Any peer ID

The basic Phase 2 settings associate IPsec Phase 2 parameters with the Phase 1 configuration and specify the remote end points of the VPN tunnels.

  1. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
  2. Enter the following information, and select OK:
Name Enter a name for the Phase 2 definition (for example, toSpokes_ph2).
Phase 1 Select the Phase 1 configuration that you defined previously (for example, toSpokes).

Define the security policies

security policies control all IP traffic passing between a source address and a destination address. For a routebased VPN, the policies are simpler than for a policy-based VPN. Instead of an IPSEC policy, you use an ACCEPT policy with the virtual IPsec interface as the external interface.

Before you define security policies, you must first define firewall addresses to use in those policies. You need addresses for:

  • The HR network behind FortiGate_1
  • The aggregate subnet address for the protected networks
Defining the IP address of the HR network behind FortiGate_1
  1. Go to Policy & Objects > Addresses.
  2. Select Create New, enter the following information, and select OK:
Name Enter an address name (for example, HR_Network).
Type Subnet
Subnet/IP Range Enter the IP address of the HR network behind FortiGate_1 (for example, 10.1.0.0/24).
Specifying the IP address the aggregate protected subnet
  1. Go to Policy & Objects > Addresses.
  2. Select Create New, enter the following information, and select OK:
Address Name Enter an address name (for example, Spoke_net).
Type Subnet
Subnet/IP Range Enter the IP address of the aggregate protected network, 10.1.0.0/16
Defining the security policy for traffic from the hub to the spokes 1. Go to Policy & Objects > IPv4 Policy and select Create New,
  1. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
  2. Enter the following information, and select OK:
Incoming Interface Select the interface to the HR network, port 1.
Source Address Select HR_Network.
Outgoing Interface Select the virtual IPsec interface that connects to the spokes, toSpokes.
Destination Address Select Spoke_net.
Action Select ACCEPT.

Place the policy in the policy list above any other policies having similar source and destination addresses.

Configure communication between spokes

Spokes communicate with each other through the hub. You need to configure the hub to allow this communication. An easy way to do this is to create a zone containing the virtual IPsec interfaces even if there is only one, and create a zone-to-zone security policy.

  1. Go to Network > Interfaces.
  2. Select the down-arrow on the Create New button and select Zone.
  3. In the Zone Name field, enter a name, such as Our_VPN_zone.
  4. Select Block intra-zone traffic.

You could enable intra-zone traffic and then you would not need to create a security policy. But, you would not be able to apply UTM features.

  1. In Interface Members, select the virtual IPsec interface, toSpokes.
  2. Select OK.
Creating a security policy for the zone
  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 these settings:
Incoming Interface Select Our_VPN_zone.
Source Address Select All.
Outgoing Interface Select Our_VPN_zone.
Destination Address Select All.
Action Select ACCEPT.
Enable NAT Enable.
  1. Select OK.

Configure the spokes

In this example, all spokes have nearly identical configuration, requiring the following:

  • Phase 1 authentication parameters to initiate a connection with the hub. l Phase 2 tunnel creation parameters to establish a VPN tunnel with the hub.
  • A source address that represents the network behind the spoke. This is the only part of the configuration that is different for each spoke.
  • A destination address that represents the aggregate protected network. l A security policy to ena.ble communications between the spoke and the aggregate protected network

Define the IPsec configuration

At each spoke, create the following configuration.

  1. At the spoke, 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). Enter the following information:
Name Type a name, for example, toHub.
Remote Gateway Select Static IP Address.
IP Address Enter 172.16.10.1.
Local Interface Select Port2.
Mode Main
Authentication Method Preshared Key
Pre-shared Key Enter the preshared key. The value must be identical to the preshared key that you specified previously in the FortiGate_1 configuration
Peer Options Select Any peer ID.
  1. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
  2. Enter the following information and select OK:
Name Enter a name for the tunnel, for example, toHub_ph2.
Phase 1 Select the name of the Phase 1 configuration that you defined previously, for example, toHub.
Advanced Select to show the following Quick Mode Selector settings.
Source Enter the address of the protected network at this spoke.

For spoke_1, this is 10.1.1.0/24.

For spoke_2, this is 10.1.2.0/24.

Destination Enter the aggregate protected subnet address, 10.1.0.0/16.

Define the security policies

You need to define firewall addresses for the spokes and the aggregate protected network and then create a security policy to enable communication between them.

Defining the IP address of the network behind the spoke
  1. Go to Policy & Objects > Addresses.
  2. Select Create New and enter the following information:
Address Name Enter an address name, for example LocalNet.
Type Subnet
Subnet/IP Range Enter the IP address of the private network behind the spoke.

For spoke_1, this is 10.1.1.0/24.

For spoke_2, this is 10.1.2.0/24.

Specifying the IP address of the aggregate protected network
  1. Go to Policy & Objects > Addresses.
  2. Select Create New and enter the following information:
Address Name Enter an address name, for example, Spoke_net.
Type Subnet
Subnet/IP Range Enter the IP address of the aggregate protected network, 10.1.0.0/16.
Defining the security policy
  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:
Incoming Interface Select the virtual IPsec interface, toHub.
Source Address Select the aggregate protected network address Spoke_net.
Outgoing Interface Select the interface to the internal (private) network, port1.
Destination Address Select the address for this spoke’s protected network LocalNet.
Action Select ACCEPT.
  1. 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 the interface to the internal private network, port1.
Source Address Select the address for this spoke’s protected network, LocalNet.
Outgoing Interface Select the virtual IPsec interface, toHub.
Destination Address Select the aggregate protected network address, Spoke_net.
Action Select ACCEPT.

Place these policies in the policy list above any other policies having similar source and destination addresses.

 

This entry was posted in Administration Guides, FortiGate, FortiOS 6 on by .

About Mike

Michael Pruett, CISSP has a wide range of cyber-security and network engineering expertise. The plethora of vendors that resell hardware but have zero engineering knowledge resulting in the wrong hardware or configuration being deployed is a major pet peeve of Michael's. This site was started in an effort to spread information while providing the option of quality consulting services at a much lower price than Fortinet Professional Services. Owns PacketLlama.Com (Fortinet Hardware Sales) and Office Of The CISO, LLC (Cybersecurity consulting firm).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.