Category Archives: FortiGate

Interface policies

Interface policies

Interface policies are implemented before the “security” policies and are only flow based. They are configured in the CLI.

This feature allows you to attach a set of IPS policies with the interface instead of the forwarding path, so packets can be delivered to IPS before entering firewall. This feature is used for following IPS deployments:

  • One-Arm: by defining interface policies with IPS and DoS anomaly checks and enabling sniff-mode on the interface, the interface can be used for one-arm IDS;
  • IPv6 IPS: IPS inspection can be enabled through interface IPv6 policy. Only IPS signature scan is supported in

FortiOS 4.0. IPv6 DoS protection is not supported; l Scan traffics that destined to FortiGate; l Scan and log traffics that are silently dropped or flooded by Firewall or Multicast traffic.

IPS sensors can be assigned to an interface policy. Both incoming and outgoing packets are inspected by IPS sensor (signature).

Here is an example of an interface policy,

# show full-configuration

config firewall interface-policy edit 1 set status enable

set comments ‘test interface policy #1’ set logtraffic utm set interface “port9” set srcaddr “all” set dstaddr “all”

set service “ALL” set application-list-status disable set ips-sensor-status disable set dsri disable set av-profile-status enable set av-profile “default” set webfilter-profile-status disable set spamfilter-profile-status disable set dlp-sensor-status disable set scan-botnet-connections disable next

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!

DSRI

DSRI

The Disable Server Response Inspection (DSRI) options is available for configuration in the CLI. This is used to assist performance when only URL filtering is being used. This allows the system to ignore the HTTP server responses. The setting is configured to be disabled by default.

Interface policies

CLI syntax for changing the status of the DSRI setting

In IPv4 or IPv6 firewall policies

config firewall policy|policy6 edit 0 set dsri enable|disable end

In IPv4 or IPv6 interface policies

config firewall interface-policy|interface-policy6 edit 0 set dsri enable|disable end

When using the sniffer

config firewall sniffer edit 0 set dsri enable|disable 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!

Protocol number

Protocol number

IP is responsible for more than the address that it is most commonly associated with and there are a number of associated protocols that make up the Network Layer. While there are not 256 of them, the field that identifies them is a numeric value between 0 and 256.

In the Internet Protocol version 4 (IPv4) [RFC791] there is a field called “Protocol” to identify the next level protocol. This is an 8 bit field. In Internet Protocol version 6 (IPv6) [RFC2460], this field is called the “Next Header” field.

Protocol numbers

# Protocol Protocol’s Full Name
0 HOPOPT IPv6 Hop-by-Hop Option
1 ICMP Internet Control Message Protocol
2 IGMP Internet Group Management
3 GGP Gateway-to-Gateway
4 IPv4 IPv4 encapsulation Protocol
5 ST Stream
6 TCP Transmission Control Protocol
7 CBT CBT
8 EGP Exterior Gateway Protocol
9 IGP Any private interior gateway (used by Cisco for their IGRP)
10 BBN-RCC-MON BBN RCC Monitoring
11 NVP-II Network Voice Protocol
12 PUP PUP

 

# Protocol Protocol’s Full Name
13 ARGUS ARGUS
14 EMCON EMCON
15 XNET Cross Net Debugger
16 CHAOS Chaos
17 UDP User Datagram Protocol
18 MUX Multiplexing
19 DCN-MEAS DCN Measurement Subsystems
20 HMP Host Monitoring
21 PRM Packet Radio Measurement
22 XNS-IDP XEROX NS IDP
23 TRUNK-1 Trunk-1
24 TRUNK-2 Trunk-2
25 LEAF-1 Leaf-1
26 LEAF-2 Leaf-2
27 RDP Reliable Data Protocol
28 IRTP Internet Reliable Transaction
29 ISO-TP4 ISO Transport Protocol Class 4
30 NETBLT Bulk Data Transfer Protocol
31 MFE-NSP MFE Network Services Protocol
32 MERIT-INP MERIT Internodal Protocol
33 DCCP Datagram Congestion Control Protocol
34 3PC Third Party Connect Protocol
35 IDPR Inter-Domain Policy Routing Protocol
36 XTP XTP

 

# Protocol Protocol’s Full Name
37 DDP Datagram Delivery Protocol
38 IDPR-CMTP IDPR Control Message Transport Proto
39 TP++ TP++ Transport Protocol
40 IL IL Transport Protocol
41 IPv6 IPv6 encapsulation
42 IPv6 SDRPSource Demand Routing Protocol
43 IPv6-Route Routing Header for IPv6
44 IPv6-Frag Fragment Header for IPv6
45 IDRP Inter-Domain Routing Protocol
46 RSVP Reservation Protocol
47 GRE General Routing Encapsulation
48 DSR Dynamic Source Routing Protocol
49 BNA BNA
50 ESP Encap Security Payload
51 AH Authentication Header
52 I-NLSP Integrated Net Layer Security TUBA
53 SWIPE IP with Encryption
54 NARP NBMA Address Resolution Protocol
55 MOBILE IP Mobility
56 TLSP Transport Layer Security Protocol using Kryptonet key management
57 SKIP SKIP
58 IPv6-ICMP ICMP for IPv6
59 IPv6-NoNxt No Next Header for IPv6
60 IPv6-Opts Destination Options for IPv6

 

# Protocol Protocol’s Full Name
61   any host internal protocol
62 CFTP CFTP
63   any local network
64 SAT-EXPAK SATNET and Backroom EXPAK
65 KRYPTOLAN Kryptolan
66 RVD MIT Remote Virtual Disk Protocol
67 IPPC Internet Pluribus Packet Core
68   any distributed file system
69 SAT-MON SATNET Monitoring
70 VISA VISA Protocol
71 IPCV Internet Packet Core Utility
72 CPNX Computer Protocol Network Executive
73 CPHB Computer Protocol Heart Beat
74 WSN Wang Span Network
75 PVP Packet Video Protocol
76 BR-SAT-MON Backroom SATNET Monitoring
77 SUN-ND SUN ND PROTOCOL-Temporary
78 WB-MON WIDEBAND Monitoring
79 WB-EXPAK WIDEBAND EXPAK
80 ISO-IP ISO Internet Protocol
81 VMTP VMTP
82 SECURE-VMTP SECURE-VMTP
83 VINES VINES
84 TTP TTP

 

# Protocol Protocol’s Full Name
84 IPTM Protocol Internet Protocol Traffic
85 NSFNET-IGP NSFNET-IGP
86 DGP Dissimilar Gateway Protocol
87 TCF TCF
88 EIGRP EIGRP
89 OSPFIGP OSPFIGP
90 Sprite-RPC Sprite RPC Protocol
91 LARP Locus Address Resolution Protocol
92 MTP Multicast Transport Protocol
93 AX.25 AX.25 Frames
94 IPIP IP-within-IP Encapsulation Protocol
95 MICP Mobile Internetworking Control Pro.
96 SCC-SP Semaphore Communications Sec. Pro.
97 ETHERIP Ethernet-within-IP Encapsulation
98 ENCAP Encapsulation Header
99   any private encryption scheme
100 GMTP GMTP
101 IFMP Ipsilon Flow Management Protocol
102 PNNI PNNI over IP
103 PIM Protocol Independent Multicast
104 ARIS ARIS
105 SCPS SCPS
106 QNX QNX
107 A/N Active Networks

 

# Protocol Protocol’s Full Name
108 IPComp IP Payload Compression Protocol
109 SNP Sitara Networks Protocol
110 Compaq-Peer Compaq Peer Protocol
111 IPX-in-IP IPX in IP
112 VRRP Virtual Router Redundancy Protocol
113 PGM PGM Reliable Transport Protocol
114   any 0-hop protocol
115 L2TP Layer Two Tunneling Protocol
116 DDX D-II Data Exchange (DDX)
117 IATP Interactive Agent Transfer Protocol
118 STP Schedule Transfer Protocol
119 SRP SpectraLink Radio Protocol
120 UTI UTI
121 SMP Simple Message Protocol
122 SM SM
123 PTP Performance Transparency Protocol
124 ISIS over IPv4  
125 FIRE  
126 CRTP Combat Radio Transport Protocol
127 CRUDP Combat Radio User Datagram
128 SSCOPMCE  
129 IPLT  
130 SPS Secure Packet Shield
131 PIPE Private IP Encapsulation within IP
# Protocol Protocol’s Full Name
132 SCTP Stream Control Transmission Protocol
133 FC Fibre Channel
134 RSVP-E2EIGNORE  
135 Mobility Header  
136 UDPLite  
137 MPLS-in-IP  
138 manet  
139 HIP  
140 Shim6  
141 WESP  
142 ROHC  
143 − 252 Unassigned Unassigned
253   Use for experimentation and testing
254   Use for experimentation and testing
255 Reserved  

Further information can be found by researching RFC 5237.

Protocol number

IP is responsible for more than the address that it is most commonly associated with and there are a number of associated protocols that make up the Network Layer. While there are not 256 of them, the field that identifies them is a numeric value between 0 and 256.

In the Internet Protocol version 4 (IPv4) [RFC791] there is a field called “Protocol” to identify the next level protocol. This is an 8 bit field. In Internet Protocol version 6 (IPv6) [RFC2460], this field is called the “Next Header” field.

Protocol numbers

# Protocol Protocol’s Full Name
0 HOPOPT IPv6 Hop-by-Hop Option

 

# Protocol Protocol’s Full Name
1 ICMP Internet Control Message Protocol
2 IGMP Internet Group Management
3 GGP Gateway-to-Gateway
4 IPv4 IPv4 encapsulation Protocol
5 ST Stream
6 TCP Transmission Control Protocol
7 CBT CBT
8 EGP Exterior Gateway Protocol
9 IGP Any private interior gateway (used by Cisco for their IGRP)
10 BBN-RCC-MON BBN RCC Monitoring
11 NVP-II Network Voice Protocol
12 PUP PUP
13 ARGUS ARGUS
14 EMCON EMCON
15 XNET Cross Net Debugger
16 CHAOS Chaos
17 UDP User Datagram Protocol
18 MUX Multiplexing
19 DCN-MEAS DCN Measurement Subsystems
20 HMP Host Monitoring
21 PRM Packet Radio Measurement
22 XNS-IDP XEROX NS IDP
23 TRUNK-1 Trunk-1
24 TRUNK-2 Trunk-2

 

# Protocol Protocol’s Full Name
25 LEAF-1 Leaf-1
26 LEAF-2 Leaf-2
27 RDP Reliable Data Protocol
28 IRTP Internet Reliable Transaction
29 ISO-TP4 ISO Transport Protocol Class 4
30 NETBLT Bulk Data Transfer Protocol
31 MFE-NSP MFE Network Services Protocol
32 MERIT-INP MERIT Internodal Protocol
33 DCCP Datagram Congestion Control Protocol
34 3PC Third Party Connect Protocol
35 IDPR Inter-Domain Policy Routing Protocol
36 XTP XTP
37 DDP Datagram Delivery Protocol
38 IDPR-CMTP IDPR Control Message Transport Proto
39 TP++ TP++ Transport Protocol
40 IL IL Transport Protocol
41 IPv6 IPv6 encapsulation
42 IPv6 SDRPSource Demand Routing Protocol
43 IPv6-Route Routing Header for IPv6
44 IPv6-Frag Fragment Header for IPv6
45 IDRP Inter-Domain Routing Protocol
46 RSVP Reservation Protocol
47 GRE General Routing Encapsulation
48 DSR Dynamic Source Routing Protocol

 

# Protocol Protocol’s Full Name
49 BNA BNA
50 ESP Encap Security Payload
51 AH Authentication Header
52 I-NLSP Integrated Net Layer Security TUBA
53 SWIPE IP with Encryption
54 NARP NBMA Address Resolution Protocol
55 MOBILE IP Mobility
56 TLSP Transport Layer Security Protocol using Kryptonet key management
57 SKIP SKIP
58 IPv6-ICMP ICMP for IPv6
59 IPv6-NoNxt No Next Header for IPv6
60 IPv6-Opts Destination Options for IPv6
61   any host internal protocol
62 CFTP CFTP
63   any local network
64 SAT-EXPAK SATNET and Backroom EXPAK
65 KRYPTOLAN Kryptolan
66 RVD MIT Remote Virtual Disk Protocol
67 IPPC Internet Pluribus Packet Core
68   any distributed file system
69 SAT-MON SATNET Monitoring
70 VISA VISA Protocol
71 IPCV Internet Packet Core Utility
72 CPNX Computer Protocol Network Executive

 

# Protocol Protocol’s Full Name
73 CPHB Computer Protocol Heart Beat
74 WSN Wang Span Network
75 PVP Packet Video Protocol
76 BR-SAT-MON Backroom SATNET Monitoring
77 SUN-ND SUN ND PROTOCOL-Temporary
78 WB-MON WIDEBAND Monitoring
79 WB-EXPAK WIDEBAND EXPAK
80 ISO-IP ISO Internet Protocol
81 VMTP VMTP
82 SECURE-VMTP SECURE-VMTP
83 VINES VINES
84 TTP TTP
84 IPTM Protocol Internet Protocol Traffic
85 NSFNET-IGP NSFNET-IGP
86 DGP Dissimilar Gateway Protocol
87 TCF TCF
88 EIGRP EIGRP
89 OSPFIGP OSPFIGP
90 Sprite-RPC Sprite RPC Protocol
91 LARP Locus Address Resolution Protocol
92 MTP Multicast Transport Protocol
93 AX.25 AX.25 Frames
94 IPIP IP-within-IP Encapsulation Protocol
95 MICP Mobile Internetworking Control Pro.

 

# Protocol Protocol’s Full Name
96 SCC-SP Semaphore Communications Sec. Pro.
97 ETHERIP Ethernet-within-IP Encapsulation
98 ENCAP Encapsulation Header
99   any private encryption scheme
100 GMTP GMTP
101 IFMP Ipsilon Flow Management Protocol
102 PNNI PNNI over IP
103 PIM Protocol Independent Multicast
104 ARIS ARIS
105 SCPS SCPS
106 QNX QNX
107 A/N Active Networks
108 IPComp IP Payload Compression Protocol
109 SNP Sitara Networks Protocol
110 Compaq-Peer Compaq Peer Protocol
111 IPX-in-IP IPX in IP
112 VRRP Virtual Router Redundancy Protocol
113 PGM PGM Reliable Transport Protocol
114   any 0-hop protocol
115 L2TP Layer Two Tunneling Protocol
116 DDX D-II Data Exchange (DDX)
117 IATP Interactive Agent Transfer Protocol
118 STP Schedule Transfer Protocol
119 SRP SpectraLink Radio Protocol

 

# Protocol Protocol’s Full Name
120 UTI UTI
121 SMP Simple Message Protocol
122 SM SM
123 PTP Performance Transparency Protocol
124 ISIS over IPv4  
125 FIRE  
126 CRTP Combat Radio Transport Protocol
127 CRUDP Combat Radio User Datagram
128 SSCOPMCE  
129 IPLT  
130 SPS Secure Packet Shield
131 PIPE Private IP Encapsulation within IP
132 SCTP Stream Control Transmission Protocol
133 FC Fibre Channel
134 RSVP-E2EIGNORE  
135 Mobility Header  
136 UDPLite  
137 MPLS-in-IP  
138 manet  
139 HIP  
140 Shim6  
141 WESP  
142 ROHC  
143 − 252 Unassigned Unassigned

 

VPN policies

# Protocol Protocol’s Full Name
253   Use for experimentation and testing
254   Use for experimentation and testing
255 Reserved  

Further information can be found by researching RFC 5237.


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!

Protocol types

Protocol types

One of the fundamental aspects of a service is the type of protocol that use used to define it. When a service is defined one of the following categories of protocol needs to be determined: l TCP/UDP/SCTP l ICMP l ICMPv6 l IP

Depending on which of these protocol categories is choose another set of specifications will can also be defined.

Protocol Type Related specifications
TCP/UDP/SCTP This is the most commonly used service protocol category. Once this category has been selected the other available options to choose are an address, either IP or

FQDN, and the protocol and port number. The protocol will be TCP, UDP or SCTP.

ICMP or ICMP6 When ICMP or ICMP6 is chosen the available options are the ICMP Type and its code.
IP When IP is the chosen protocol type the addition option is the Protocol Number.

TCP/UDP/SCTP

TCP

Transmission Control Protocol (TCP) is one of the core or fundamental protocols of the Internet. It is part of the Transport Layer of the OSI Model. It is designed to provide reliable delivery of data from a program on one device on the network or Internet to another program on another device on the network or Internet. TCP achieves its reliability because it is a connection based protocol. TCP is stream-oriented. It transports streams of data reliably and in order.

TCP establishes a prior connection link between the hosts before sending data. This is often referred to as the handshake. Once the link is established the protocol uses checks to verify that the data transmitted. If an error check fails the data is retransmitted. This makes sure that the data is getting to the destination error free and in the correct order so that it can be put back together into a form that is identical to the way they were sent.

TCP is configured more for reliability than for speed and because of this TCP will likely be slower than a connectionless protocol such as UDP. This is why TCP is generally not used for real time applications such as voice communication or online gaming. Some of the applications that use TCP are:

l World Wide Web (HTTP and HTTPS) l Email (SMTP, POP3, IMAP4) l Remote administration (RDP) l File transfer (FTP)

UDP

User Datagram Protocol (UDP) like TCP is one of the core protocols of the Internet and part of the Transport Layer of the OSI Model. UDP is designed more for speed than reliability and is generally used for different applications than TCP. UDP sends messages, referred to as datagrams across the network or Internet to other hosts without establishing a prior communication link. In other words, there is no handshake.

UDP is an unreliable service as the datagrams can arrive out of order, duplicated or go missing without any mechanism to verify them. UDP works on the assumption that any error checking is done by the application or is not necessary for the function of the application. This way it avoids the overhead that is required to verify the integrity of the data.

This lack of overhead improves the speed of the data transfer and is why UDP is often used by applications that are time sensitive in nature. UDP’s stateless nature is also great for applications that answer a large number of small queries from a large number of clients.

Common uses for UDP are:

l Domain Name Resolution (DNS) l Time (NTP) l Streaming media (RTSP, RTP and RTCP) l Telephone of the Internet (VoIP) l File Transfer (TFTP) l Logging (SNMP) l Online games (GTP and OGP)

SCTP

Stream Control Transmission Protocol (SCTP) is part of the Transport Layer of the OSI Model just like TCP and UDP and provides some of the features of both of those protocols. It is message or datagram orientated like UDP but it also ensures reliable sequential transport of data with congestion control like TCP.

SCTP provides the following services:

  • Acknowledged error-free non-duplicated transfer of user data l Data fragmentation to conform to discovered path MTU size l Sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages
  • Optional bundling of multiple user messages into a single SCTP packet l Network-level fault tolerance through supporting of multi-homing at either or both ends of an association l Congestion avoidance behavior and resistance to flooding and masquerade attacks

SCTP uses multi-streaming to transport its messages which means that there can be several independent streams of messages traveling in parallel between the points of the transmission. The data is sent out in larger chunks of data than is used by TCP just like UDP but the messages include a sequence number within each message in the same way that TCP does so that the data can be reassembled at the other end of the transmission in the correct sequence without the data having to arrive in the correct sequence.

SCTP is effective as the transport protocol for applications that require monitoring and session-loss detection. For such applications, the SCTP path and session failure detection mechanisms actively monitor the connectivity of the session. SCTP differs from TCP in having multi-homing capabilities at either or both ends and several streams within a connection, typically referred to as an association. A TCP stream represents a sequence of bytes; an SCTP stream represents a sequence of messages.

Some common applications of SCTP include supporting transmission of the following protocols over IP networks:

  • SCTP is important in 3G and 4G/LTE networks (for example, HomeNodeB = FemtoCells) l SS7 over IP (for example, for 3G mobile networks) l SCTP is also defined and used for SIP over SCTP and H.248 over SCTP l Transport of Public Switched Telephone Network (PSTN) signaling messages over IP networks.

SCTP is a much newer protocol. It was defined by the IETF Signaling Transport (SIGTRAN) working group in 2000. It was introduced by RFC 3286 and more fully define by RFC 4960.

The FortiGate firewall can apply security policies to SCTP sessions in the same way as TCP and UDP sessions. You can create security policies that accept or deny SCTP traffic by setting the service to “ALL”. FortiOS does not include pre-defined SCTP services. To configure security policies for traffic with specific SCTP source or destination ports you must create custom firewall services for SCTP.

FortiGate units route SCTP traffic in the same way as TCP and UDP traffic. You can configure policy routes specifically for routing SCTP traffic by setting the protocol number to 132. SCTP policy routes can route SCTP traffic according to the destination port of the traffic if you add a port range to the policy route.

You can configure a FortiGate unit to perform stateful inspection of different types of SCTP traffic by creating custom SCTP services and defining the port numbers or port ranges used by those services. FortiGate units support SCTP over IPv4. The FortiGate unit performs the following checks on SCTP packets:

  • Source and Destination Port and Verification Tag. l Chunk Type, Chunk Flags and Chunk Length l Verify that association exists l Sequence of Chunk Types (INIT, INIT ACK, etc) l Timer checking l Four way handshake checking l Heartbeat mechanism l Protection against INIT/ACK flood DoS attacks, and long-INIT flooding
  • Protection against association hijacking

FortiOS also supports SCTP sessions over IPsec VPN tunnels, as well as full traffic and event logging for SCTP sessions.

Protocol port values

The source and destination ports for TCP/UDP/SCTP services are important to get correct. If they are reversed the service will not work. The destination port(s) are the on ones that refer to the ports that the computer will be listening on. These are the port numbers that most people are familiar with when they associate a port number to a protocol. In most cases the source port will be one that is randomly assigned by the computer that is not being already used by another service.

Most people associate HTTP with port 80. This means that a web-server will be listening on port 80 for any http requests being sent to the computer. The computer that is sending the request can use any port that is not already assigned to another service or communication session. There are 65,535 ports that it can randomly assign, but because the ports from 1 to 1024 are normally used for listening for incoming communications it is usually not in that range. It is unless there is a specific instance when you know that a communication will be coming from a predefined source port it is best practice to set the source port range from 1 to 65,535.

ICMP

The Internet Control Message Protocol (ICMP) is a protocol layered onto the Internet Protocol Suite to provide error reporting flow control and first-hop gateway redirection. It is normally used by the operating systems of networked computers to send connectivity status query, response and error messages. It is assigned protocol number 1. There is a separate version of the protocol for both IPv4 and for IPv6. It is not designed to be absolutely reliable like TCP.

ICMP is not typically used for transporting data or for end-user network applications with the exception of some diagnostic utilities such as ping and traceroute.

ICMP messages are sent in several situations, for example:

l when a datagram cannot reach its destination, l time exceeded messages l redirect messages l when the gateway does not have the buffering capacity to forward a datagram l when the gateway can direct the host to send traffic on a shorter route.

Some of the specific ICMP message types are: l ICMP_ECHO l ICMP_TIMESTAMP l ICMP_INFO_REQUEST l ICMP_ADDRESS

For ICMP error messages, only those reporting an error for an existing session can pass through the firewall. The security policy will allow traffic to be routed, forwarded or denied. If allowed, the ICMP packets will start a new session. Only ICMP error messages of a corresponding security policy is available will be sent back to the source. Otherwise, the packet is dropped. That is, only ICMP packets for a corresponding security policy can traverse the FortiGate unit.

ICMP types and codes

ICMP 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.

ICMP types and codes

Type Number Type Name Optional Code(s)
0 Echo Reply  
1 Unassigned
2 Unassigned
3 Destination Unreachable 0            Net Unreachable

1            Host Unreachable

2            Protocol Unreachable

3            Port Unreachable

4            Fragmentation Needed and Don’t Fragment was Set

5            Source Route Failed

6            Destination Network Unknown

7            Destination Host Unknown

8            Source Host Isolated

9            Communication with Destination Network is Administratively Prohibited

10         Communication with Destination Host is Administratively Prohibited

11         Destination Network Unreachable for Type of Service

12         Destination Host Unreachable for Type of Service

13         Communication Administratively Prohibited

14         Host Precedence Violation

15         Precedence cutoff in effect

4 Source Quench  

 

Type Number Type Name Optional Code(s)
5 Redirect 0 Redirect Datagram for the Network (or subnet)

1 Redirect Datagram for the Host

2 Redirect Datagram for the Type of Service and Network

3 Redirect Datagram for the Type of Service and Host

6 Alternate Host Address  
7 Unassigned  
8 Echo  
9 Router

Advertisement

 
10 Router Selection  
11 Time Exceeded 0 Time to Live exceeded in Transit

1 Fragment Reassembly Time Exceeded

12 Parameter Problem 0 Pointer indicates the error

1 Missing a Required Option

2 Bad Length

13 Timestamp  
14 Timestand Reply  
15 Information Request  
16 Information Reply  
17 Address Mask Request  
18 Address Mask Reply  
19 Reserved (for Security)  
Type Number Type Name Optional Code(s)
20 – 29 Reserved (for

Robustness

Experiment)

 
30 Traceroute  
31 Datagram

Conversion Error

 
32 Mobile Host Redirect  
33 IPv6 Where-AreYou  
34 IPv6 I-Am-Here  
35 Mobile Registration  
36 Mobile Registration Reply  
37 Domain Name

Request

 
38 Domain Name

Reply

 
39 SKIP  
40 Photuris  
41 – 255 Reserved  
log-invalid-packet

The log-invalid-packet CLI setting is one that is intended to log invalid ICMP packets. The exact definition being:

If the FortiGate unit receives an ICMP error packet that contains an embedded IP(A,B)|TCP (C,D) header, then if FortiOS can locate the A:C -> B:D session it checks to make sure that the sequence number in the TCP header is within the range recorded in the session. If the sequence number is not in range then the ICMP packet is dropped.

When this field is enabled, the FortiGate also log messages that are not ICMP error packets.

Types of logs covered by log-invalid-packet

  • Invalid ICMP l If ICMP error message verification (see “check-reset-range”) is enabled
  • Invalid DNS packets l DNS packets that contain requests for non-existing domains
  • iprope check failed l reverse path check fail l denied and broadcast traffic l no session matched

Some other examples of messages that are not errors that will be logged, based on RFC792: Type 3 messages correspond to “Destination Unreachable Message” l Type 3, Code 1 = host unreachable l Type 3, Code 3 = port unreachable

Type 11 messages correspond to “Time Exceeded Message” l Type 11, Code 0 = time to live exceeded in transit

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 l diagnostic functions l Neighbor Discovery process l IPv6 multicast membership reporting

It 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. l 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:

  1. Destination Unreachable
  2. Time Exceeded
  3. Packet Too Big
  4. Parameter Problems

Information messages are divided into three groups:

  1. Diagnostic messages
  2. Neighbor Discovery messages
  3. 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 Number Type Name Code
0 Reserved 0 – no route to destination

1 – communication with destination administratively prohibited

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

1 Destination Unreachable  
2 Packet Too Big  
3 Time Exceeded 0 – hop limit exceeded in transit

1 – fragment reassembly time exceeded

4 Parameter Problem 0 – erroneous header field encountered

1 – unrecognized Next Header type encountered

2 – unrecognized IPv6 option encountered

 

Type Number Type Name Code
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  
131 Multicast Listener Report  
132 Multicast Listener

Done

 
133 Router Solicitation  
134 Router

Advertisement

 
135 Neighbor Solicitation  
136 Neighbor

Advertisement

 
137 Redirect Message  
138 Router

Renumbering

0 – Router Renumbering Command

1 – Router Renumbering Result

255 – Sequence Number Reset

 

Type Number Type Name Code
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

Solicitation

Message

 
142 Inverse Neighbor

Discovery

Advertisement

Message

 
143 Version 2 Multicast Listener Report  
144 Home Agent

Address Discovery

Request Message

 
145 Home Agent

Address Discovery

Reply Message

 
146 Mobile Prefix

Solicitation

 
147 Mobile Prefix Advertisement  
148 Certification Path

Solicitation

Message

 

 

Type Number Type Name Code
149 Certification Path

Advertisement

Message

 
150 ICMP messages

utilized by experimental 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

 

IP

Internet Protocol (IP) is the primary part of the Network Layer of the OSI Model that is responsible for routing traffic across network boundaries. It is the protocol that is responsible for addressing. IPv4 is probable the version that most people are familiar with and it has been around since 1974. IPv6 is its current successor and due to a shortage of available IPv4 addresses compared to the explosive increase in the number of devices that use IP addresses, IPv6 is rapidly increasing in use.

When IP is chosen as the protocol type the available option to further specify the protocol is the protocol number.

This is used to narrow down which protocol within the Internet Protocol Suite and provide a more granular control.


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!

Services and TCP ports

Services and TCP ports

There are a number of different services and protocols in use on the Internet. The most commonly known is HTTP which is used by web servers to transmit requests and responses for unencrypted web pages. These services are set up to listen for requests on a numbered port. These services and protocols can use any port from 1 to 65,535. To keep things simple for everyone a large number of the more commonly used services started using a standardized list of ports. For instance, though it is not required, by default, most web servers listen for HTTP requests on port 80 and by default, web browsers will send HTTP traffic to port 80. If you wish to use another port such as 8080 you would put “:8080” at the end of the URL to indicate that you want the browser to use 8080 instead of the default port.

Example

Default URL for HTTP traffic when the web server is listening on the standard HTTP port: http://fortinet.com

URL to the same address when the web server is listening for HTTP traffic on port 8080 http://fortinet.com:8080

Services represent typical traffic types and application packets that pass through the FortiGate unit. Firewall services define one or more protocols and port numbers associated with each service. Security policies use service definitions to match session types. You can organize related services into service groups to simplify your security policy list.

Many well-known traffic types have been predefined on the FortiGate unit. If there is a service that does not appear on the list you can create a service or edit an existing one. You need to know the ports, IP addresses or protocols of that particular service or application uses, to create a service.

Best Practices

While you can edit a predefined service it is best to leave those ones alone and create a new service and name it something similar such as the same service name with a descriptive identifier appended.

Based on the previous example, instead of the name “HTTP” you could name the service “HTTP8080” or use the application that is using that port, “HTTP-Application”.


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!

NAT

NAT

NAT or Network Address Translation is the process that enables a single device such as a router or firewall to act as an agent between the Internet or Public Network and a local or private network. This “agent”, in real time, translates the source IP address of a device on one network interface, usually the Internal, to a different IP address as it leaves another interface, usually the interface connected to the ISP and the Internet. This enables a single public address to represent a significantly larger number of private addresses.

The origins of NAT

In order to understand NAT it helps to know why it was created. At one time, every computer that was part of a network had to have it’s own addresses so that the other computers could talk to it. There were a few protocols in use at the time, some of which were only for use on a single network, but of those that were routable, the one that had become the standard for the Internet was IP (Internet Protocol) version 4.

When IP version 4 addressing was created nobody had any idea how many addresses would be needed. The total address range was based on the concept of 2 to the 32nd power, which works out to be 4 294 967 296 potential addresses. Once you eliminate some of those for reserved addresses, broadcast addresses, network addresses, multicasting, etc., you end up with a workable scope of about 3.2 million addressees. This was thought to be more than enough at the time. The designers were not expecting the explosion of personal computing, the World Wide Web or smart phones. As of the beginning of 2012, some estimate the number of computers in the world in the neighborhood of 1 billion, and most of those computer users are going to want to be on the Internet or Search the World Wide Web. In short, we ran out of addresses.

This problem of an address shortage was realized before we actually ran out, and in the mid 1990s 2 technical papers called RFCs numbered 1631 (http://www.ietf.org/rfc/rfc1631.txt) and 1918

(http://tools.ietf.org/html/rfc1918), proposed components of a method that would be used as a solution until a new addressing methodology could be implemented across the Internet infrastructure. For more information on this you can look up IP version 6.

RFC 1631 described a process that would allow networking devices to translate a single public address to multiple private IP addresses and RFC 1918 laid out the use of the private addresses. The addresses that were on the Internet (Public IP addresses) could not be duplicated for them to work as unique addresses, but behind a firewall, which most large institutions had, they could use their own Private IP addresses for internal use and the internal computers could share the external or Public IP address.

To give an idea on a small scale how this works, image that a company has a need for 200 computer addresses. Before Private IP addresses and NAT the company would have purchased a full Class C address range which would have been 254 usable IP addresses; wasting about 50 addresses. Now with NAT, that company only needs 1 IP address for its 200 computers and this leaves the rest of the IP addresses in that range available for other companies to do the same thing.

NAT gives better value than it would first appear because it is not 253 companies that can use 254 addresses but each of those 254 companies could set up their networking infrastructures to use up to thousands of Private IP addresses, more if they don’t all have to talk to the Internet at the same time. This process enabled the Internet to keep growing even though we technically have many more computers networked than we have addresses.

Dynamic NAT

Dynamic NAT maps the private IP addresses to the first available Public Address from a pool of possible Addresses. In the FortiGate firewall this can be done by using IP Pools.

Overloading

This is a form of Dynamic NAT that maps multiple private IP address to a single Public IP address but differentiates them by using a different port assignment. This is probably the most widely used version of NAT. This is also referred to as PAT (Port Address Translation) or Masquerading.

An example would be if you had a single IP address assigned to you by your ISP but had 50 or 60 computers on your local network.

NAT

Say the internal address of the interface connected to the ISP was 256.16.32.65 (again an impossible address) with 256.16.32.64 being the remote gateway. If you are using this form of NAT any time one of your computers accesses the Internet it will be seen from the Internet as 256.16.32.65. If you wish to test this go to 2 different computers and verify that they each have a different private IP address then go to a site that tells you your IP address such as www.ipchicken.com. You will see that the site gives the same result of 256.16.32.65, if it existed, as the public address for both computers.

As mentioned before this is sometimes called Port Address Translation because network device uses TCP ports to determine which internal IP address is associated with each session through the network device. For example, if you have a network with internal addresses ranging from 192.168.1.1 to 192.168.1.255 and you have 5 computers all trying to connect to a web site which is normally listening on port 80 all of them will appear to the remote web site to have the IP address of 256.16.32.65 but they will each have a different sending TCP port, with the port numbers being somewhere between 1 and 65 535, although the port numbers between 1 to 1024 are usually reserved or already in use. So it could be something like the following:

192.168.1.10    256.16.32.65:   port 486

192.168.1.23    256.16.32.65:   port 2409

192.168.1.56    256.16.32.65:   port 53763

192.168.1.109 256.16.32.65:   port 5548

192.168.1.201 256.16.32.65:   port 4396

And the remote web server would send the responding traffic back based on those port numbers so the network device would be able to sort through the incoming traffic and pass it on to the correct computer.

Overlapping

Because everybody is using the relative same small selection of Private IP addresses it is inevitable that there will be two networks that share the same network range that will need to talk with each other. This happens most often over Virtual Private Networks or when one organization ends up merging with another. This is a case where a private IP address may be translated into a different private IP address so there are no issues with conflict of addresses or confusion in terms of routing.

An example of this would be when you have a Main office that is using an IP range of 172.16.0.1 to

172.20.255.255 connecting through a VPN to a recently acquired branch office that is already running with an IP range of 172.17.1.1 to 172.17.255.255. Both of these ranges are perfectly valid but because the Branch office range is included in the Main Office range any time the system from the Main office try to connect to an address in the Branch Office the routing the system will not send the packet to the default gateway because according to the routing table the address is in its own subnet.

The plan here would be to NAT in both directions so that traffic from neither side of the firewall would be in conflict and they would be able to route the traffic. Everything coming from the Branch Office could be assigned an address in the 192.168.1.1 to 192.168.1.255 range and everything from the Main office going to the Branch Office could be assigned to an address in the 192.168.10.1 to 192.168.10.255 range.

Static NAT

In Static NAT one internal IP address is always mapped to the same public IP address.

In FortiGate firewall configurations this is most commonly done with the use of Virtual IP addressing.

An example would be if you had a small range of IP addresses assigned to you by your ISP and you wished to use one of those IP address exclusively for a particular server such as an email server.

Say the internal address of the Email server was 192.168.12.25 and the Public IP address from your assigned addresses range from 256.16.32.65 to 256.16.32.127. Many readers will notice that because one of the numbers NAT

is above 255 that this is not a real Public IP address. The Address that you have assigned to the interface connected to your ISP is 256.16.32.66, with 256.16.32.65 being the remote gateway. You wish to use the address of 256.16.32.70 exclusively for your email server.

When using a Virtual IP address you set the external IP address of 256.16.32.70 to map to 192.168.12.25. This means that any traffic being sent to the public address of 256.16.32.70 will be directed to the internal computer at the address of 192.168.12.25

When using a Virtual IP address, this will have the added function that when ever traffic goes from 192.168.12.25

to the Internet it will appear to the recipient of that traffic at the other end as coming from 256.16.32.70.

You should note that if you use Virtual IP addressing with the Port Forwarding enabled you do not get this reciprocal effect and must use IP pools to make sure that the outbound traffic uses the specified IP address.

Benefits of NAT

More IP addresses available while conserving public IP addresses

As explained earlier, this was the original intent of the technology and does not need to be gone into further.

Financial savings

Because an organization does not have to purchase IP addresses for every computer in use there is a significant cost savings due to using the process of Network Address Translation.

Security enhancements

One of the side benefits of the process of NAT is an improvement in security. Individual computers are harder to target from the outside and if port forwarding is being used computers on the inside of a firewall are less likely to have unmonitored open ports accessible from the Internet.

Ease of compartmentalization of your network

With a large available pool of IP addresses to use internally a network administrator can arrange things to be compartmentalized in a rational and easily remembered fashion and networks can be broken apart easily to isolate for reasons of network performance and security.

Example

You have a large organization that for security reasons has certain departments that do not share network resources.

You can have the main section of the organization set up as follows;

Network Devices 192.168.1.1 to 192.168.1.25
Internal Servers 192.168.1.26 to 192.168.1.50
Printers 192.168.1.51 to 192.168.1.75

NAT

Administration Personnel 192.168.1.76 to 192.168.1.100
Sales People 192.168.1.101 to 192.168.1.200
Marketing 192.168.1.201 to 192.168.1.250

You could then have the following groups broken off into separate subnets:

Accounting 192.168.100.1 to 192.168.100.255
Research and Development 172.16.1.1 to 172.16.255.255
Executive Management 192.168.50.1 to 192.168.50.255
Web sites and Email Servers 10.0.50.1 to 10.0.50.255

These addresses do not have to be assigned right away but can be used as planned ranges.

NAT in transparent mode

Similar to operating in NAT mode, when operating a FortiGate unit in transparent mode you can add security policies and:

l Enable NAT to translate the source addresses of packets as they pass through the FortiGate unit. l Add virtual IPs to translate destination addresses of packets as they pass through the FortiGate unit. l Add IP pools as required for source address translation

A FortiGate unit operating in transparent mode normally has only one IP address – the management IP. To support NAT in transparent mode, you can add a second management IP. These two management IPs must be on different subnets. When you add two management IP addresses, all FortiGate unit network interfaces will respond to connections to both of these IP addresses.

Use the following steps to configure NAT in transparent mode:

  1. Add two management IPs
  2. Add an IP pool to the WAN1 interface
  3. Add an Internal to WAN1 security policy

You can add the security policy from the web-based manager and then use the CLI to enable NAT and add the IP pool.

The usual practice of NATing in transparent mode makes use of two management IP addresses that are on different subnets, but this is not an essential requirement in every case.

If there is a router between the client systems and the FortiGate unit you can use the router’s capabilities of tracking sessions to assign NATed addresses from an IP pool to the clients even if the assigned address don’t belong to a subnet on your network.

 

Example

Client computer has an IP address of 1.1.1.33 on the subnet 1.1.1.0/24.

Router “A” sits between the client computer and the FortiGate (in transparent mode) with the IP address of

1.1.1.1 on the client’s side of the router and the IP address of 192.168.1.211 on the FortiGate’s side of the router.

Use NAT to assign addresses from an address pool of 9.9.9.1 to 9.9.9.99 to traffic coming from gateway of 192.168.1.211.

To enable the return traffic to get to the original computer, set up a static route than assigns any traffic with a destination of 9.9.9.0/24 to go through the 192.168.1.211 gateway. As long as the session for the outgoing traffic has been maintained, communication between the client computer and the external system on the other side of the FortiGate will work.

Central NAT table

The central NAT table enables you to define, and control with more granularity, the address translation performed by the FortiGate unit. With the NAT table, you can define the rules which dictate the source address or address group and which IP pool the destination address uses.

While similar in functionality to IP pools, where a single address is translated to an alternate address from a range of IP addresses, with IP pools there is no control over the translated port. When using the IP pool for source NAT, you can define a fixed port to guarantee the source port number is unchanged. If no fix port is defined, the port translation is randomly chosen by the FortiGate unit. With the central NAT table, you have full control over both the IP address and port translation.

The FortiGate unit reads the NAT rules in a top-down methodology, until it hits a matching rule for the incoming address. This enables you to create multiple NAT policies that dictate which IP pool is used based on the source address. The NAT policies can be rearranged within the policy list as well. NAT policies are applied to network traffic after a security policy.

NAT64 and NAT46

NAT64 and NAT46 are the terms used to refer to the mechanism that allows IPv6 addressed hosts to communicate with IPv4 addressed hosts and vice versa. Without such a mechanism an IPv6 node on a network such as a corporate LAN would not be able to communicate with a web site that was still in a IPv4 only environment and IPv4 environments would not be able to connect to IPv6 networks.

One of these setups involves having at least 2 interfaces, 1 on an IPv4 network and 1 on an IPv6 network. The NAT64 server synthesizes AAAA records, used by IPv6 from A records used by IPv4. This way client-server and peer to peer communications will be able to work between an IPv6 only client and an IPv4 server without making changes to either of the end nodes in the communication transaction. The IPv6 network attached to the FortiGate unit should be a 32 bit segment, (for instance 64:ff9b::/96, see RFC 6052 and RFC 6146). IPv4 address will be embedded into the communications from the IPv6 client.

Because the IPv6 range of addresses is so much larger than the IPv4 range, a one to one mapping is not feasible. Therefore the NAT64 function is required to maintain any IPv6 to IPv4 mappings that it synthesizes. This can be done either statically by the administrator or automatically by the service as the packets from the IPv6 network go through the device. The first method would be a stateless translation and the second would be a stateful translation. NAT64 is designed for communication initiated from IPv6 hosts to IPv4 addresses. It is address mapping like this that allows the reverse to occur between established connections. The stateless or manual method is an appropriate solution when the NAT64 translation is taking place in front of legacy IPv4 servers to allow those specific servers to be accessed by remote IPv6-only clients. The stateful or automatic solution is best used closer to the client side when you have to allow some specific IPv6 clients to talk to any of the IPv4-only servers on the Internet.

There are currently issues with NAT64 not being able to make everything accessible. Examples would be SIP, Skype, MSN, Goggle talk, and sites with IPv4 literals. IPv4 literals being IPv4 addresses that are imbedded into content rather than a FQDN.

Policies that employ NAT64 or NAT46 can be configured from the web-based manager as long as the feature is enabled using the Features setting found at System > Config > Features.

l To create a NAT64 policy go to Policy & Objects > NAT64 Policy and select Create New. l To create a NAT46 policy go to Policy > NAT46 Policy and select Create New.

The difference between these NAT policies and regular policies is that there is no option to use the security profiles and sensors.

NAT64 CLAT traffic is now supported by the FortiGate. CLAT traffic comes from devices that use the SIIT translator that plays a part in affecting IPv6 – IPv4 NAT translation.

NAT64 CLAT

NAT64 CLATtraffic is supported by FortiOS. CLAT traffic comes from devices that use the SIIT translator that plays a part in affecting IPv6 – IPv4 NAT translation.

NAT66

NAT66 is Network Address Translation between 2 IPv6 network. The basic idea behind NAT66 is no different than the regular NAT between IPv4 networks that we are all used to. The difference are in the mechanics of how it is performed, mainly because of the complexity and size of the addresses that are being dealt with.

In an IPv4 world, the reason for the use of NAT was usually one or a combination of the following 3 reasons:

  • Improved security – actual addresses behind NAT are virtually hidden l Amplification of addresses – hundreds of computers can use as little as a single public IP address
  • Internal address stability – there is control of internal addressing. The addresses can stay the same even if Internet Service Providers change.

In these days of security awareness the protective properties of NAT are not something that are not normally depended on by themselves to defend a network and with the vastly enlarged IPv6 address scope there is no longer a need to amplify the available addresses. However, the desire to have internal address control still exists. The most common reason for using NAT66 is likely to be the maintaining of the existing address scheme of the internal network despite changes outside of it. Imagine that you have an internal network of 2000 IP addresses and one day the company changes its ISP and thus the addresses assigned to it. Even if most of the addressing is handled by DHCP, changing the address scheme is going to have an impact on operations.

Addressing stability can be achieved by:

  • Keeping the same provider – this would depend on the reason for the change. If the cost of this provider has become too expensive this is unlikely. If the ISP is out of business it becomes impossible.
  • Transfer the addresses from the old provider to the new one – There is little motivation for an ISP to do you a favor for not doing business with them.
  • Get your own autonomous system number – this can be too expensive for smaller organizations. l NAT – this is the only one on the list that is in the control of IT.

There are differences between NAT66 and IPv4 NAT. Because there is no shortage of addresses most organizations will be given a /48 network that can be translated into another /48 network. This allows for a one to one translation, no need for port forwarding. This is a good thing because port forwarding is more complicated in IPv6. In fact, NAT66 will actually just be the rewriting of the prefix on the address.

Example

If your current IPv6 address is

2001:db8:cafe::/48 you could change it to

2001:db8:fea7::/48

There is an exception to the one to one translation. NAT66 cannot translate internal networks that contain 0xffff in bits 49 through 63 – this is due to the way checksums are calculated in TCP/IP: they use the one’s-complement representation of numbers which assigns the value zero to both 0x0000 and 0xffff.

How FortiOS differentiates sessions when NATing

The basics of NAT are fairly simple. Many private addresses get translated into a smaller number of public addresses, often just one. The trick is how the FortiGate keeps track of the return traffic because the web server, or what ever device that was out on the Internet is going to be sending traffic back not to the private address behind the FortiGate but to the IP address of the interface on the public side of the FortiGate.

The way this is done is by making each session unique. Most of the attributes that are available in the network packets cannot be changed without changing where the packet will go but because the source port has to be changed anyway in case two computer on the network used the same source port this is a useful way of making each listing of network attributes a unique combination. As a packet goes through the NAT process FortiOS assigns different source ports for each of the internally initiated sessions and keeping track of which port was used for each device in a database until the session has ended. It then becomes a matter of how the port number is selected.

In a very simple example of an environment using NAT, we will use a fictitious university with a rather large student population. So large in fact that they use a subnet of 10.0.0.0/8 as their subnet for workstation IP addresses. All of these private IP addresses are NATed out a single IP address. To keep the number of numeric values in this example from getting to a confusing level, we’ll just us “u.u.u.1” to refer to the public IP address of the University and the IP address of the web server on the Internet will be “w.w.w.1”.

Student A (IP address 10.1.1.56) sends an HTML request to a web server on the Internet with the IP address w.w.w.1. The applicable networking information in the packet breaks down as follows:

Attribute Original Packet Packet after NATing
Source IP address or src-ip 10.1.1.56 u.u.u.1
Destination IP address or dst-ip: w.w.w.1 w.w.w.1
Attribute Original Packet Packet after NATing
Source port or src-port: 10000 46372
Destination port or dst-port 80 80

The source IP address is now that of the public facing interface of the FortiGate and source port number is an unused TCP port number on the FortiGate chosen by the FortiGate. Of these variable the only one the that FortiGate can really change and still have the packet reach the correct destination, in both directions, is the source port number.

There are a few methods of assigning the port number. First we’ll look at the methods that are or have been used in the industry but aren’t used by Fortinet.

Global pool

This method of differentiation focuses on the attribute of the source port number. In this approach a single pool of potential port numbers is set aside for the purposes of NAT. As a pool number is assigned, it is removed from the pool so that two sessions from different computers can not using the same port number. Once the session is over and no longer in use by the computer, the port number is put back into the pool where it can be assigned again.

Example global pool:

  Hexidecimal Decimal
Start or range 0x7000 28672
End end of range 0xF000 61440
Possible ports in range 215 32768

This is a simple approach to implement and is good if the number of connections in unlike to reach the pool size. It would be okay for home use, but our example is for a university using 10.1.1.0/8 as a subnet. That means 16,777,214 possible IP addresses; more than this method can handle.

Fortinet does not use this method.

Global per protocol

This method uses the attributes source port number and type of protocol to differentiate between sessions.This approach is a variation of the first one. An additional piece of information is refered to in the packet that describes the protocol. For instance UDP or TCP. This could effectively double the number of potential addresses to NAT.

Example:

Here are two possible packets that would be considered different by the FortiGate so that any responses from the web server would make it back to their correct original sender.

From Student A

Attribute Original Packet Packet after NATing
Source IP address or src-ip 10.1.1.56 u.u.u.1
Destination IP address or dst-ip: w.w.w.1 w.w.w.1
Protocol tcp tcp
Source port or src-port: 10000 46372
Destination port or dst-port 80 80

From Student B

Attribute Original Packet Packet after NATing
Source IP address or src-ip 10.5.1.233 u.u.u.1
Destination IP address or dst-ip: w.w.w.1 w.w.w.1
Protocol udp udp
Source port or src-port: 26785 46372
Destination port or dst-port 80 80

Even though the source port is the same, because the protocol is different they are considered to be from different sessions and different computers.

The drawback is that it would depend on the protocols being used be evenly distributed between TCP and UDP.

Even if this was the case the number would only double; reaching an upper limit of 65,536 possible connections. That number is still far short of the possible more than 16 million for an IP subnet with an eight bit subnet mask like the one in our example.

Fortinet does not use this method.

Per NAT IP pool

This approach adds on to the previous one by adding another variable. In this case that variable is the IP addresses on the public side of the FortiGate. By having a pool of IP addresses to assign as the source IP address when NATing, the same number that was potentially available for the Global per protocol method can be multiplied by the number of external IP addresses in the pool. If you can assign a second IP address to the pool, you can double the potential number of sessions.

Example:

In this example it will be assumed that the FortiGate has 2 IP addresses that it can use. This could happen either by using two ISPs, or by having a pool of IP addresses assigned to a single interface. For simplicity will will refer to these IP public IP addresses as u.u.u.1 and u.u.u.2.

Here are two possible packets that would be considered different by the FortiGate so that any responses from the web server would make it back to their correct original sender.

From Student A

Attribute Original Packet Packet after NATing
Source IP address or src-ip 10.1.1.56 u.u.u.1
Destination IP address or dst-ip: w.w.w.1 w.w.w.1
Protocol tcp tcp
Source port or src-port: 10000 46372
Destination port or dst-port 80 80

From Student B

Attribute Original Packet Packet after NATing
Source IP address or src-ip 10.5.1.233 u.u.u.2
Destination IP address or dst-ip: w.w.w.1 w.w.w.1
Protocol tcp tcp
Source port or src-port: 26785 46372
Destination port or dst-port 80 80

In this example we even made the protocl the same. After the NATing process all of the variables are the same except the sourse addresss. This is still going to make it bake to the original sender.

The drawback is that if you have only one IP address for the purposes of NATing this method does not gain you anything over the last method. Or if you do have multiple IP addresses to use it will still take quite a few to reach the 16 million possible that the subnet is capable of handling.

Fortinet does not use this method.

Per NAT IP, destination IP, port, and protocol

This is the approach that FortiOS uses.

It uses all of the differentiation point of the previous methods, NAT IP, port number and protocol, but the additonal information point of the destination IP is also used. So now the network information points in the packet that the FortiGate keeps in its database to differentiate between sessions is:

l Public IP address of the FortiGate assigned by NATing l Protocol of the traffic l Source port assigned by the FortiGate l Destination IP address of the packet

The last one is an especially good way to differentiate because as a theortical number, the upper limit on that is the numbers of Public IP addresses on the whole of the Internet. Chances are that while a large number of session from inside the University will be going to a small group of sites such as Google, Youtube, Facebook and some others it is unlikely that they will all be going to them at the same time.

Example:

In this example it will be assumed that the FortiGate has only one IP address.Two possible packets will be described. The only difference in the attributes recorded will be the destination of the HTML request.These packets are still considered to be from differnt sessions and any responses will make it back to the correct computer.

From Student A

Attribute Original Packet Packet after NATing
Source IP address or src-ip 10.1.1.56 u.u.u.1
Destination IP address or dst-ip: w.w.w.1 w.w.w.1
Protocol tcp tcp
Source port or src-port: 10000 46372
Destination port or dst-port 80 80

From Student B

Attribute Original Packet Packet after NATing
Source IP address or src-ip 10.5.1.233 u.u.u.1
Destination IP address or dst-ip: w.w.w.2 w.w.w.2
Protocol tcp tcp
Source port or src-port: 26785 46372
Destination port or dst-port 80 80

The reason that these attributes are used to determine defferentiation between traffic is based on how the indexes for the sessions are recorded in the database. When a TCP connection is made through a FortiGate unit, a session is created and two indexes are created for the session. The FortiGate unit uses these indexes to guide matching traffic to the session.

This following could be the session record for the TCP connection in the first example.

Attribute Outgoing Traffic Returning Traffic
Source IP address 10.78.33.97 (internal address) w.w.w.1
Destination address w.w.w.1 u.u.u.1
Protocol tcp tcp
Source port 10000 (from original computer)

46372 (assigned by NAT)

80
Destination port 80 46372 (FortiGate assigned port)

Using the FortiGate’s approach for session differentiation, FortiOS only has to ensure that the assigned port, along with the other four attributes is a unique combination to identify the session. So for example, if Student A simultaneously makes a HTTP(port 80) connection and a HTTPS(port 443) connection the same web server this would create another session and the index in the reply direction would be:

Attribute Outgoing Traffic Returning Traffic
Source IP address 10.78.33.97 (internal address) w.w.w.1
Destination address w.w.w.1 u.u.u.1
Protocol tcp tcp
Source port 10000 (from original computer)

46372 (assigned by NAT)

443
Destination port 443 46372 (FortiGate assigned port)

These two sessions are different and acceptable because of the different source port numbers on the returning traffic or the destination port depending on the direction of the traffic.

Calculations for possible session numbers

The result of using these four attributes instead of just the one that was originally used is a large increase in the number of possible unique combinations.For those who love math, the maximum number of simultaneous connections that can be supported is:

N x R x P x D x Dp where:

  • N is the number of NAT IP addresses
  • R is the port range,

 

IP pools

  • P is the number of protocols, l D is the number of unique destination IP addresses l Dp the number of unique destination ports. As a rough example let’s do some basic calculations l N – In our existing example we have already stated that there is only one public IP address that is being used by NAT. Realistically, for a university this number would likely be larger, but we’re keeping it simple.

N = 1

R – The port range for our example has already been describe and we will keep it the same.

R = 32768

P – While there are a few protocols that are involved in Internet traffic we will limit this calculation just to TCP traffic.

P = 1

D – As mentioned before the number of unique destination addresses is growing larger every day,so figureing out the upper limit of that numbe would be difficult to say the least. Instead we will make the assumption that most of the university students, do to their shared interest and similar demographic will concentrate most of their web browsing to the same sites; sites such as YouTube, Facebook, Google, Twitter, Instagram, Wikipedia etc. This is not even taking into account the fact that many of these popular sites use load balancing and multiple IP addresses. As an arbatrary number let’s use the number 25.

D = 25

Dp – To keep things simple it is tempting to limit the destiation port to port 80, the one that many associate with web browsing, but this would not be realistic. the use of HTTPS, port 443 is on the rise. There is also email, DNS, FTP, NTP and a number of other background services that we use without thinking too closely about. Let’s keep it small and say ten of them.

Dp = 10

The math on this very conservative calculation is:

1 x 32768 x 1 x 25 x 10 = 8,192,000 possible NAT sessions

When you take into account that the chances of everybody being online at the same time, going only to one of those 25 sites and not millions of others, and using only TCP not UDP or any of the other protocols, it starts to look like this method may provide enough potential unique sessions even for a subnet as large as the one described.

IP pools

IP Pools are a mechanism that allow sessions leaving the FortiGate Firewall to use NAT. An IP pool defines a single IP address or a range of IP addresses to be used as the source address for the duration of the session.

These assigned addresses will be used instead of the IP address assigned to that FortiGate interface.

IP pools

When using IP pools for NATing, there is a limitation that must be taken into account. In order for communication to be successful in both directions, it is normal for the source address in the packet header assigned by the NAT process to be an address that is associated with the interface that the traffic is going through. For example, if traffic is going out an interface with the IP address 172.16.100.1, packets would be NATed so that the source IP address would be 172.16.100.1. This way the returning traffic will be directed to the same interface on the same FortiGate that the traffic left from. Even if the packets are assigned a source address that is associated with another interface on the same FortiGate this can cause issues with asymmetrical routing. It is possible to configure the NATed source IP address to be different than the IP address of the interface but you have to make sure that the routing rules of the surrounding network devices take this unorthodox approach into consideration.

There are 4 types of IP Pools that can be configured on the FortiGate firewall:

  • One-to-One – in this case the only internal address used by the external address is the internal address that it is mapped to.
  • Overload – this is the default setting. Internal addresses other than the one designated in the policy can use this address for the purposes of NAT.
  • Fixed Port Range – rather than a single address to be used, there is a range of addresses that can be used as the NAT address. These addresses are randomly assigned as the connections are made.
  • Port Block Allocation – this setting is used to allocate a block of port numbers for IP pool users. Two variables will also have to be set. The block size can be set from 64 to 4096 and as the name implies describes the number of ports in one block of port numbers. The number of blocks per user determines how many of these blocks will be assigned. This number can range from 1 to 128.

Be careful when calculating the values of the variables. The maximum number of ports that are available on an address is 65,536. If you chose the maximum value for both variables you will get a number far in excess of the available port numbers.

4096 x 128 = 524,288

One of the more common examples is when you have an email server behind your FortiGate firewall and the range of IP addresses assigned to you by your ISP is more than one. If an organization is assigned multiple IP addresses it is normally considered a best practice to assign a specific address other than the one used for the Firewall to the mail server. However, when normal NAT is used the address assigned to the firewall is also assigned to any outbound sessions. Anti-spam services match the source IP address of mail traffic that they receive to the MX record on DNS servers as an indicator for spam. If there is a mismatch the mail may not get through so there is a need to make sure that the NATed address assigned matches the MX record.

You can also use the Central NAT table as a way to configure IP pools.

Source IP address and IP pool address matching when using a range

When the source addresses are translated to an IP pool that is a range of addresses, one of the following three cases may occur:

Scenario 1:

The number of source addresses equals that of IP pool addresses

IP pools

In this case, the FortiGate unit always matches the IP addressed one to one.

If you enable fixed port in such a case, the FortiGate unit preserves the original source port. This may cause conflicts if more than one security policy uses the same IP pool, or the same IP addresses are used in more than one IP pool.

Scenario 2:

The number of source addresses is more than that of IP pool addresses

In this case, the FortiGate unit translates IP addresses using a wrap-around mechanism. If you enable fixed port in such a case, the FortiGate unit preserves the original source port. But conflicts may occur since users may have different sessions using the same TCP 5 tuples.

Scenario 3:

The number of source addresses is fewer than that of IP pool addresses

In this case, some of the IP pool addresses are used and the rest of them are not be used.

ARP replies

If a FortiGate firewall interface IP address overlaps with one or more IP pool address ranges, the interface responds to ARP requests for all of the IP addresses in the overlapping IP pools. For example, consider a FortiGate unit with the following IP addresses for the port1 and port2 interfaces:

  • port1 IP address: 1.1.1.1/255.255.255.0 (range is 1.1.1.0-1.1.1.255) l port2 IP address: 2.2.2.2/255.255.255.0 (range is 2.2.2.0-2.2.2.255) And the following IP pools:
  • IP_pool_1: 1.1.1.10-1.1.1.20 l IP_pool_2: 2.2.2.10-2.2.2.20 l IP_pool_3: 2.2.2.30-2.2.2.40

The port1 interface overlap IP range with IP_pool_1 is:

(1.1.1.0-1.1.1.255) and (1.1.1.10-1.1.1.20) = 1.1.1.10-1.1.1.20

The port2 interface overlap IP range with IP_pool_2 is:

(2.2.2.0-2.2.2.255) & (2.2.2.10-2.2.2.20) = 2.2.2.10-2.2.2.20 The port2 interface overlap IP range with IP_pool_3 is:

(2.2.2.0-2.2.2.255) & (2.2.2.30-2.2.2.40) = 2.2.2.30-2.2.2.40 And the result is:

  • The port1 interface answers ARP requests for 1.1.1.10-1.1.1.20
  • The port2 interface answers ARP requests for 2.2.2.10-2.2.2.20 and for 2.2.2.30-2.2.2.40

Select Enable NAT in a security policy and then select Dynamic IP Pool. Select an IP pool to translate the source address of packets leaving the FortiGate unit to an address randomly selected from the IP pool. Whether or not the external address of an IP Pool will respond to an ARP request can be disabled. You might want to disable the ability to responded to ARP requests so that these address cannot be used as a way into your network or show up on a port scan.

 

IP pools and zones

Because IP pools are associated with individual interfaces IP pools cannot be set up for a zone. IP pools are connected to individual interfaces.

Fixed port

Some network configurations do not operate correctly if a NAT policy translates the source port of packets used by the connection. NAT translates source ports to keep track of connections for a particular service.

However, enabling the use of a fixed port means that only one connection can be supported through the firewall for this service. To be able to support multiple connections, add an IP pool, and then select Dynamic IP pool in the policy. The firewall randomly selects an IP address from the IP pool and assigns it to each connection. In this case, the number of connections that the firewall can support is limited by the number of IP addresses in the IP pool.

Match-VIP

The match-vip feature allows the FortiGate unit to log virtual IP traffic that gets implicitly dropped. This feature eliminates the need to create two policies for virtual IPs; one that allows the virtual IP, and the other to get proper log entry for DROP rules.

For example, you have a virtual IP security policy and enabled the match-vip feature; the virtual IP traffic that is not matched by the policy is now caught.

The match-vip feature is available only in the CLI. By default, the feature is disabled.


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!

RPC over HTTP

RPC over HTTP

How protocol options profiles and SSL inspection profiles handle RPC (Remote Procedure Calls) over HTTP traffic can be configured separately from normal HTTP traffic. The configuration is done in the CLI.

Configuration in protocol options

config firewall profile-protocol-options edit 0 set rpc-over-http [disable|enable] end

Configuration in SSL/SSH inspection

config firewall ssl-ssh-profile edit deep inspection set rpc-over-http [disable|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!

Encryption strength for proxied SSH sessions

Encryption strength for proxied SSH sessions

The level of SSH encryption can be set for SSH sessions on a per-profile basis.

 

RPC over HTTP

Encryption Level Description
compatible This level allows for a broader set of encryption algorithms to be used and is better for compatibility.
highencryption This level will only allow AES-CTR, AES-GCM and high encryption algorithms to be used for the session.

Syntax:

config firewall ssl-ssh-profile edit <profile name> config ssh set ssh-algorithm {compatible|high-encryption} end

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!