Fortinet Document Library

Version:


Table of Contents

Cookbook

6.2.0
Download PDF
Copy Link

VXLAN over IPsec using a VTEP

This example is intended for network engineers who are familiar with the FortiGate platform. It does not include all of the required configuration steps. The intention is to provide the information that you need to implement VXLAN over IPsec VPN using a VXLAN Tunnel Endpoint (VTEP).

Sample topology

This example covers a VXLAN over IPsec VPN configuration using the FortiGate as the VTEP. There is also a technical note showing how to directly encapsulate traffic in IPsec VPN without creating a VXLAN interface.

This example shows a specific configuration that uses a hub-and-spoke topology. However, the same logic can be applied to a static VPN. This example's hub-and-spoke topology shows a dialup VPN for convenience as it uses a single phase 1 dialup definition on the hub FortiGate, with additional spoke tunnels being added without any changes to the hub other than adding a user account for each additional spoke.

Sample configuration

This sample configuration has the following steps:

  1. Configure IPsec VPN
  2. Configure a VXLAN interface and bind it to IPsec tunnel 1
  3. Bind the VXLAN interface to the Ethernet port
  4. Test the configuration
To configure IPsec VPN:
  1. Configure the phase 1 and phase 2 interfaces on the hub and spoke FortiGates:
    1. Run the following CLI commands on the hub FortiGate:
      config vpn ipsec phase1-interface
         edit "SPOKES"
            set type dynamic
            set interface "port2"
            set mode aggressive
            set peertype one
            set proposal aes256-sha256
            set xauthtype auto
            set authusrgrp "SPOKES"
            set peerid "SPOKES"
            set psksecret <SECRET>
         next
      end
      config vpn ipsec phase2-interface
         edit "SPOKES"
            set phase1name "SPOKES"
            set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
         next
      end
    2. Run the following CLI commands on the spoke FortiGates:
      config vpn ipsec phase1-interface
         edit "HUB"
            set interface "port2"
            set mode aggressive
            set peertype any
            set proposal aes256-sha256
            set localid "SPOKES"
            set xauthtype client
            set authusr "SPOKE1"
            set authpasswd <SECRET>
            set remote-gw <HUB_PUBLIC_IP>
            set psksecret <SECRET>
         next
      end
      config vpn ipsec phase2-interface
         edit "HUB"
            set phase1name "HUB"
            set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
            set auto-negotiate enable
            set src-subnet 192.168.255.2 255.255.255.255
         next
      end
    Note

    The hub FortiGate inserts a reverse route pointing to newly established tunnel interfaces for any of the subnets that the spoke FortiGate's source quick mode selectors provides. This is why you should set the tunnel IP address here.

  2. Configure the IPsec VPN policies on the hub and spoke FortiGates:
    1. Run the following CLI commands on the hub FortiGate. This policy allows VXLAN traffic between spokes, since spoke-to-spoke traffic is done through the hub:
      config firewall policy
         edit 1
            set name "VXLAN_SPOKE_to_SPOKE"
            set srcintf "SPOKES"
            set dstintf "SPOKES"
            set srcaddr "NET_192.168.255.0"
            set dstaddr "NET_192.168.255.0"
            set action accept
            set schedule "always"
            set service "UDP_4789"
            set logtraffic all
            set fsso disable
         next
      end
    2. Run the following commands on the spoke FortiGates. Usually, a tunnel interface is required for the IPsec VPN to establish a policy. In this example, the FortiGate issues the VXLAN tunnel, which ends at the remote FortiGate's tunnel interface. This explicitly removes the requirement for allowing VXLAN traffic. This explains how such a policy can be created:
      config firewall policy
         edit 1
            set name "FICTIVE_IPSEC_POLICY"
            set srcintf "HUB"
            set dstintf "HUB"
            set srcaddr "none"
            set dstaddr "none"
            set action accept
            set schedule "always"
            set service "PING"
            set logtraffic disable
            set fsso disable
         next
      end
  3. Configure the IPsec tunnel interfaces. IPsec tunnel interfaces are used to support VXLAN tunnel termination. Therefore, you must set an IP address for each tunnel interface. You should also allow ping access for troubleshooting purposes:
    1. Run the following CLI commands on the hub FortiGate. The remote IP address is not used, but is necessary for this configuration.
      config system interface
         edit "SPOKES"
            set vdom "root"
            set ip 192.168.255.1 255.255.255.255
            set allowaccess ping
            set type tunnel
            set remote-ip 192.168.255.254 255.255.255.0
            set snmp-index 12
            set interface "port2"
         next
      end
    2. Run the following CLI commands on the spoke FortiGates:
      config system interface
         edit "HUB"
            set vdom "root"
            set ip 192.168.255.2 255.255.255.255
            set allowaccess ping
            set type tunnel
            set remote-ip 192.168.255.1 255.255.255.0
            set snmp-index 12
            set interface "port2"
         next
      end
To configure a VXLAN interface and bind it to IPsec tunnel 1:

All VXLAN interfaces share the same VXLAN Network ID (VNI).

  1. Run the following CLI commands on the hub FortiGate. The remote IP address is the spokes' tunnel interfaces' IP addresses.
    config system VXLAN
       edit "SPOKES_VXLAN"
          set interface "SPOKES"
          set vni 1
          set remote-ip "192.168.255.2" "192.168.255.3"
       next
    end
  2. Run the following CLI commands on the spoke FortiGates. The remote IP address is the hub's tunnel interface's IP address.
    config system VXLAN
       edit "HUB_VXLAN"
          set interface "HUB"
          set vni 1
          set remote-ip "192.168.255.1"
       next
    end

    You can add another spoke's tunnel IP address to establish a VXLAN tunnel between spokes. For example, to add another spoke's tunnel IP address to the above example, the set remote-ip command would be set remote-ip "192.168.255.1" "192.168.255.3".

    Note

    To add more remote IP addresses to a VXLAN interface, the interface cannot be in use. You may want to provision future spokes' remote IP addresses at this point to avoid traffic disruption in the future. Otherwise, you must delete the reference (the policy in this case) before adding remote IP addresses.

Bind the VXLAN interface to the Ethernet port

VXLAN encapsulates OSI layer 2 Ethernet frames within layer 3 IP packets. This is why you must bind the internal port and VXLAN interface so that devices behind port1 have direct layer 2 access to remote peers over the VXLAN tunnel. You can use one of the following methods:

  • Use a switch interface
  • Use a virtual wire pair
To use a switch interface, use the following CLI command on the hub FortiGate:
config system switch-interface
   edit "SW"
      set vdom "root"
      set member "port1" "SPOKES_VXLAN"
   next
end
Note

According to switch interface configuration, allowing intraswitch traffic is implicitly allowed (default) or needs an explicit policy using the set intra-switch-policy explicit command.

To use a virtual wire pair, use the following CLI command on the spoke FortiGates:
config system virtual-wire-pair
   edit "VWP"
      set member "HUB_VXLAN" "port1"
   next
end

The virtual wire pair needs an explicit policy to allow traffic between interfaces:

To test the configuration:
  1. Ping the hub FortiGate from the spoke FortiGate. The output should look as follows:
    user@pc-spoke1:~$ ping 192.168.1.1 -c 3PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
    64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.24 ms
    64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.672 ms
    64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.855 ms
    --- 192.168.1.1 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2002ms
    rtt min/avg/max/mdev = 0.672/0.923/1.243/0.239 ms
  2. Sniff traffic on the hub FortiGate:
    FGT-HUB # diagnose sniffer packet any 'icmp or (udp and port 4789)' 4 0 ainterfaces=[any]
    filters=[icmp or (udp and port 4789)]
    15:00:01.438230 SPOKES in 192.168.255.2.4790 -&gt; 192.168.255.1.4789: udp 106
    
    <<<<1
    15:00:01.438256 SPOKES_VXLAN in 192.168.1.2 -&gt; 192.168.1.1: icmp: echo request
    <<<<2
    15:00:01.438260 port1 out 192.168.1.2 -&gt; 192.168.1.1: icmp: echo request
    <<<<3
    15:00:01.438532 port1 in 192.168.1.1 -&gt; 192.168.1.2: icmp: echo reply
    15:00:01.438536 SPOKES_VXLAN out 192.168.1.1 -&gt; 192.168.1.2: icmp: echo reply
    15:00:01.438546 SPOKES out 192.168.255.1.4851 -&gt; 192.168.255.2.4789: udp 106

VXLAN over IPsec using a VTEP

This example is intended for network engineers who are familiar with the FortiGate platform. It does not include all of the required configuration steps. The intention is to provide the information that you need to implement VXLAN over IPsec VPN using a VXLAN Tunnel Endpoint (VTEP).

Sample topology

This example covers a VXLAN over IPsec VPN configuration using the FortiGate as the VTEP. There is also a technical note showing how to directly encapsulate traffic in IPsec VPN without creating a VXLAN interface.

This example shows a specific configuration that uses a hub-and-spoke topology. However, the same logic can be applied to a static VPN. This example's hub-and-spoke topology shows a dialup VPN for convenience as it uses a single phase 1 dialup definition on the hub FortiGate, with additional spoke tunnels being added without any changes to the hub other than adding a user account for each additional spoke.

Sample configuration

This sample configuration has the following steps:

  1. Configure IPsec VPN
  2. Configure a VXLAN interface and bind it to IPsec tunnel 1
  3. Bind the VXLAN interface to the Ethernet port
  4. Test the configuration
To configure IPsec VPN:
  1. Configure the phase 1 and phase 2 interfaces on the hub and spoke FortiGates:
    1. Run the following CLI commands on the hub FortiGate:
      config vpn ipsec phase1-interface
         edit "SPOKES"
            set type dynamic
            set interface "port2"
            set mode aggressive
            set peertype one
            set proposal aes256-sha256
            set xauthtype auto
            set authusrgrp "SPOKES"
            set peerid "SPOKES"
            set psksecret <SECRET>
         next
      end
      config vpn ipsec phase2-interface
         edit "SPOKES"
            set phase1name "SPOKES"
            set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
         next
      end
    2. Run the following CLI commands on the spoke FortiGates:
      config vpn ipsec phase1-interface
         edit "HUB"
            set interface "port2"
            set mode aggressive
            set peertype any
            set proposal aes256-sha256
            set localid "SPOKES"
            set xauthtype client
            set authusr "SPOKE1"
            set authpasswd <SECRET>
            set remote-gw <HUB_PUBLIC_IP>
            set psksecret <SECRET>
         next
      end
      config vpn ipsec phase2-interface
         edit "HUB"
            set phase1name "HUB"
            set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
            set auto-negotiate enable
            set src-subnet 192.168.255.2 255.255.255.255
         next
      end
    Note

    The hub FortiGate inserts a reverse route pointing to newly established tunnel interfaces for any of the subnets that the spoke FortiGate's source quick mode selectors provides. This is why you should set the tunnel IP address here.

  2. Configure the IPsec VPN policies on the hub and spoke FortiGates:
    1. Run the following CLI commands on the hub FortiGate. This policy allows VXLAN traffic between spokes, since spoke-to-spoke traffic is done through the hub:
      config firewall policy
         edit 1
            set name "VXLAN_SPOKE_to_SPOKE"
            set srcintf "SPOKES"
            set dstintf "SPOKES"
            set srcaddr "NET_192.168.255.0"
            set dstaddr "NET_192.168.255.0"
            set action accept
            set schedule "always"
            set service "UDP_4789"
            set logtraffic all
            set fsso disable
         next
      end
    2. Run the following commands on the spoke FortiGates. Usually, a tunnel interface is required for the IPsec VPN to establish a policy. In this example, the FortiGate issues the VXLAN tunnel, which ends at the remote FortiGate's tunnel interface. This explicitly removes the requirement for allowing VXLAN traffic. This explains how such a policy can be created:
      config firewall policy
         edit 1
            set name "FICTIVE_IPSEC_POLICY"
            set srcintf "HUB"
            set dstintf "HUB"
            set srcaddr "none"
            set dstaddr "none"
            set action accept
            set schedule "always"
            set service "PING"
            set logtraffic disable
            set fsso disable
         next
      end
  3. Configure the IPsec tunnel interfaces. IPsec tunnel interfaces are used to support VXLAN tunnel termination. Therefore, you must set an IP address for each tunnel interface. You should also allow ping access for troubleshooting purposes:
    1. Run the following CLI commands on the hub FortiGate. The remote IP address is not used, but is necessary for this configuration.
      config system interface
         edit "SPOKES"
            set vdom "root"
            set ip 192.168.255.1 255.255.255.255
            set allowaccess ping
            set type tunnel
            set remote-ip 192.168.255.254 255.255.255.0
            set snmp-index 12
            set interface "port2"
         next
      end
    2. Run the following CLI commands on the spoke FortiGates:
      config system interface
         edit "HUB"
            set vdom "root"
            set ip 192.168.255.2 255.255.255.255
            set allowaccess ping
            set type tunnel
            set remote-ip 192.168.255.1 255.255.255.0
            set snmp-index 12
            set interface "port2"
         next
      end
To configure a VXLAN interface and bind it to IPsec tunnel 1:

All VXLAN interfaces share the same VXLAN Network ID (VNI).

  1. Run the following CLI commands on the hub FortiGate. The remote IP address is the spokes' tunnel interfaces' IP addresses.
    config system VXLAN
       edit "SPOKES_VXLAN"
          set interface "SPOKES"
          set vni 1
          set remote-ip "192.168.255.2" "192.168.255.3"
       next
    end
  2. Run the following CLI commands on the spoke FortiGates. The remote IP address is the hub's tunnel interface's IP address.
    config system VXLAN
       edit "HUB_VXLAN"
          set interface "HUB"
          set vni 1
          set remote-ip "192.168.255.1"
       next
    end

    You can add another spoke's tunnel IP address to establish a VXLAN tunnel between spokes. For example, to add another spoke's tunnel IP address to the above example, the set remote-ip command would be set remote-ip "192.168.255.1" "192.168.255.3".

    Note

    To add more remote IP addresses to a VXLAN interface, the interface cannot be in use. You may want to provision future spokes' remote IP addresses at this point to avoid traffic disruption in the future. Otherwise, you must delete the reference (the policy in this case) before adding remote IP addresses.

Bind the VXLAN interface to the Ethernet port

VXLAN encapsulates OSI layer 2 Ethernet frames within layer 3 IP packets. This is why you must bind the internal port and VXLAN interface so that devices behind port1 have direct layer 2 access to remote peers over the VXLAN tunnel. You can use one of the following methods:

  • Use a switch interface
  • Use a virtual wire pair
To use a switch interface, use the following CLI command on the hub FortiGate:
config system switch-interface
   edit "SW"
      set vdom "root"
      set member "port1" "SPOKES_VXLAN"
   next
end
Note

According to switch interface configuration, allowing intraswitch traffic is implicitly allowed (default) or needs an explicit policy using the set intra-switch-policy explicit command.

To use a virtual wire pair, use the following CLI command on the spoke FortiGates:
config system virtual-wire-pair
   edit "VWP"
      set member "HUB_VXLAN" "port1"
   next
end

The virtual wire pair needs an explicit policy to allow traffic between interfaces:

To test the configuration:
  1. Ping the hub FortiGate from the spoke FortiGate. The output should look as follows:
    user@pc-spoke1:~$ ping 192.168.1.1 -c 3PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
    64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.24 ms
    64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.672 ms
    64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.855 ms
    --- 192.168.1.1 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2002ms
    rtt min/avg/max/mdev = 0.672/0.923/1.243/0.239 ms
  2. Sniff traffic on the hub FortiGate:
    FGT-HUB # diagnose sniffer packet any 'icmp or (udp and port 4789)' 4 0 ainterfaces=[any]
    filters=[icmp or (udp and port 4789)]
    15:00:01.438230 SPOKES in 192.168.255.2.4790 -&gt; 192.168.255.1.4789: udp 106
    
    <<<<1
    15:00:01.438256 SPOKES_VXLAN in 192.168.1.2 -&gt; 192.168.1.1: icmp: echo request
    <<<<2
    15:00:01.438260 port1 out 192.168.1.2 -&gt; 192.168.1.1: icmp: echo request
    <<<<3
    15:00:01.438532 port1 in 192.168.1.1 -&gt; 192.168.1.2: icmp: echo reply
    15:00:01.438536 SPOKES_VXLAN out 192.168.1.1 -&gt; 192.168.1.2: icmp: echo reply
    15:00:01.438546 SPOKES out 192.168.255.1.4851 -&gt; 192.168.255.2.4789: udp 106