Chapter 15 – IPv6

Leave a reply

Chapter 15 – IPv6

The origins of Internet Protocol Version 6 (IPv6) date back to December 1998 with the publication of RFC 2460, which describes IPv6 as the successor to IPv4, the standard communications protocol still in use by the majority of users today. This transition away from IPv4 was a direct response to the foreseeable exhaustion of 32-bit IPv4 addresses, which are virtually all but assigned—all 4.3 billion.

IPv4 uses 32-bit addresses, which means that there is a theoretical address limit of 2 to the power of 32. The IPv6 address scheme is based on a 128-bit address, resulting in a theoretical address limit of 2 to the power of 128.

 

Possible addresses:

IPv4 = Roughly 4.3 billion

IPv6 = Over 340 undecillion (340 followed by 36 digits)

Assuming a world population of approximately 8 billion people, IPv6 would allow for each individual to have approximately 42,535,295,865,117,200,000, 000,000,000 devices with an IP address. That’s 42 quintillion devices, so it’s unlikely that we will ever need to worry about the availability of IPv6 addresses.

Aside from the difference of possible addresses, there is also the different formatting of the addresses. A computer would view an IPv4 address as a 32-bit string of binary digits made up of 1s and 0s, broken up into 4 octets of 8 digits separated by a period: 10101100.00010000.11111110.00000001

To make the number more user-friendly, we translate the address into decimal, again 4 octets separated by a period: 172.16.254.1

A computer would view an IPv6 address as a 128-bit string of binary digits made up of 1s and 0s, broken up into 8 octets of 16 digits separated by a colon: 0010000000000001:0000110110111:0000000000000000:000000000000010:0000000000000000:000000000

0000000:0000000000000000:0000000000100000

To make this number a little more user-friendly, we translate it into hexadecimal, again 8 octets separated by a colon, for example: 2001:0db8:0000:0002:0000:0000:0000:0020

We can further simplify the above address. Because any four-digit group of zeros within an IPv6 address may be reduced to a single zero or altogether omitted, the above address can be reduced to: 2001:0db8:0000:0002:0:0:0:20 or 2001:db8:0:2::20

 

IPv6 packet structure

Each IPv6 packet consists of a mandatory fixed header and optional extension headers, and carries a payload, which is typically either a datagram and/or Transport Layer information. The payload could also contain data for the Internet Layer or Link Layer. Unlike IPv4, IPv6 packets aren’t fragmented by routers, requiring hosts to implement Maximum Transmission Unit (MTU) Path Discovery for MTUs larger than the smallest MTU (which is 1280 octets).

 

Jumbograms and jumbo payloads

In IPv6, packets which exceed the MTU of the underlying network are labelled jumbograms, which consist of a jumbo payload. A jumbogram typically exceeds the IP MTU size limit of 65,535 octets, and provides the jumbo payload option, which can allow up to nearly 4GiB of payload data, as defined in RFC 2675. When the MTU is determined to be too large, the receiving host sends a ‘Packet too Big’ ICMPv6 type 2 message to the sender.

 

Fragmentation and reassembly

As noted, packets that are too large for the MTU require hosts to perform MTU Path Discovery to determine the maximum size of packets to send. Packets that are too large require a ‘Fragment’ extension header, to divide the payload into segments that are 8 octets in length (except for the last fragment, which is smaller). Packets are reassembled according to the extension header and the fragment offset.

 

Benefits of IPv6

Some of the benefits of IPv6 include:

  • More efficient routing
  • Reduced management requirement
  • Stateless auto-reconfiguration of hosts
  • Improved methods to change Internet Service Providers
  • Better mobility support
  • Multi-homing
  • Security
  • Scoped address: link-local, site-local, and global address space

 

What‘s new in FortiOS 5.4

 

DHCPv6 server is configurable in delegated mode (295007)

Downstream IPv6 interfaces can receive address assignments on delegated subnets from a DHCP server that serves an upstream interface.

 

DHCPv6-PD configuration

Enable DHCPv6 Prefix Delegation on upstream interface (port10):

config system interface

end

edit “port10” config ipv6

set dhcp6-prefix-delegation enable end

 

Assign delegated prefix on downstream interface (port1). Optionally, specific delegated prefixes can be specified:

 

config system interface edit “port1”

config ipv6

set ip6-mode delegated

set ip6-upstream-interface “port10” set ip6-subnet ::1:0:0:0:1/64

set ip6-send-adv enable

config ipv6-delegated-prefix-list edit 1

set upstream-interface “port10” set autonomous-flag enable

set onlink-flag enable

set subnet 0:0:0:100::/64 end

end end

 

DHCPv6 Server configuration

Configuring a server that uses delegated prefix and DNS from upstream:

 

config system dhcp6 server edit 1

set dns-service delegated set interface “wan2”

set upstream-interface “wan1” set ip-mode delegated

set subnet 0:0:0:102::/64 end

 

FortiGate can connect to FortiAnalyzer using IPv6 addresses (245620)

When configuring your FortiGate to send logs to a FortiAnalyzer you can specify an IPv4 or an IPv6 address.

 

IPv6 neighbor discovery limits changes(248076)

You can use the following command to configure the maximum number of IPv6 neighbors that can be discovered by the IPv6 Neighbor Discovery Protocol (NDP) and added to the IPv6 neighbor database.

 

config system global

set ndp-max-entry <integer>

end

The number of entries can be in the range 65,536 to 2,147,483,647. The default value of 0 means 65,536 entries.

 

Support IPv6 blackhole routing (220101)

Similar to IPv4 blackhole routing, IPv6 blackhole routing is now supported. Use the following command to enable IPv6 blackhole routing:

 

config router static6 edit 1

set blackhole enable/disable next

end

 

TFTP session helper for IPv6 (263127)

FTP is supported over nat66 and nat46.

 

FTP, PPTP and RTSP session helper enhancements for IPv6 (244986)

The FTP, PPTP and RTSP session helpers support NAT-64 customer-side translator (CLAT) sessions.

 

Central Management ratings and update servers can use IPv6 addresses (297144)

You can configure servers for Central Management using either IPv4 or IPv6 addresses. The addr-type field sets the address type. The address is entered in the server-address or server-address6 field as appropriate.

 

config system central-management set type fortimanager

set fmg “2000:172:16:200::207” set vdom “vdom1”

config server-list edit 1

set server-type rating update set addr-type ipv6

set server-address6 2000:172:16:200::207 end

end

 

Allow asymmetric routing for ICMP (258734)

Where network topology requires asymmetric routing for ICMP traffic, you can configure the FortiGate to permit the asymmetric ICMP traffic. This is done in the CLI. There are separate fields for IPv4 and IPv6 versions of ICMP.

 

config system settings

set asymroute-icmp enable set asymroute-icmp6 enable

end

 


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

VPN troubleshooting tips

Leave a reply

VPN troubleshooting tips

More in-depth VPN troubleshooting can be found in the Troubleshooting guide.

 

Attempting hardware offloading beyond SHA1

If you are trying to off-load VPN processing to a network processing unit (NPU), remember that only SHA1 authentication is supported. For high levels of authentication such as SHA256, SHA384, and SHA512 hardware offloading is not an option — all VPN processing must be done in software.

 

Enable/disable IPsec ASIC-offloading

Much like NPU-offload in IKE phase1 configuration, you can enable or disable the usage of ASIC hardware for IPsec Diffie-Hellman key exchange and IPsec ESP traffic. By default hardware offloading is used. For debugging purposes, sometimes it is best for all the traffic to be processed by software.

config sys global

set ipsec-asic-offload [enable | disable]

end

 

Check Phase 1 proposal settings

Ensure that both sides have at least one Phase 1 proposal in common. Otherwise they will not connect. If there are many proposals in the list, this will slow down the negotiating of Phase 1. If its too slow, the connection may timeout before completing. If this happens, try removing some of the unused proposals.

NPU offloading is supported when the local gateway is a loopback interface.

 

Check your routing

If routing is not properly configured with an entry for the remote end of the VPN tunnel, traffic will not flow properly. You may need static routes on both ends of the tunnel. If routing is the problem, the proposal will likely setup properly but no traffic will flow.

 

Try enabling XAuth

If one end of an attempted VPN tunnel is using XAuth and the other end is not, the connection attempt will fail. The log messages for the attempted connection will not mention XAuth is the reason, but when connections are failing it is a good idea to ensure both ends have the same XAuth settings. If you do not know the other end’s settings enable or disable XAuth on your end to see if that is the problem.

 

General troubleshooting tips

Most connection failures are due to a configuration mismatch between the FortiGate unit and the remote peer. In general, begin troubleshooting an IPsec VPN connection failure as follows:

1. Ping the remote network or client to verify whether the connection is up. See General troubleshooting tips on page 1831.

2. Traceroute the remote network or client. If DNS is working, you can use domain names. Otherwise use IP addresses.

3. Check the routing behind the dialup client. Routing problems may be affecting DHCP. If this appears to be the case, configure a DHCP relay service to enable DHCP requests to be relayed to a DHCP server on or behind the FortiGate server.

4. Verify the configuration of the FortiGate unit and the remote peer. Check the following IPsec parameters:

  • The mode setting for ID protection (main or aggressive) on both VPN peers must be identical.
  • The authentication method (preshared keys or certificates) used by the client must be supported on the FortiGate unit and configured properly.
  • If preshared keys are being used for authentication purposes, both VPN peers must have identical preshared keys.
  • The remote client must have at least one set of Phase 1 encryption, authentication, and Diffie-Hellman settings that match corresponding settings on the FortiGate unit.
  • Both VPN peers must have the same NAT traversal setting (enabled or disabled).
  • The remote client must have at least one set of Phase 2 encryption and authentication algorithm settings that match the corresponding settings on the FortiGate unit.
  • If you are using manual keys to establish a tunnel, the Remote SPI setting on the FortiGate unit must be identical to the Local SPI setting on the remote peer, and vise versa.

5. To correct the problem, see the following table.

 

VPN trouble-shooting tips

Configuration problem           Correction

Mode settings do not match.

Select complementary mode settings. See Phase 1 parameters on page 1624.

 

Peer ID or certificate name of the remote peer or dia- lup client is not recognized by FortiGate VPN server.

Check Phase 1 configuration. Depending on the Remote Gateway and Authentication Method settings, you have a choice of options to authen- ticate FortiGate dialup clients or VPN peers by ID or certificate name (see Phase 1 parameters on page 1624).

If you are configuring authentication parameters for FortiClient dialup cli- ents, refer to the Authenticating FortiClient Dialup Clients Technical Note.
Preshared keys do not match.

Reenter the preshared key. See Phase 1 parameters on page 1624.

 

Phase 1 or Phase 2 key exchange proposals are mismatched.

Make sure that both VPN peers have at least one set of proposals in com- mon for each phase. See Phase 1 parameters on page 1624 and Phase 2 parameters on page 1642.
NAT traversal settings are mismatched.

Select or clear both options as required. See Phase 1 parameters on page 1624 and Phase 1 parameters on page 1624.

 

A word about NAT devices

When a device with NAT capabilities is located between two VPN peers or a VPN peer and a dialup client, that device must be NAT traversal (NAT-T) compatible for encrypted traffic to pass through the NAT device. For more information, see Phase 1 parameters on page 1624.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Logging VPN events

Leave a reply

Logging VPN events

You can configure the FortiGate unit to log VPN events. For IPsec VPNs, Phase 1 and Phase 2 authentication and encryption events are logged. For information about how to interpret log messages, see the FortiGate Log Message Reference.

 

To log VPN events

1. Go to Log & Report > Log Settings.

2. Verify that the VPN activity event option is selected.

3. Select Apply.

 

To view event logs

1. Go to Log & Report > VPN Events.

2. Select the Log location.

 

Sending tunnel statistics to FortiAnalyzer

By default, logged events include tunnel-up and tunnel-down status events. Other events, by default, will appear in the FortiAnalyzer report as “No Data Available”. More accurate results require logs with action=tunnel- stats, which is used in generating reports on the FortiAnalyzer (rather than the tunnel-up and tunnel-down event logs). The FortiGate does not, by default, send tunnel-stats information.

To allow VPN tunnel-stats to be sent to FortiAnalyzer, configure the FortiGate unit as follows using the CLI:

config system settings

set vpn-stats-log ipsec ssl set vpn-stats-period 300

end

 

This section contains tips to help you with some common challenges of IPsec VPNs.

A VPN connection has multiple stages that can be confirmed to ensure the connection is working properly. It is easiest to see if the final stage is successful first since if it is successful the other stages will be working properly. Otherwise, you will need to work back through the stages to see where the problem is located.

When a VPN connection is properly established, traffic will flow from one end to the other as if both ends were physically in the same place. If you can determine the connection is working properly then any problems are likely problems with your applications.

On some FortiGate units, such as the FortiGate 94D, you cannot ping over the IPsec tunnel without first setting a source-IP. In this scenario, you must assign an IP address to the virtual IPSEC VPN interface. Anything sourced from the FortiGate going over the VPN will use this IP address.

If the egress/outgoing interface (determined by kernel route) has an IP address, then use the IP address of the egress/outgoing interface. Otherwise, use the IP address of the first interface from the interface list (that has an IP address).

The first diagnostic command worth running, in any IPsec VPN troubleshooting situation, is the following:

diagnose vpn tunnel list

 

This command is very useful for gathering statistical data such as the number of packets encrypted versus decrypted, the number of bytes sent versus received, the SPI identifier, etc. This kind of information in the resulting output can make all the difference in determining the issue with the VPN.

Another appropriate diagnostic command worth trying is:

diagnose debug flow

This command will inform you of any lack of firewall policy, lack of forwarding route, and of policy ordering issues. The following is a list of such potential issues. Bear in mind that the troubleshooting suggestions below are not

exhaustive, and may not reflect your network topology.

 

The options to configure policy-based IPsec VPN are unavailable.

Go to System > Feature Select. Select Show More and turn on Policy-based IPsec VPN.

 

The VPN connection attempt fails.

If your VPN fails to connect, check the following:

  • Ensure that the pre–shared keys match exactly (see The pre-shared key does not match (PSK mismatch error). below).
  • Ensure that both ends use the same P1 and P2 proposal settings (seeThe SA proposals do not match (SA proposal mismatch). below).
  • Ensure that you have allowed inbound and outbound traffic for all necessary network services, especially if services such as DNS or DHCP are having problems.
  • Check that a static route has been configured properly to allow routing of VPN traffic.
  • Ensure that your FortiGate unit is in NAT/Route mode, rather than Transparent.
  • Check your NAT settings, enabling NAT traversal in the Phase 1 configuration while disabling NAT in the security policy. You might need to pin the PAT/NAT session table, or use some of kind of NAT-T keepalive to avoid the expiration of your PAT/NAT translation.
  • Ensure that both ends of the VPN tunnel are using Main mode, unless multiple dial-up tunnels are being used.
  • If you have multiple dial-up IPsec VPNs, ensure that the Peer ID is configured properly on the
  • FortiGate and that clients have specified the correct Local ID.
  • If you are using FortiClient, ensure that your version is compatible with the FortiGate firmware by reading the FortiOS Release Notes.
  • If you are using Perfect Forward Secrecy (PFS), ensure that it is used on both peers. You can use the diagnose vpn tunnel list command to troubleshoot this.
  • Ensure that the Quick Mode selectors are correctly configured. If part of the setup currently uses firewall addresses or address groups, try changing it to either specify the IP addresses or use an expanded address range. This is especially useful if the remote endpoint is not a FortiGate device.
  • If XAUTH is enabled, ensure that the settings are the same for both ends, and that the FortiGate unit is set to Enable as Server.
  • Check IPsec VPN Maximum Transmission Unit (MTU) size. A 1500 byte MTU is going to exceed the overhead of the ESP-header, including the additional ip_header,etc. You can use the diagnose vpn tunnel list command to troubleshoot this.
  • If your FortiGate unit is behind a NAT device, such as a router, configure port forwarding for UDP ports 500 and 4500.
  • Remove any Phase 1 or Phase 2 configurations that are not in use. If a duplicate instance of the VPN tunnel appears on the IPsec Monitor, reboot your FortiGate unit to try and clear the entry.

 

If you are still unable to connect to the VPN tunnel, run the following diagnostic command in the CLI:

diagnose debug application ike -1 diagnose debug enable

The resulting output may indicate where the problem is occurring. When you are finished, disable the diagnostics by using the following command:

diagnose debug reset diagnose debug disable

 

The VPN tunnel goes down frequently.

If your VPN tunnel goes down often, check the Phase 2 settings and either increase the Keylife value or enable Autokey Keep Alive.

 

The pre-shared key does not match (PSK mismatch error).

It is possible to identify a PSK mismatch using the following combination of CLI commands:

diag vpn ike log filter name <phase1-name>

diag debug app ike -1 diag debug enable

 

This will provide you with clues as to any PSK or other proposal issues. If it is a PSK mismatch, you should see something similar to the following output:

ike 0:TRX:322: PSK auth failed: probable pre-shared key mismatch

ike Negotiate SA Error:

 

The SA proposals do not match (SA proposal mismatch).

The most common problem with IPsec VPN tunnels is a mismatch between the proposals offered between each party. Without a match and proposal agreement, Phase 1 can never establish. Use the following command to show the proposals presented by both parties.

 

diag debug app ike -1 diag debug enable

 

The resulting output should include something similar to the following, where blue represents the remote VPN device, and green represents the local FortiGate.

 

responder received SA_INIT msg incoming proposal:

proposal id = 1:

protocol = IKEv2:

encapsulation = IKEv2/none

type=ENCR, val=AES_CBC (key_len = 256) type=INTEGR, val=AUTH_HMAC_SHA_96 type=PRF, val=PRF_HMAC_SHA type=DH_GROUP, val=1536.

proposal id = 2:

protocol = IKEv2:

encapsulation = IKEv2/none type=ENCR, val=3DES_CBC

type=INTEGR, val=AUTH_HMAC_SHA_2_256_128 type=PRF, val=PRF_HMAC_SHA2_256 type=DH_GROUP, val=1536.

proposal id = 1:

protocol = IKEv2:

encapsulation = IKEv2/none

type=ENCR, val=AES_CBC (key_len = 128) type=INTEGR, val=AUTH_HMAC_SHA_96 type=PRF, val=PRF_HMAC_SHA type=DH_GROUP, val=1536.

 

Pre–existing IPsec VPN tunnels need to be cleared.

Should you need to clear an IKE gateway, use the following commands:

diagnose vpn ike restart diagnose vpn ike gateway clear

 

LAN interface connection

To confirm whether a VPN connection over LAN interfaces has been configured correctly, issue a ping or traceroute command on the network behind the FortiGate unit to test the connection to a computer on the remote network. If the connection is properly configured, a VPN tunnel will be established automatically when the first data packet destined for the remote network is intercepted by the FortiGate unit.

If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not indicate problems with the VPN tunnel. You can confirm this by going to Monitor > IPsec Monitor where you will be able to see your connection. A green arrow means the tunnel is up and currently processing traffic. A red arrow means the tunnel is not processing traffic, and this VPN connection has a problem.

If the connection has problems, see Troubleshooting VPN connections on page 1829.

 

Dialup connection

A dialup VPN connection has additional steps. To confirm that a VPN between a local network and a dialup client has been configured correctly, at the dialup client, issue a ping command to test the connection to the local network. The VPN tunnel initializes when the dialup client attempts to connect.

If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not indicate problems with the VPN tunnel, or dialup client. As with the LAN connection, confirm the VPN tunnel is established by checking Monitor > IPsec Monitor.

 

Troubleshooting VPN connections

If you have determined that your VPN connection is not working properly through Troubleshooting on page 1826, the next step is to verify that you have a phase2 connection.

If traffic is not passing through the FortiGate unit as you expect, ensure the traffic does not contain IPcomp packets (IP protocol 108, RFC 3173). FortiGate units do not allow IPcomp packets, they compress packet payload, preventing it from being scanned.

Testing Phase 1 and 2 connections is a bit more difficult than testing the working VPN. This is because they require diagnose CLI commands. These commands are typically used by Fortinet customer support to discover more information about your FortiGate unit and its current configuration.

 

Before you begin troubleshooting, you must:

  • Configure FortiGate units on both ends for interface VPN
  • Record the information in your VPN Phase 1 and Phase 2 configurations – for our example here the remote IP address is 10.11.101.10 and the names of the phases are Phase 1 and Phase 2
  • Install a telnet or SSH client such as putty that allows logging of output
  • Ensure that the admin interface supports your chosen connection protocol so you can connect to your FortiGate unit admin interface.

 

For this example, default values were used unless stated otherwise.

 

To get diagnose information for the VPN connection – CLI

1. Log into the CLI as admin with the output being logged to a file.

2. Stop any diagnose debug sessions that are currently running with the CLI command diagnose debug disable

3. Clear any existing log-filters by running

diagnose vpn ike log-filter clear

4. Set the log-filter to the IP address of the remote computer (10.11.101.10). This filters out all VPN connections except ones to the IP address we are concerned with. The command is

diagnose vpn ike log-filter dst-addr4 10.11.101.10.

5. Set up the commands to output the VPN handshaking. The commands are:

diagnose debug app ike 255

diagnose debug enable

6. Have the remote FortiGate initiate the VPN connection in the web-based manager by going to VPN > IPsec Tunnels and selecting Bring up.

 

This makes the remote FortiGate the initiator and the local FortiGate becomes the responder. Establishing the connection in this manner means the local FortiGate will have its configuration information as well as the information the remote computer sends. Having both sets of information locally makes it easier to troubleshoot your VPN connection.

7. Watch the screen for output, and after roughly 15 seconds enter the following CLI command to stop the output.

diagnose debug disable

8. If needed, save the log file of this output to a file on your local computer. Saving the output to a file can make it easier to search for a particular phrase, and is useful for comparisons.

 

To troubleshoot a phase1 VPN connection

Using the output from To get diagnose information for the VPN connection – CLI on page 1829, search for the word proposal in the output. It may occur once indicating a successful connection, or it will occur two or more times for an unsuccessful connection — there will be one proposal listed for each end of the tunnel and each possible combination in their settings. For example if 10.11.101.10 selected both Diffie-Hellman Groups 1 and 5, that would be at least 2 proposals set.

 

A successful negotiation proposal will look similar to

IPsec SA connect 26 10.12.101.10->10.11.101.10:500 config found

created connection: 0x2f55860 26 10.12.101.10->10.11.101.10:500

IPsec SA connect 26 10.12.101.10->10.11.101.10:500 negotiating

no suitable ISAKMP SA, queuing quick-mode request and initiating ISAKMP SA negotiation initiator: main mode is sending 1st message…

cookie 3db6afe559e3df0f/0000000000000000 out [encryption]

sent IKE msg (ident-i1send): 10.12.101.10:500->10.11.101.10:500, len=264, id=3db6afe559e3df0f/0000000000000000

diaike 0: comes 10.12.101.1:500->10.11.101.1:500,ifindex=26….

 

Note the phrase “initiator: main mode is sending 1st message…” which shows you the handshake between the ends of the tunnel is in progress. Initiator shows the remote unit is sending the first message.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Monitoring VPN connections

Leave a reply

This section provides some general logging and monitoring procedures for VPNs. The following topics are included in this section:

  • Monitoring VPN connections
  • Logging VPN events

 

Monitoring VPN connections

You can use the monitor to view activity on IPsec VPN tunnels and to start or stop those tunnels. The display provides a list of addresses, proxy IDs, and timeout information for all active tunnels.

 

Monitoring connections to remote peers

The list of tunnels provides information about VPN connections to remote peers that have static IP addresses or domain names. You can use this list to view status and IP addressing information for each tunnel configuration. You can also start and stop individual tunnels from the list.

To view the list of static-IP and dynamic-DNS tunnels go to Monitor > IPsec Monitor.

 

Monitoring dialup IPsec connections

The list of dialup tunnels provides information about the status of tunnels that have been established for dialup clients. The list displays the IP addresses of dialup clients and the names of all active tunnels. The number of tunnels shown in the list can change as dialup clients connect and disconnect.

To view the list of dialup tunnels go to Monitor > IPsec Monitor.

If you take down an active tunnel while a dialup client such as FortiClient is still connected, FortiClient will continue to show the tunnel connected and idle. The dialup client must disconnect before another tunnel can be initiated.

 

The list of dialup tunnels displays the following statistics:

  • The Name column displays the name of the tunnel.
  • The meaning of the value in the Remote gateway column changes, depending on the configuration of the network at the far end:
  • When a FortiClient dialup client establishes a tunnel, the Remote gateway column displays either the public IP address and UDP port of the remote host device (on which the FortiClient Endpoint Security application is installed), or if a NAT device exists in front of the remote host, the Remote gateway column displays the public IP address and UDP port of the remote host.
  • When a FortiGate dialup client establishes a tunnel, the Remote gateway column displays the public IP address and UDP port of the FortiGate dialup client.
  • The Username column displays the peer ID, certificate name, or XAuth user name of the dialup client (if a peer ID, certificate name, or XAuth user name was assigned to the dialup client for authentication purposes).
  • The Timeout column displays the time before the next key exchange. The time is calculated by subtracting the time elapsed since the last key exchange from the keylife.
  • The Proxy ID Source column displays the IP addresses of the hosts, servers, or private networks behind the FortiGate unit. A network range may be displayed if the source address in the security encryption policy was expressed as a range of IP addresses.
  • The meaning of the value in the Proxy ID Destination column changes, depending on the configuration of the network at the far end:
  • When a FortiClient dialup client establishes a tunnel:
  • If VIP addresses are not used and the remote host connects to the Internet directly, the Proxy ID Destination field displays the public IP address of the Network Interface Card (NIC) in the remote host.
  • If VIP addresses are not used and the remote host is behind a NAT device, the Proxy ID Destination field displays the private IP address of the NIC in the remote host.
  • If VIP addresses were configured (manually or through FortiGate DHCP relay), the Proxy ID Destination field displays either the VIP address belonging to a FortiClient dialup client, or a subnet address from which VIP addresses were assigned.
  • When a FortiGate dialup client establishes a tunnel, the Proxy ID Destination field displays the IP address of the remote private network.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

IPsec Auto-Discovery VPN (ADVPN)

Leave a reply

IPsec Auto-Discovery VPN (ADVPN)

Consider a company that wants to provide direct secure (IPsec) connections between all of its offices in New York, Chicago, Greenwich, London, Paris, Frankfurt, Tokyo, Shanghai, and Hong Kong.

A straightforward solution is to create a full mesh of connections such that every site has eight IPsec configurations, one for each of the other sites. If there were ninety sites, that could still be done but now the configuration is becoming tedious, since every time a new site is added, N-1 other sites have to have their configuration updated.

An efficient and secure alternative is IPsec Auto-Discovery VPN (ADVPN), which allows a minimum amount of configuration per site but still allows direct IPsec connections to be made between every site. RFC 7018 essentially describes this problem, along with some requirements for candidate solutions.

The ADVPN solution involves partitioning the sites into spokes and hubs such that a spoke has to have enough IPsec configuration to enable it to connect to at least one hub. A hub does not have specific configuration for each spoke, so the amount of configuration does not grow with the number of spokes that are connected to that hub. A hub to hub connection would typically involve both hubs having configuration for each other.

So, one possible partition for the original nine sites would be that Chicago and Greenwich would be spokes for the New York hub, Paris and Frankfurt would be spokes for the London hub, and Tokyo and Hong Kong would be spokes for the Shanghai hub:

ipsec-auto-discovery

 

Once a spoke has established a connection to its hub then initially IPsec traffic to another site transits via one or more hubs. For example, traffic from Chicago to Hong Kong would transit via the New York and Shanghai hubs. This transit traffic then triggers an attempt to create a more direct connection.

 

In FortiOS:

  • Direct connections are only created between the two endpoints that want to exchange traffic (e.g. Chicago and Hong Kong); we do not create intermediate connections  say Chicago to Shanghai, or New York to Hong Kong) as a side-effect.
  • Learning the peer subnets is done via a dynamic routing protocol running over the IPsec connections.
  • Negotiation of the direct connections is done via IKE.
  • Both PSK and certificate authentication is supported.

 

Example ADVPN configuration

Since dynamic routing with IPsec under FortiOS requires that an interface have an IP address, then for every site a unique IP address from some unused range is allocated. For example we’ll assume that 10.100.0.0/16 is unused and so assign the IP addresses:

  • Chicago 10.100.0.4
  • Greenwich 10.100.0.5
  • New York 10.100.0.1
  • London 10.100.0.2
  • Shanghai 10.100.0.3
  • Paris 10.100.0.6
  • Frankfurt 10.100.0.7
  • Hong Kong 10.100.0.8
  • Tokyo 10.100.0.9

We’ll assume that each site has one or more subnets that it protects that it wants to make available to the peers. For the purposes of exposition we’ll assume there is only one subnet per site and they are allocated as:

  • Chicago 10.0.4.0/16
  • Greenwich 10.0.5.0/24
  • New York 10.0.1.0/24
  • London 10.0.2.0/24
  • Shanghai 10.0.3.0/24
  • Paris 10.0.6.0/24
  • Frankfurt 10.0.7.0/24
  • Hong Kong 10.0.8.0/24
  • Tokyo 10.0.9.0/24

Our example network topology now looks like this:

greenwich

 

The configuraton in Chicago would be as follows:

 

config vpn ipsec phase1-interface edit “New York”

set type static

set interface wan1

set remote-gw <New-York-IP-address>

set psk <New-York-PSK>

set auto-discovery-receiver enable next

end

 

The attribute auto-discovery-receiver indicates that this IPsec tunnel wishes to participate in an auto- discovery VPN. The IPsec interface would then have its IP assigned according to the Chicago address:

config system interface edit “New York”

set ip 10.100.0.4/32

set remote-ip 10.100.0.1 next

end

 

RIP (for simplicity, you could use OSPF or BGP) is then configured to run on the IPsec interface and on the Chicago subnet (you could use redistribute connected, but we’ll allow for the fact that there may be other subnets learned from another router on the 10.0.4.0/24 subnet):

config router rip

edit 1

set prefix 10.100.0.0/16 next

edit 2

set prefix 10.0.4.0/24 next

end

 

Other than the firewall policy and a minimal phase 2 configuration, this concludes the configuration for Chicago.

 

Each spoke would have a similar configuration.

The New York hub would have a dynamic phase 1 for its spoke connections, and two static phase 1s for its connections to the other hubs:

config vpn ipsec phase1-interface edit “Spokes”

set type dynamic set interface wan1

set psk <New-York-PSK>

set auto-discovery-sender enable set auto-discovery-psk enable

set add-route disable next

edit “London”

set type static

set interface wan1

set psk <New-York-London-PSK>

set auto-discovery-forwarder enable next

edit “Shanghai”

set type static

set interface wan1

set psk <New-York-Shanghai-PSK>

set auto-discovery-forwarder enable next

end

 

The ‘Spokes’ connection has set auto-discovery-sender enable to indicate that when IPsec traffic transits the hub it should optionally generate a message to the initiator of the traffic to indicate that it could perhaps establish a more direct connection. The set add-route disable ensures that IKE does not automatically add a route back over the spoke and instead leaves routing to a separately configured routing protocol.

The two inter-hub connections have set auto-discovery-forwarder enable to indicate that these connections can participate in the auto-discovery process. The interface IP addresses are assigned:

config system interface edit “Spokes”

set ip 10.100.0.1/32

set remote-ip 10.100.0.254 next

edit “London”

set ip 10.100.0.1/32

set remote-ip 10.100.0.2 next

edit “London”

set ip 10.100.0.1/32

set remote-ip 10.100.0.3 next

end

 

Following this, RIP is enabled on the relevant interfaces:

config router rip edit 1

set prefix 10.100.0.0/16 next

edit 2

set prefix 10.0.1.0/24 next

end

 

A similar configuration would be used on the other two hubs.

 

Traffic flow and tunnel connection

With the configuration in place at all spokes and hubs, assuming all the spokes are connected to a hub, then Chicago would learn (via RIP) that the route to the Hong Kong subnet 10.0.8.0/24 is via its “New York” interface. If a device on the Chicago protected subnet (say 10.0.4.45) attempted to send traffic to the Hong Kong proected subnet (say 10.0.8.13) then it should flow over the New York interface to New York, which should then transmit it over the Shanghai tunnel to Shanghai, which should then send it over the dynamically negotiated Hong Kong tunnel to Hong Kong.

At the point when the traffic transits New York it should notice that the Chicago Spoke tunnel and the Shanghai tunnel have auto-discovery enabled, causing the New York hub to send a message via IKE to Chicago informing it that it may want to try and negotiate a direct connection for traffic from 10.0.4.45 to 10.0.8.13.

On receipt of this message, IKE on Chicago creates the (FortiOS-specific) IKE INFORMATIONAL SHORTCUT- QUERY message which contains the Chicago public IP address, the source IP of the traffic (10.0.4.45), the desired destination IP (10.0.8.13), and the PSK that should be used to secure any direct tunnel (if certificates are confgured, it is assumed that they all share the same CA and so no additional authentication information is required). This message is sent via IKE to New York since routing indicates that New York is the best route to 10.0.8.13.

On receipt of the IKE INFORMATIONAL query, New York checks its routing table to see who owns 10.0.8.13. It finds that 10.0.8.13 should be routed via Shanghai, and since Shanghai is marked as an auto-discovery-forwarder then the query is forwarded.

Shanghai repeats the process, finds that 10.0.8.13 should be routed via its Hong Kong Spoke and so sends it to Hong Kong. Hong Kong checks 10.0.8.13, finds that it owns the subnet, so it remembers the Chicago public IP address (and PSK) and creates an IKE INFORMATIONAL reply message containing its external IP address. To work out where to send the IKE message, the FortiGate does a routing lookup for the original source IP (10.0.4.45), determines that the message should be routed via its Shanghai tunnel and so sends the reply back to Shanghai. The reply then makes its way back to Chicago following the reverse of the path that it used to arrive at Hong Kong.

When the reply makes it back to the Chicago initator then it now knows the IP address of the Hong Kong device. Chicago now creates a new dynamic tunnel with the remote gateway as the Hong Kong public IP address and initiates an IKE negotiation (the dynamic tunnel nameis auto-generated from the tunnel over which it performed the query; in this case it would be called ‘New York_0’).

This negotiation should succeed since Hong Kong is set up to expect an attempted negotiation from the Chicago public IP address. Once the negotiation succeeds, RIP will start to run on the newly created tunnels at Chicago and Hong Kong. This will update the routing on Chicago (and Hong Kong) so that the prefered route to 10.0.8.0 (10.0.4.0) is via the newly created tunnel rather than via the connection to New York (Shanghai).

 

Notes about ADVPN in FortiOS

  • Auto-discovery is only supported by IKEv1.
  • All Spokes must have an IP address that is routable from any other spoke; devices behind NAT are not currently supported.
  • The feature requires the use of a dynamic routing protocol. There is no support for IKE handling routing.
  • RIP is not a very scalable routing protocol. When there are more than a few spokes it would be advisable to use route summarization to avoid huge RIP updates. Better yet, use BGP instead of RIP.
  • It is assumed that spokes will not be used to transit other spoke traffic, for example: traffic from Chicago to Tokyo would not transit an existing Chicago to Hong Kong tunnel even though that has a shorter hop count than a route via New York and Shanghai.
  • There is no facility to allow you to filter which traffic that transits the hub should trigger the message sent to the initiator suggesting it create a direct connection. Currently any and all traffic will trigger it.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

BGP over dynamic IPsec

Leave a reply

BGP over dynamic IPsec

This example shows how to create a dynamic IPsec VPN tunnel that allows BGP.

 

Configuring IPsec on FortiGate 1

1. Go to Policy & Objects > Addresses and select create new Address.

Name                                                Remote_loop_int

Type                                                 Subnet

Subnet/IP Range                             10.10.10.10

Interface                                           any

2. Create an Address Group.

Group Name                                    VPN_DST

Show in Address List                    enable

Members                                          Remote_loop_int all

3. Go to Dashboard and enter the CLI Console widget.

4. Create phase 1:

config vpn ipsec phase1-interface edit Dialup

set type dynamic set interface wan1 set mode aggressive set peertype one

set mode-cfg enable

set proposal 3des-sha1 aes128-sha1 set peerid dial

set assign-ip disable set psksecret

next end

5. Create phase 2:

config vpn ipsec phase2-interface edit dial_p2

set phase1name Dialup

set proposal 3des-sha1 aes128-sha1 set src-addr-type name

set dst-addr-type name set src-name all

set dst-name VPN_DST

next

end

 

Configuring BGP on FortiGate 1

1. Go to Network > Interfaces and create a Loopback interface.

2. Set IP/Network Mask to 20.20.20.20/255.255.255.255.

3. Go to Dashboard and enter the CLI Console widget.

4. Create a BGP route.

config router bgp set as 100

set router-id 1.1.1.1 config neighbor

edit 10.10.10.10

set ebgp-enforce-multihop enable set remote-as 200

set update-source loop next

end

config redistribute connected set status enable

end

end

 

Adding policies on FortiGate 1

1. Go to Policy & Objects > IPv4 Policy and create a policy allowing BGP traffic from Dialup to loop interfaces.

2. Go to Policy & Objects > IPv4 Policy and create a policy allowing BGP traffic from loop to Dialup interfaces.

 

Configuring IPsec on FortiGate 2

1. Go to Dashboard and enter the CLI Console widget.

2. Create phase 1:

config vpn ipsec phase1-interface edit Dialup

set interface wan1 set mode aggressive set mode-cfg enable

set proposal 3des-sha1 aes128-sha1 set localid dial

set remote-gw 172.20.120.22 set assign-ip disable

set psksecret next

end

3. Create phase 2:

config vpn ipsec phase2-interface edit dial_p2

set phase1name Dialup

set proposal 3des-sha1 aes128-sha1 set keepalive enable

next end

 

BGP over dynamic IPsec

 

Configuring BGP on FortiGate 2

1. Go to Network > Interfaces and create a Loopback interface.

2. Set IP/Network Mask to 10.10.10.10/255.255.255.255.

3. Go to Dashboard and enter the CLI Console widget.

4. Create a BGP route.

config router bgp set as 200

set router-id 1.1.1.2 config neighbor

edit 20.20.20.20

set ebgp-enforce-multihop enable set remote-as 100

set update-source loop next

end

config redistribute connected set status enable

end

end

 

Adding policies on FortiGate 2

1. Go to Policy & Objects > IPv4 Policy and create a policy allowing BGP traffic from Dialup to loop interfaces.

2. Go to Policy & Objects > IPv4 Policy and create a policy allowing BGP traffic from loop to Dialup interfaces.

 

Adding a static route on FortiGate 2

Go to Network > Static Routes and add a route to the remote Loopback interface via Dialup interface.

Destination IP/Mask                       20.20.20.20/255.255.255.255

Device                                              Dialup

Administrative Distance                10

 

Verifying the tunnel is up

Go to Monitor > IPsec Monitor to verify that the tunnel is Up.

 

Results

1. From FortiGate 1, go to Monitor > Routing Monitor and verify that routes from FortiGate 2 were successfully advertised to FortiGate 1 via BGP.

2. From FortiGate 1, go to Dashboard.

3. Enter the CLI Console widget and type this command to verify BGP neighbors:

get router info bgp summary

4. From FortiGate 2, go to Monitor > Routing Monitor and verify that routes from FortiGate 1 were successfully advertised to FortiGate 2 via BGP.

5. From FortiGate 2, go to Dashboard.

6. Enter the CLI Console widget and type this command to verify BGP neighbors:

get router info bgp summary


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

OSPF over dynamic IPsec

Leave a reply

OSPF over dynamic IPsec

This example shows how to create a dynamic IPsec VPN tunnel that allows OSPF.

 

Configuring IPsec on FortiGate 1

1. Go to Dashboard and enter the CLI Console widget

2. Create phase 1:

config vpn ipsec phase1-interface edit “dial-up”

set type dynamic

set interface “wan1” set mode-cfg enable

set proposal 3des-sha1 set add-route disable

set ipv4-start-ip 10.10.101.0 set ipv4-end-ip 10.10.101.255 set psksecret

next end

3. Create phase 2:

config vpn ipsec phase2-interface edit “dial-up-p2”

set phase1name “dial-up”

set proposal 3des-sha1 aes128-sha1 next

end

 

Configuring OSPF on FortiGate 1

1. Go to Dashboard and enter the CLI Console widget.

2. Create OSPF route.

config router ospf

set router-id 172.20.120.22 config area

edit 0.0.0.0 next

end

config network edit 1

set prefix 10.10.101.0 255.255.255.0 next

end

config redistribute “connected” set status enable

end

config redistribute “static” set status enable

end

end

 

Adding policies on FortiGate 1

1. Go to Policy & Objects > IPv4 Policy and create a policy allowing OSPF traffic from dial–up to port5.

2. Go to Policy & Objects > IPv4 Policy and create a policy allowing OSPF traffic from port5 to dial–up interfaces.

 

Configuring IPsec on FortiGate 2

1. Go to Dashboard and enter the CLI Console widget

2. Create phase 1:

config vpn ipsec phase1-interface edit “dial-up-client”

set interface “wan1” set mode-cfg enable

set proposal 3des-sha1 set add-route disable

set remote-gw 172.20.120.22 set psksecret

next end

3. Create phase 2:

config vpn ipsec phase2-interface edit “dial-up-client”

set phase1name “dial-up-client”

set proposal 3des-sha1 aes128-sha1 set auto-negotiate enable

next end

 

Configuring OSPF on FortiGate 2

1. Go to Dashboard and enter the CLI Console widget.

2. Create OSPF route.

config router ospf

set router-id 172.20.120.15 config area

edit 0.0.0.0 next

end

config network edit 1

set prefix 10.10.101.0 255.255.255.0 next

end

config redistribute “connected” set status enable

end

config redistribute “static” set status enable

end

end

 

Adding policies on FortiGate 2

1. Go to Policy & Objects > IPv4 Policy and create a policy allowing OSPF traffic from dial–up–client to port5.

2. Go to Policy & Objects > IPv4 Policy and create a policy allowing OSPF traffic from port5 to dial–up–client interfaces.

 

Verifying the tunnel is up

Go to Monitor > IPsec Monitor to verify that the tunnel is Up.

 

Results

1. From FortiGate 1, go to Monitor > Routing Monitor and verify that routes from FortiGate 2 were successfully advertised to FortiGate 1 via OSPF.

2. From FortiGate 1, go to Dashboard. Enter the CLI Console widget and type this command to verify OSPF neighbors:

get router info ospf neighbor

OSPF process 0:

Neighbor     ID Pri State Dead Time    Address Interface

172.20.120.25 1 Full /    –  00:00:34 10.10.101.1 dial-up_0

3. From FortiGate 2, go to Monitor > Routing Monitor and verify that routes from FortiGate 1 were successfully advertised to FortiGate 2 via OSPF.

4. From FortiGate 2, go to Dashboard. Enter the CLI Console widget and type this command to verify OSPF neighbors:

get router info ospf neighbor

OSPF process 0:

Neighbor     ID Pri State Dead Time    Address    Interface

172.20.120.22 1 Full /    –  00:00:30 10.10.101.2 dial-up_client


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Redundant OSPF routing over IPsec

Leave a reply

Redundant OSPF routing over IPsec

This example sets up redundant secure communication between two remote networks using an Open Shortest Path First (OSPF) VPN connection. In this example, the HQ FortiGate unit will be called FortiGate 1 and the Branch FortiGate unit will be called FortiGate 2.

 

The steps include:

1. Creating redundant IPsec tunnels on FortiGate 1.

2. Configuring IP addresses and OSPF on FortiGate 1.

3. Configuring firewall addresses on FortiGate 1.

4. Configuring security policies on FortiGate 1.

5. Creating redundant IPsec tunnels for FortiGate 2.

6. Configuring IP addresses and OSPF on FortiGate 2.

7. Configuring firewall addresses on FortiGate 2.

8. Configuring security policies on FortiGate 2.

 

Creating redundant IPsec tunnels on FortiGate 1

1. Go to VPN > IPsec Tunnels.

2. Select Create New, name the primary tunnel and select Custom VPN Tunnel (No Template).

3. Set the following:

Remote Gateway                          Static IP Address

IP Address                                    FortiGate 2’s wan1 IP

Local Interface                             wan1 (the primary Internet-facing interface)

Pre–shared Key                            Enter

4. Go to VPN > IPsec Tunnels.

5. Select Create New, name the secondary tunnel and select Custom VPN Tunnel (No Template).

6. Set the following:

Remote Gateway                          Static IP Address

IP Address                                    FortiGate 2’s wan1 IP

Local Interface                             wan2 (the secondary Internet-facing interface)

Pre–shared Key                            Enter

 

Configuring IP addresses and OSPF on FortiGate 1

1. Go to Network > Interfaces.

2. Select the arrow for wan1 to expand the list.

3. Edit the primary tunnel interface and create IP addresses.

IP                                                      10.1.1.1

Remote IP                                        10.1.1.2

4. Select the arrow for wan2 to expand the list.

5. Edit the secondary tunnel interface and create IP addresses.

IP                                                      10.2.1.1

Remote IP                                        10.2.1.2

6. Go to Network > OSPF and enter the Router ID for FortiGate 1.

7. Select Create New in the Area section.

8. Add the backbone area of 0.0.0.0.

9. Select Create New in the Networks section.

10. Create the networks and select Area 0.0.0.0 for each one.

11. Select Create New in the Interfaces section.

12. Create primary and secondary tunnel interfaces.

13. Set a Cost of 10 for the primary interface and 100 for the secondary interface.

 

Configuring firewall addresses on FortiGate 1

1. Go to Policy & Objects > Addresses.

2. Create/Edit the subnets behind FortiGate 1 and FortiGate 2.

3. Create/Edit the primary and secondary interfaces of FortiGate 2.

 

Configuring security policies on FortiGate 1

1. Go to Policy & Objects > IPv4 Policy.

2. Create the four security policies required for both FortiGate 1’s primary and secondary interfaces to connect to FortiGate 2’s primary and secondary interfaces.

Creating redundant IPsec tunnels on FortiGate 2

1. Go to VPN > IPsec Tunnels.

2. Select Create New, name the primary tunnel and select Custom VPN Tunnel (No Template).

3. Set the following:

Remote Gateway                          Static IP Address

IP Address                                    FortiGate 1’s wan1 IP

Local Interface                             wan1 (the primary Internet-facing interface)

Pre–shared Key                            Enter

Redundant OSPF routing over IPsec

4. Go to VPN > IPsec Tunnels.

5. Select Create New, name the secondary tunnel and select Custom VPN Tunnel (No Template).

6. Set the following:

Remote Gateway                          Static IP Address

IP Address                                    FortiGate 1’s wan1 IP

Local Interface                             wan2 (the secondary Internet-facing interface)

Pre–shared Key                            Enter

 

Configuring IP addresses and OSPF on FortiGate 1

1. Go to Network > Interfaces.

2. Select the arrow for wan1 to expand the list.

3. Edit the primary tunnel interface and create IP addresses.

IP                                                      10.1.1.2

Remote IP                                        10.1.1.1

4. Select the arrow for wan2 to expand the list.

5. Edit the secondary tunnel interface and create IP addresses.

IP                                                      10.2.1.2

Remote IP                                        10.2.1.1

6. Go to Network > OSPF and enter the Router ID for FortiGate 2.

7. Select Create New in the Area section.

8. Add the backbone area of 0.0.0.0.

9. Select Create New in the Networks section.

10. Create the networks and select Area 0.0.0.0 for each one.

11. Select Create New in the Interfaces section.

12. Create primary and secondary tunnel interfaces.

13. Set a Cost of 10 for the primary interface and 100 for the secondary interface.

 

Configuring firewall addresses on FortiGate 2

1. Go to Policy & Objects > Addresses.

2. Create/Edit the subnets behind FortiGate 1 and FortiGate 2.

3. Create/Edit the primary and secondary interfaces of FortiGate 2.

 

Configuring security policies on FortiGate 2

1. Go to Policy & Objects > IPv4 Policy.

2. Create the four security policies required for both FortiGate 2’s primary and secondary interfaces to connect to FortiGate 1’s primary and secondary interfaces.

 

Results

1. Go to Monitor > IPsec Monitor to verify the statuses of both the primary and secondary IPsec VPN tunnels on FortiGate 1 and FortiGate 2.

2. Go to Monitor > Routing Monitor. Monitor to verify the routing table on FortiGate 1 and FortiGate 2. Type OSPF for the Type and select Apply Filter to verify the OSPF route.

3. Verify that traffic flows via the primary tunnel:

  • From a PC1 set to IP:10.20.1.100 behind FortiGate 1, run a tracert to a PC2 set to IP address 10.21.1.00 behind FortiGate 2 and vise versa.
  • From PC1, you should see that the traffic goes through 10.1.1.2 which is the primary tunnel interface IP set on FortiGate 2.
  • From PC2, you should see the traffic goes through 10.1.1.1 which is the primary tunnel interface IP set on FortiGate 1.

4. The VPN network between the two OSPF networks uses the primary VPN connection. Disconnect the wan1 interface and confirm that the secondary tunnel will be used automatically to maintain a secure connection.

5. Verify the IPsec VPN tunnel statuses on FortiGate 1 and FortiGate 2. Both FortiGates should show that primary tunnel is DOWN and secondary tunnel is UP.

6. Go to Monitor > IPsec Monitor to verify the status.

7. Verify the routing table on FortiGate 1 and FortiGate 2.

The secondary OSPF route (with cost = 100) appears on both FortiGate units.

8. Go to Monitor > Routing Monitor. Type OSPF for the Type and select Apply Filter to verify OSPF route.

9. Verify that traffic flows via the secondary tunnel:

  • From a PC1 set to IP:10.20.1.100 behind FortiGate 1, run a tracert to a PC2 set to IP:10.21.1.100 behind FortiGate 2 and vice versa.
  • From PC1, you should see that the traffic goes through 10.2.1.2 which is the secondary tunnel interface IP set on FortiGate 2.
  • From PC2, you should see the traffic goes through 10.2.1.1 which is the secondary tunnel interface IP set on FortiGate 1.

 


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!