Category Archives: FortiOS

ICMPv6

Internet Control Message Protocol version 6 (ICMPv6) is the new implementation of the Internet Control Message Protocol (ICMP) that is part of Internet Protocol version 6 (IPv6). The ICMPv6 protocol is defined in RFC 4443.

ICMPv6 is a multipurpose protocol. It performs such things as:

error reporting in packet processing
diagnostic functions
Neighbor Discovery process
IPv6 multicast membership reporting

It is also designed as a framework to use extensions for use with future implementations and changes. Examples of extensions that have already been written for ICMPv6:

Neighbor Discovery Protocol (NDP) – a node discovery protocol in IPv6 which replaces and enhances functions of ARP.
Secure Neighbor Discovery Protocol (SEND) – an extension of NDP with extra security.
Multicast Router Discovery (MRD) – allows discovery of multicast routers.
ICMPv6 messages use IPv6 packets for transportation and can include IPv6 extension headers. ICMPv6 includes some of the functionality that in IPv4 was distributed among protocols such as ICMPv4, ARP (Address Resolution Protocol), and IGMP (Internet Group Membership Protocol version 3).
ICMPv6 has simplified the communication process by eliminating obsolete messages. ICMPv6 messages are subdivided into two classes: error messages and information messages. Error Messages are divided into four categories:
Destination Unreachable
Time Exceeded
Packet Too Big
Parameter Problems
Information messages are divided into three groups:
Diagnostic messages
Neighbor Discovery messages
Messages for the management of multicast groups.

ICMPv6 Types and Codes

ICMPv6 has a number of messages that are identified by the “Type” field. Some of these types have assigned “Code” fields as well. The table below shows the different types of ICMP Types with their associated codes if there are any.

Type codes 0 − 127 are error messages and type codes 128 − 255 are for information messages.

ICMPv6 Types and Codes

Type #

Type Name

Code

Reserved

0 – no route to destination

1 – communication with destination administratively pro- hibited

2 – beyond scope of source address

3 – address unreachable

4 – port unreachable

5 – source address failed ingress/egress policy

6 – reject route to destination

7 – Error in Source Routing Header

Destination Unreachable

Packet Too Big

Time Exceeded

0 – hop limit exceeded in transit

1 – fragment reassembly time exceeded

Parameter Problem

0 – erroneous header field encountered

1 – unrecognized Next Header type encountered

2 – unrecognized IPv6 option encountered

100

Private Experimentation

101

Private Experimentation

102 –

126

Unassigned

127

Reserved for expansion if ICMPv6 error messages

128

Echo Request

129

Echo Replay

130

Multicast Listener Query

Type # Type Name Code

131 Multicast Listener Report

132 Multicast Listener Done

133 Router Solicitation

134 Router Advertisement

135 Neighbor Solicitation

136 Neighbor Advertisement

137 Redirect Message

0 – Router Renumbering Command

138 Router Renumbering

1 – Router Renumbering Result

255 – Sequence Number Reset

139 ICMP Node Information Query 0 – The Data field contains an IPv6 address which is the

Subject of this Query.

1 – The Data field contains a name which is the Subject of this Query, or is empty, as in the case of a NOOP.

2 – The Data field contains an IPv4 address which is the

Subject of this Query.

140 ICMP Node Information Response

0 – A successful reply. The Reply Data field may or may not be empty.

1 – The Responder refuses to supply the answer. The

Reply Data field will be empty.

2 – The Qtype of the Query is unknown to the Responder. The Reply Data field will be empty.

141 Inverse Neighbor Discovery Soli- citation Message

142 Inverse Neighbor Discovery Advert- isement Message

143 Version 2 Multicast Listener Report

144 Home Agent Address Discovery

Request Message

Type # Type Name Code

145 Home Agent Address Discovery

Reply Message

146 Mobile Prefix Solicitation

147 Mobile Prefix Advertisement

148 Certification Path Solicitation Mes- sage

149 Certification Path Advertisement

Message

150

ICMP messages utilized by exper- imental mobility protocols such as Seamoby

151 Multicast Router Advertisement

152 Multicast Router Solicitation

153 Multicast Router Termination

154 FMIPv6 Messages

155 RPL Control Message

156 ILNPv6 Locator Update Message

157 Duplicate Address Request

158 Duplicate Address Confirmation

159 −

199

Unassigned

200 Private experimentation

201 Private experimentation

255 Reserved for expansion of ICMPv6 informational messages

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!

NAT64 and NAT66 session failover

Leave a reply

NAT64 and NAT66 session failover

The FortiGate Clustering Protocol (FGCP) supports IPv6, NAT64, and NAT66 session failover. If session pickup is enabled, these sessions are synchronized between cluster members and, after an HA failover, the sessions will resume with only minimal interruption.

NAT46

NAT46 is used to translate IPv4 addresses to IPv6 addresses so that a client on an IPv4 network can communicate transparently with a server on an IPv6 network.

To enable NAT46, use the following CLI command:

config firewall vip46

NAT46 policies

Security policies for NAT46 can be configured from the web-based manager. For these options to appear in the web-based manager, this feature must be enabled using System > Feature Select. You can then configure the policies under Policy & Objects > NAT46 Policy.

NAT46 policies and can also be configured from the CLI using the following command:

config firewall policy46

NAT66

Leave a reply

NAT66

NAT66 is used for translating an IPv6 source or destination address to a different IPv6 source or destination address. NAT66 is not as common or as important as IPv4 NAT, as many IPv6 addresses do not need NAT66 as much as IPv4 NAT. However, NAT66 can be useful for a number of reasons. For example, you may have changed the IP addresses of some devices on your network but want traffic to still appear to be coming from their old addresses. You can use NAT66 to translate the source addresses of packets from the devices to their old source addresses.

In FortiOS, NAT66 options can be added to an IPv6 security policy from the CLI. Configuring NAT66 is very similar to configuring NAT in an IPv4 security policy. For example, use the following command to add an IPv6 security policy that translates the source address of IPv6 packets to the address of the destination interface (similar to IPv4 source NAT:

config firewall policy6 edit 0

set srcintf internal set dstintf wan1

set srcaddr internal_net set dstaddr all

set action accept set schedule always set service ANY

set nat enable end

Its also can be useful to translate one IPv6 source address to another address that is not the same as the address of the exiting interface. You can do this using IP pools. For example, enter the following command to add an IPv6 IP pool containing one IPv6 IP address:

config firewall ippool6 edit example_6_pool

set startip 2001:db8::

set endip 2001:db8::

end

Enter the following command to add an IPv6 firewall address that contains a single IPv6 IP address.

config firewall address6 edit device_address

set ip6 2001:db8::132/128 end

Enter the following command to add an IPv6 security policy that accepts packets from a device with IP address 2001:db8::132 and translates the source address to 2001:db8::.

config firewall policy6 edit 0

set srcintf internal set dstintf wan1

set srcaddr device_address set dstaddr all

set action accept set schedule always set service ANY

set nat enable

set ippool enable

set poolname example_6_pool end

NAT66 destination address translation

NAT66 can also be used to translate destination addresses. This is done in an IPv6 policy by using IPv6 virtual IPs. For example, enter the following command to add an IPv6 virtual IP that maps the destination address 2001:db8::dd to 2001:db8::ee.

config firewall vip6 edit example-vip6

set extip 2001:db8::dd

set mappedip 2001:db8::ee end

Enter the following command to add an IPv6 security policy that accepts packets with a destination address 2001:db8::dd and translates that destination address to 2001:db8::ee.

config firewall policy6 edit 0

set srcintf internal set dstintf wan1

set srcaddr all

set dstaddr example-vip6 set action accept

set schedule always set service ANY

end

IPv6 Network Address Translation

2 Replies

IPv6 Network Address Translation

NAT66, NAT64, and DNS64 are now supported for IPv6. These options provide IPv6 NAT and DNS capabilities withIPv6-IPv4 tunnelling or dual stack configurations. The commands are available only in the CLI.

Fortinet supports all features described in RFC 6146. However, for DNS64 there is no support for handling Domain Name System Security Extensions (DNSSEC). DNSSEC is for securing types of information that are provided by the DNS as used on an IP network or networks. You can find more information about DNS64 in RFC 6147.

NAT64 and DNS64 (DNS proxy)

NAT64 is used to translate IPv6 addresses to IPv4 addresses so that a client on an IPv6 network can communicate transparently with a server on an IPv4 network.

NAT64 is usually implemented in combination with the DNS proxy called DNS64. DNS64 synthesizes AAAA records from A records and is used to synthesize IPv6 addresses for hosts that only have IPv4 addresses. ‘DNS proxy’ and ‘DNS64’ are interchangeable terms.

Example NAT64 configuration

With a NAT64 and DNS64 configuration in place on a FortiGate unit, clients on an IPv6 network can transparently connect to addresses on an IPv4 network. NAT64 and DNS64 perform the IPv4 to IPv6 transition, allowing clients that have already switched to IPv6 addresses to continue communicating with servers that still use IPv4 addresses.

To enable NAT64 and DNS64, use the following CLI commands:

Enable NAT64

config system nat64 set status enable

end

Enable the DNS proxy on the IPv6 interface

config system dns-server edit internal

end

In your DHCP6 configuration, configure the IPv6 interface IP address as the DNS6 server IP address. The FortiGate will proxy DNS requests to the system DNS server.

config system dhcp6 server edit 1

set interface internal config ip-range

edit 1

set start-ip 2001:db8:1::11 set end-ip 2001:db8:1::20

end

set dns-server1 2001:db8:1::10 end

NAT64 policies

You can configure security policies for NAT64 using the web-based manager. For these options to appear, the feature must be enabled using System > Feature Select. You can then configure the policies under Policy & Objects > NAT64 Policy.

NAT64 policies and can also be configured from the CLI using the following command:

config firewall policy64

In the following section, you will configure a NAT64 policy that allows connections from an internal IPv6 network to an external IPv4 network.

Configuring NAT64 to allow a host on the IPv6 network to connect to the Internet server

In this example, the Internal IPv6 network address is 2001:db8:1::/48 and the external IPv4 network address is 172.20.120.0/24. NAT64 is configured to allow a user on the internal network to connect to the server at IPv4 address 172.20.120.12. In this configuration, sessions exiting the wan1 interface must have their source address changed to an IPv4 address in the range 172.20.120.200 to 172.20.120.210.

Enter the following command to enable NAT64:

config system nat64 set status enable

end

Enabling NAT64 with the config system nat64 command means that all IPv6 traffic received by the current VDOM can be subject to NAT64 if the source and destination address matches an NAT64 security policy.

By default, the setting always-synthesize-aaaa-record is enabled. If you disable this setting, the DNS proxy (DNS64) will attempt to find an AAAA records for queries to domain names and therefore resolve the host names to IPv6 addresses. If the DNS proxy cannot find an AAAA record, it synthesizes one by adding the NAT64 prefix to the A record.

By using the nat64-prefix option of the config system nat64 command to change the default nat64 prefix from the well-known prefix of 64:ff9b::/96 and setting always-synthesize-aaaa-record to enable (default), the DNS proxy does not check for AAAA records but rather synthesizes AAAA records.

As an alternative to the above entry, there is the optional configuration that would allow the resolution of CNAME queries.

config system nat64 set status enable

set nat64-prefix 64:ff9b::/96

set always-synthesize-aaaa-record enable end

Enter the following command to add an IPv6 firewall address for the internal network:

config firewall address6 edit internal-net6

set ip6 2001:db8:1::/48 end

Enter the following command to add an IPv4 firewall address for the external network:

config firewall address edit external-net4

set subnet 172.20.120.0/24

set associated-interface wan1 end

Enter the following command to add an IP pool containing the IPv4 address that the should become the source address of the packets exiting the wan1 interface:

config firewall ippool edit exit-pool4

set startip 172.20.120.200 set endip 172.20.120.210

end

Enter the following command to add a NAT64 policy that allows connections from the internal IPv6 network to the external IPv4 network:

config firewall policy64 edit 0

set srcintf internal

set srcaddr internal-net6 set dstintf wan1

set dstaddr external-net4 set action accept

set schedule always set service ANY

set logtraffic enable set ippool enable

set poolname exit-pool4 end

The srcaddr can be any IPv6 firewall address and the dstaddr can be any IPv4 firewall address.

Other NAT64 policy options include fixedport, which can be used to prevent NAT64 from changing the destination port. You can also configure traffic shaping for NAT64 policies.

How a host on the internal IPv6 network communicates with example.server.com that only has IPv4 address on the Internet

1. The host on the internal network does a DNS lookup for example.server.com by sending a DNS query for an AAAA record for example.server.com.

2. The DNS query is intercepted by the FortiGate DNS proxy.

3. The DNS proxy attempts to resolve the query with a DNS server on the Internet and discovers that there are no AAAA records for example.server.com.

4. The previous step is skipped if always-synthesize-aaaa-record is enabled.

5. The DNS proxy performs an A-record query for example.server.com and gets back an RRSet containing a single A record with the IPv4 address 172.20.120.12.

6. The DNS proxy then synthesizes an AAAA record. The IPv6 address in the AAAA record begins with the configured NAT64 prefix in the upper 96 bits and the received IPv4 address in the lower 32 bits. By default, the resulting IPv6 address is 64:ff9b::172.20.120.12.

7. The host on the internal network receives the synthetic AAAA record and sends a packet to the destination address 64:ff9b::172.20.120.12.

8. The packet is routed to the FortiGate internal interface where it is accepted by the NAT64 security policy.

9. The FortiGate unit translates the destination address of the packets from IPv6 address 64:ff9b::172.20.120.12 to IPv4 address 172.20.120.12 and translates the source address of the packets to 172.20.120.200 (or another address in the IP pool range) and forwards the packets out the wan1 interface to the Internet.

IPv6 Features

Leave a reply

IPv6 Features

In order to configure IPv6 features using the web-based manager, IPv6 must be enabled using Feature Select. Go to System > Config > Features, enable IPv6, and click Apply.

The following IPv6 features are available from the FortiOS web manager:

IPv6 policies
IPv6 Network Address Translation
ICMPv6
IPv6 in dynamic routing
Dual stack routing IPv6 tunnelling SIP over IPv6
New Fortinet FortiGate IPv6 MIB fields
IPv6 Per-IP traffic shaper
DHCPv6
IPv6 forwarding
Obtaining IPv6 addresses from an IPv6 DHCP server

IPv6 policies

IPv6 security policies are created both for an IPv6 network and a transitional network. A transitional network is a network that is transitioning over to IPv6 but must still have access to the Internet or must connect over an IPv4 network.

These policies allow for this specific type of traffic to travel between the IPv6 and IPv4 networks. The IPv6 options for creating these policies is hidden by default. You must enable this feature under System > Config > Features.

IPv6 policy route

IPv6 policy routing

IPv6 policy routing functions in the same was as IPv4 policy routing. To add an IPv6 policy route, go to Network > Policy Routes and select Create New > IPv6 Policy Route.

Adding an IPv6 Policy route

You can also use the following command to add IPv6 policy routes:

config router policy6 edit 0

set input-device <interface>

set src <ipv6_ip>

set dst <ipv6_ip>

set protocol <0-255>

set gateway <ipv6_ip>

set output-device <interface>

set tos <bit_pattern>

set tos-mask <bit_mask>

end

IPv6 security policies

IPv6 security policies support all the features supported by IPv4 security policies:

Policy types and subtypes.
NAT support including using the destination interface IP address, fixed port, and dynamic IP pools.
All security features (antivirus, web filtering, application control, IPS, email filtering, DLP, VoIP, and ICAP).
All traffic shaping options, including: shared traffic shaping, reverse shared traffic shaping, and per-IP traffic shaping.
All user and device authentication options.

IPv6 explicit web proxy

You can use the explicit web proxy for IPv6 traffic. To do this you need to:

Enable the IPv6 explicit web proxy from the CLI.
Enable the explicit web proxy for one or more FortiGate interfaces. These interfaces also need IPv6 addresses.
Add IPv6 web proxy security policies to allow the explicit web proxy to accept IPv6 traffic.

Use the following steps to set up a FortiGate unit to accept IPv6 traffic for the explicit web proxy at the Internal interface and forward IPv6 explicit proxy traffic out the wan1 interface to the Internet.

1. Enter the following CLI command to enable the IPv6 explicit web proxy:

config web-proxy explicit set status enable

set ipv6-status enable end

2. Go to Network > Interfaces and edit the internal interface, select Enable Explicit Web Proxy and select OK.

3. Go to Policy & Objects > Explicit Proxy Policy and select Create New to add an IPv6 explicit web proxy security policy with the following settings shown.

This IPv6 explicit web proxy policy allows traffic from all IPv6 IP addresses to connect through the explicit web proxy and through the wan1 interface to any IPv6 addresses that are accessible from the wan1 interface.

If you have enabled both the IPv4 and the IPv6 explicit web proxy, you can combine IPv4 and IPv6 addresses in a single explicit web proxy policy to allow both IPv4 and IPv6 traffic through the proxy.

Restricting the IP address of the explicit IPv6 web proxy

You can use the following command to restrict access to the IPv6 explicit web proxy using only one IPv6 address. The IPv6 address that you specify must be the IPv6 address of an interface that the explicit HTTP proxy is enabled on. You might want to use this option if the explicit web proxy is enabled on an interface with multiple IPv6 addresses.

For example, to require users to connect to the IPv6 address 2001:db8:0:2::30 to connect to the explicit IPv6 HTTP proxy, use the following command:

config web-proxy explicit

set incoming-ipv6 2001:db8:0:2::30 end

Restricting the outgoing source IP address of the IPv6 explicit web proxy

You can use the following command to restrict the source address of outgoing web proxy packets to a single IPv6 address. The IP address that you specify must be the IPv6 address of an interface that the explicit HTTP proxy is enabled on. You might want to use this option if the explicit HTTP proxy is enabled on an interface with multiple IPv6 addresses.

For example, to restrict the outgoing packet source address to 2001:db8:0:2::50:

config http-proxy explicit

set outgoing-ip6 2001:db8:0:2::50 end

VIP64

VIP64 policies can be used to configure static NAT virtual IPv6 address for IPv4 addresses. VIP64 can be configured from the CLI using the following commands:

config firewall vip64 edit <zname_str>

set arp-reply {enable | disable}

set color <color_int>

set comment <comment_str>

set extip <address_ipv6>[-address_ipv6]

set extport <port_int>

set id <id_num_str>

set mappedip [<start_ipv4>-<end_ipv4>]

set mappedport <port_int>

set portforward {enable | disable}

set src-filter <addr_str>

end

VIP64 CLI Variables and Defaults

Variable Description Default

<zname_str> Enter the name of this virtual IP address. No default.

arp-reply

{enable | disable}

Select to respond to ARP requests for this virtual IP address.

enable

Variable Description Default

color <color_int> Enter the number of the color to use for the group icon in the web-based man- ager.

comment <comment_str> Enter comments relevant to the con- figured virtual IP. 0

No default.

extip <address_ipv6>[- address_ipv6]

Enter the IP address or address range ::

on the external interface that you want to map to an address or address range on the destination network.

If mappedip is an IP address range, the FortiGate unit uses extip as the first IP address in the external IP address range, and calculates the last IP address required to create an equal number of external and mapped IP addresses for one-to-one mapping.

To configure a dynamic virtual IP that accepts connections destined for any IP address, set extip to ::.

Enter the external port number that you want to map to a port number on the destination network.

This option only appears if port- forward is enabled.

extport <port_int>

If portforward is enabled and you

want to configure a static NAT virtual IP 0 that maps a range of external port num-

id <id_num_str> Enter a unique identification number for the configured virtual IP. Not checked for uniqueness. Range 0 – 65535.

No default.

Variable	Description	Default
	Enter the IP address or IP address
	range on the destination network to
	which the external IP address is
	mapped.
mappedip	If mappedip is an IP address range, the FortiGate unit uses extip as the first IP address in the external IP
[<start_ipv4>-<end_	address range, and calculates the last	0.0.0.0
ipv4>]	IP address required to create an equal
	number of external and mapped IP
	addresses for one-to-one mapping.

If mappedip is an IP address range, the FortiGate unit uses extip as a single IP address to create a one-to- many mapping.

mappedport <port_int> Enter the port number on the des- 0 tination network to which the external port number is mapped.

You can also enter a port number range to forward packets to multiple ports on the destination network.

For a static NAT virtual IP, if you add a map to port range the FortiGate unit cal- culates the external port number range.

portforward

{enable | disable}

Select to enable port forwarding. You must also specify the port forwarding mappings by configuring extport and mappedport.

disable

src-filter <addr_str> Enter a source address filter. Each address must be in the form of an IPv4 subnet (x:x:x:x:x:x:x:x/n). Separate addresses with spaces.

null

VIP46 policies can be used to configure static NAT virtual IPv4 address for IPv6 addresses. VIP46 can be configured from the CLI using the following commands (see the table below for variable details):

config firewall vip46 edit <name_str>

set arp-reply {enable | disable}

set color <color_int>

set comment <comment_str>

set extip <address_ipv4>[-address_ipv4]

set extport <port_int>

set id <id_num_str>

set mappedip [<start_ipv6>-<end_ipv6>]

set mappedport <port_int>

set portforward {enable | disable}

set src-filter <add_str>

end

VIP46 CLI Variables and Defaults

Variable	Description	Default
<name_str>	Enter the name of this virtual IP	No default.
	address.
arp-reply {enable \| disable}	Select to respond to ARP requests for this virtual IP address.	enable
color <color_int>	Enter the number of the color to use for	0
	the group icon in the web-based man-
	ager.
comment <comment_str>	Enter comments relevant to the con- figured virtual IP.	No default.
extip <address_ipv4>[-	Enter the IP address or address range	0.0.0.0
address_ipv4]	on the external interface that you want
	to map to an address or address range
	on the destination network.
	If mappedip is an IP address range, the FortiGate unit uses extip as the first IP address in the external IP
	address range, and calculates the last
	IP address required to create an equal
	number of external and mapped IP
	addresses for one-to-one mapping.
	To configure a dynamic virtual IP that
	accepts connections destined for any IP
	address, set extip to 0.0.0.0.

Variable Description Default

Enter the external port number that you want to map to a port number on the destination network.

This option only appears if port- forward is enabled.

extport <port_int>

If portforward is enabled and you

want to configure a static NAT virtual IP 0 that maps a range of external port num-

bers to a range of destination port num- bers, set extport to the first port number in the range. Then set mapped- port to the start and end of the des- tination port range. The FortiGate unit automatically calculates the end of the extport port number range.
id <id_num_str> Enter a unique identification number for the configured virtual IP. Not checked for uniqueness. Range 0 – 65535.

No default.

Enter the IP address or IP address range on the destination network to which the external IP address is mapped.

mappedip [<start_ipv6>-<end_ ipv6>]

If mappedip is an IP address range, the FortiGate unit uses extip as the first IP address in the external IP address

range, and calculates the last IP ::

address required to create an equal number of external and mapped IP addresses for one-to-one mapping.

If mappedip is an IP address range, the FortiGate unit uses extip as a single IP address to create a one-to- many mapping.

Variable Description Default

mappedport <port_int> Enter the port number on the des- 0 tination network to which the external

port number is mapped.

You can also enter a port number range to forward packets to multiple ports on the destination network.

For a static NAT virtual IP, if you add a map to port range the FortiGate unit cal- culates the external port number range.

portforward

{enable | disable}

Select to enable port forwarding. You must also specify the port forwarding mappings by configuring extport and mappedport.

disable

src-filter <addr_str> Enter a source address filter. Each address must be in the form of an IPv4 subnet (x.x.x.x/n). Separate addresses with spaces.

null

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

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.

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.