Category Archives: FortiOS

FortiOS Carrier and MMS duplicate messages and message floods

Leave a reply

FortiOS Carrier and MMS duplicate messages and message floods

FortiOS Carrier detects duplicate messages and message floods for the MM1 and MM4 interfaces. How FortiOS Carrier detects and responds to duplicate messages and message floods is different from how FortiOS Carrier detects and responds to viruses and other MMS scanning protection measures.

For message floods and duplicate messages, the sender does not receive notifications about floods or duplicate messages, as if the sender is an attacker they can gain useful information about flood and duplicate thresholds. Plus, duplicate messages and message floods are usually a result of a large amount of messaging activity and filtering of these messages is designed to reduce the amount of unwanted messaging traffic. Adding to the traffic by sending notifications to senders and receivers could result in an increase in message traffic.

You can create up to three thresholds for detecting duplicate messages and message floods. For each threshold you can configure the FortiOS Carrier unit to respond by logging the activity, archiving or quarantining the messages, notifying administrators of the activity, and by blocking the messages. In many cases you may only want to configure blocking for higher activity thresholds, and to just monitor and send administrator notifications at lower activity thresholds.

When a block threshold is reached for MM1 messages, FortiOS Carrier sends m-send.conf or m-retrieve.conf messages to the originator of the activity. These messages are sent to end the MM1 sessions, otherwise the originator would continue to re-send the blocked message. When a block threshold is reached for MM4, FortiOS Carrier sends a MM4-forward.res message to close the MM4 session. An MM4 message is sent only if initiated by the originating MM4-forward.req message.

MM1 message flood and duplicate message blocking of sent messages
Sender FortiOS Carrier

MMSC
1. Open TCP session

2. Open TCP session
3. m-send.req

4. Flood or duplicate blocked
5. Reset TCP session

6. m-send.conf replacement message
7. Close TCP Session

8. Notification message to administrators (various protocols)

Sent once per notification period, regardless of how many messages are blocked

MM1 message flood and duplicate message blocking of received messages
MMSC

FortiOS Carrier

Receiver
1. GET request for message
2. GET request for message
3. m-retrieve.conf mesage

4. Flood or duplicate blocked

6. Notification message to administrators (various protocols)

Sent once per notification period, regardless of how many messages are blocked
5. m-retrieve.conf replacement message

MM4 message flood and duplicate message blocking

Forwarding Operator
MMSC

FortiOS Carrier

Receiving Operator
MMSC
1. Open TCP session
2. Open TCP session

3. Send full MM4-forward.req message
5. m-retrieve.conf mesage
4. Send full MM4-forward.req message

Without ‘.’ on single line

6. Flood or duplicate blocked

7. Reset TCP session
8. Send 250 response
9. Close TCP session
10. Open new TCP session
11. Send MM4-forward.res message 10, 11, 12 Only initiated if the
MM4-forward.req message
12. Close TCP session

requested a response
13. Notification message to administrators (various protocols)

Sent once per notification period, regardless of how many messages are blocked


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!

FortiOS Carrier and MMS content scanning

Leave a reply

FortiOS Carrier and MMS content scanning

The following section applies to MMS content scanning, including virus scanning, file filtering, content spam filtering, carrier endpoint filtering, and MMS content checksum filtering.

MM1 Content Scanning

During MM1 content scanning a message is first transmitted from the sender, establishing a connection with the MMSC. FortiOS Carrier intercepts this connection and acts as the endpoint. FortiOS Carrier then establishes its own connection to the MMSC. Once connected, the client transmits its m-send.req HTTP post request to FortiOS Carrier which scans it according to the MMS protection profile settings. If the content is clean, the message is forwarded to the MMSC. The MMSC returns m-send.conf HTTP response through FortiOS Carrier to the sender.

If FortiOS Carrier blocks the message (for example because a virus was found, see the figure below), FortiOS Carrier resets the connection to the MMSC and sends m-send.conf HTTP response back to the sender. The response message can be customized using replacement messages. FortiOS Carrier then terminates the connection. Sending back an m-send.conf message prevents the sender from trying to send the message again.

MM1 MMS scanning of message sent by sender (blocking m.send.req messages)
Sender FortiOS Carrier

MMSC

1. Open TCP session

2. Open TCP session

3. m-send.req

4. Content blocked

6. m-send.conf replacement message

5. Reset TCP session

7. Close TCP Session

8. m-send.rec notification message to sender
(MM1 or MM7/SOAP payload, by configuration)

Sent once per notification period, regardless of how many messages are blocked

9. Notification message to administrators (various protocols)

Sent once per notification period, regardless of how many messages are blocked

FortiOS Carrier also sends m-send.rec notifications messages to the MMSC that are then forwarded to the sender to notify them of blocked messages.

Filtering message retrieval

FortiOS Carrier intercepts the connection to the MMSC, and the m-retrieve.conf HTTP response from the MMSC is scanned according to the MMS content scanning settings. If the content is clean, the response is forwarded back to the client. If the content is blocked, FortiOS Carrier drops the connection to the MMSC. It then builds an m-retrieve.conf message from the associated replacement message and transmits this back to the client.

FortiOS Carrier also sends m-send.rec notifications messages to the MMSC that are then forwarded to the receiver to notify them of blocked messages.

MM1 MMS scanning of messages received by receiver (blocking m.retrieve.conf messages)
MMSC

FortiOS Carrier

Receiver
1. GET request for message

2. GET request for message
3. m-retrieve.conf mesage

4. Content blocked

6. m-send.rec notification message to sender
(MM1 or MM7/SOAP payload, by configuration)

5. m-retrieve.conf replacement message

Sent once per notification period, regardless of how many messages are blocked

7. Notification message to administrators (various protocols)

Sent once per notification period, regardless of how many messages are blocked

Filtering MM3 and MM4 messages works in an similar way to MM1 (see the figures below). FortiOS Carrier intercepts connections to the MMSC, and scans messages as configured. When messages are blocked, FortiOS Carrier closes sessions as required, sends confirmation messages to the sender, notifies administrators, and notifies senders and receivers of messages.

MM3 MMS scanning of messages sent from a sender on the Internet to an MMSC

Internet

Sender on the Internet

1. Open TCP session

FortiOS Carrier

2. Open TCP session

MMSC
3. Send full email message
3. m-retrieve.conf mesage

4. Send full email message

Without ‘.’ on single line
5. Content blocked
7. Send 550 Error and replacement message

6. Reset TCP session
8. Close TCP session
9. MM3 notification message

Sent once per notification period, regardless of how many messages are blocked
10. Notification message to administrators (various protocols)

Sent once per notification period, regardless of how many messages are blocked

MM4 MMS scanning of messages sent between operator MMSCs
Sending Operator
MMSC

FortiOS Carrier

Receiving Operator
MMSC
1. Open TCP session
2. Open TCP session

3. Send full MM4-forward.req message
5. m-retrieve.conf mesage

4. Send full MM4-forward.req message

Without ‘.’ on single line

6. Content blocked
8. Send 250 response

7. Reset TCP session
9. Close TCP session
10. Open new TCP session

11. Send MM4-forward.res message

12. Close TCP session
10, 11, 12 Only initiated if the MM4-forward.req message requested a response

13. MM4-forward.req notification

Sent once per notification period, regardless of how many messages are blocked

14. Notification message to administrators (various protocols)

Sent once per notification period, regardless of how many messages are blocked

MM7 MMS scanning of messages sent between a VASP and an MMSC
Sending
VASP

FortiOS Carrier

Receiving
MMSC
1. Open TCP session
2. Open TCP session
3. submit.req or delivery.req

4. Content blocked

6. submit.resp/delivery.resp replacement message

5. Reset TCP session
7. Close TCP session
8. submit.req/delivery.req notification message

Sent once per notification period, regardless of how many messages are blocked

9. Notification message to administrators (various protocols)

Sent once per notification period, regardless of how many messages are blocked


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!

How FortiOS Carrier processes MMS messages

Leave a reply

How FortiOS Carrier processes MMS messages

MMS messages can be vectors for propagating undesirable content such as spam and viruses. FortiOS Carrier can scan MMS messages sent using the MM1, MM3, MM4, and MM7 content interfaces. You can configure FortiOS Carrier to scan MMS messages for spam and viruses by configuring and adding MMS protection profiles and adding the MMS protection profiles to security policies. You can also use MMS protection profiles to apply content blocking, carrier endpoint filtering, MMS address translation, sending MMS notifications, DLP archiving of MMS messages, and logging of MMS message activity.

 

FortiOS Carrier MMS processing

FortiOS Carrier can send MMS messages to senders informing those senders that their devices are infected. FortiOS Carrier can also send MMS notifications to administrators to inform them of suspicious activity on their networks.

For message floods and duplicate messages, FortiOS Carrier does not send notifications to message senders but does send notifications to administrators and sends messages to sender handsets to complete MM1 and MM4 sessions.

 

Where MMS messaging uses the TCP/IP set of protocols, SMS text messaging uses the Signaling System Number 7 (SS7) set of protocols, which is not supported by FortiOS.


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!

Chapter 6 – FortiOS Carrier

Leave a reply

Chapter 6 – FortiOS Carrier

This FortiOS Handbook chapter contains the following sections:

  • Overview of FortiOS Carrier features provides an overview of the three major topics for FortiOS Carrier — Dynamic Profiles, MMS, and GTP.
  • Carrier web-based manager settings describes the web-based manager interface of FortiOS Carrier specific features.
  • MMS Security features describes FortiOS security features as they apply to MMS including MMS virus scanning, MMS file filtering, MMS content-based Antispam protection, and MMS DLP archiving.
  • Message flood protection describes setting thresholds to protect your MMS servers from receiving too many messages from the same sender.
  • Duplicate message protection describes setting thresholds to protect your MMS servers from receiving the same message from more than one sender.
  • Configuring GTP on FortiOS Carrier explains configuration of the more basic FortiOS Carrier GTP features. GTP message type filtering explains this feature, and how to configure it on FortiOS Carrier.
  • GTP identity filtering explains this feature, and how to configure it on FortiOS Carrier. Troubleshooting provides answer to common FortiOS Carrier GTP issues.

 

Overview of FortiOS Carrier features

FortiOS Carrier specific features include Multimedia messaging service (MMS) protection, and GPRS Tunneling Protocol (GTP) protection.

All FortiGate units, carrier-enabled or not, are capable of handling Stream Control Transmission Protocol (SCTP) traffic, which is a protocol designed for and primarily used in Carrier networks. This section includes:

  • Overview
  • Registering FortiOS Carrier
  • MMS background
  • How FortiOS Carrier processes MMS messages
  • MMS protection profiles
  • Bypassing MMS protection profile filtering based on carrier endpoints
  • Applying MMS protection profiles to MMS traffic
  • GTP basic concepts
  • GPRS network common interfaces Packet flow through the GPRS network SCTP

 

 

Overview

FortiOS Carrier provides all the features found on FortiGate units plus added features specific to carrier networks: MMS and GTP.

 

MMS

MMS is a standard for sending messages that include multimedia content between mobile phones. MMS is also popular as a method of delivering news and entertainment content including videos, pictures, and text. Carrier networks include four different MMS types of messages — MM1, MM3, MM4, and MM7. See “MMS background”.

 

GTP

The GPRS Tunneling Protocol (GTP) runs on GPRS carrier networks. GPRS is a GSM packet radio standard. It provides more efficient usage of the radio interface so that mobile devices can share the same radio channel. FortiOS supports GTPv1 and GTPv2.

GPRS provides direct connections to the Internet (TCP/IP) and X.25 networks for point-to-point services (connection-less/connection oriented) and point-to-multipoint services (broadcast).

GPRS currently supports data rates from 9.6 kbps to more than 100 kbps, and it is best suited for burst forms of traffic. GPRS involves both radio and wired components. The mobile phone sends the message to a base station unit (radio based) that converts the message from radio to wired, and sends the message to the carrier network and eventually the Internet (wired carrier network). See GTP basic concepts.

 

Registering FortiOS Carrier

A license is purchased from Fortinet, and is delivered by mail as a scratch card. The contained registration code is entered into the CLI according to the instructions on the card. The FortiGate unit will then factory reset itself into Carrier mode.

Only certain FortiGate models support Carrier mode. Contact Fortinet Support for more information and firmware images.

 

MMS background

MMS is a common method for mobile users to send and receive multimedia content. A Carrier network supports MMS across its network. This makes up the MMS Service Provider Network (MSPN).

Messages can be sent or received between the MMSC and a number of other services including the Internet, content providers, or other carriers. Each of these different service connections uses different MMS formats including MM1 and MM7 messages (essentially HTTP format), and MM3 and MM4 messages (SMTP formatted). These different formats reflect the different purposes and content for each type of MMS message.

 

 

MMS content interfaces

MMS messages are sent from devices and servers to other devices and servers using MMS content interfaces

There are eight interfaces defined for the MMS standard, referred to as MM1 through MM8. The most important of these interfaces for the transfer of data is the MM1 interface, as this defines how mobile users communicate from the mobile network to the Multimedia Message Service Center (MMSC). MMS content to be monitored and controlled comes from these mobile users and is going to the provider network.

Other MMS content interfaces that connect a service provider network to other external sources can pose threats as well. MM3 handles communication between the Internet and the MMSC and is a possible source of viruses and other content problems from the Internet. MM4 handles communication between different content provider MMSCs. Filtering MM4 content protects the service provider network from content sent from foriegn service providers and their subscribers. Finally MM7 is used for communication between content providers and the MMSC. Filtering MM3 content can also keep harmful content off of the service provider network.

 

MMS content interfaces

 

Type Transaction Similar to
 

MM 1

  

Handset to MMSC

  

HTTP
 

MM 3

  

Between MMSC and Internet

  

SMTP
 

MM 4

  

Between Operator MMSCs

  

SMTP
 

MM 7

  

Content Providers to MMSC

  

HTTP and SOAP

 

How MMS content interfaces are applied

As shownbelow, the sender’s mobile device encodes the MMS content in a form similar to MIME email message (MMS MIME content formats are defined by the MMS Message Encapsulation specification). The encoded message is then forwarded to the service provider’s MMSC. Communication between the sending device and the MMSC uses the MM1 content interface. The MM1 content interface establishes a connection and sends an MM1 send request (m-send.req) message that contains the MMS message. The MMSC processes this request and sends back an MM1 send confirmation (m-send.conf) HTTP response indicating the status of the message — accepted or an error occurred, for example.

 

MM1 transactions between senders and receivers and the MMSC

Sender

(sends MMS message

to receiver)

MMSC

Receiver (receives MMS message from sender)

1. m-send.req (contains the MMS message and is directed to the URI of the MMSC)

3. m-send.conf (confirms message receipt and handles any error conditions, also includes transaction identity)

2. m-notification.req (indicates mesage is available for delivery, includes size, expiry and URI)

4. m-notifyresp.ind (WSP/HTTP POST to confirm receipt of notification)

5. WSP/HTTP GET.req

(Requests the MM.content)

6. m-retrieve.conf (the MMS content)

8. m-delivery.ind (optional, confirms delivery of MMS content)

7. m-acknowledge.ind (if requested, optional acknowledgment of receipt of MMS content)

 

If the recipient is on another carrier, the MMSC forwards the message to the recipient’s carrier. This forwarding uses the MM4 content interface for forwarding content between operator MMSCs (see the figure below).

Before the MMSC can forward the message to the final recipient, it must first determine if the receiver’s handset can receive MMS messages using the MM1 content interface. If the recipient can use the MM1 content interface, the content is extracted and sent to a temporary storage server with an HTTP front-end.

To retrieve the message, the receiver’s handset establishes a connection with the MMSC. An HTTP get request is then sent from the recipient to the MMSC. This message contains the URL where the content of the message is stored. The MMSC responds with a retrieve confirmation (m-retrieve.conf) HTTP response that contains the message.

 

MM4 messages sent between operator MMSCs

Sending Operator

MMSC

Receiving Operator

MMSC

1. MM4-forward.req (contains the MMS content and is directed to the receiving MMSC. X-MMS headers contain MMS extensions)

2. MM4-forward.res (administrative message to confirm transaction with status code)

3. MM4-delivery-report.req (feedback required by UA pr VASP)

4. MM4-delivery_report.res (response to feedback request with status codes)

 

This causes the receiver’s handset to retrieve the content from the embedded URL. Several messages are exchanged to indicate status of the delivery attempt. Before delivering content, some MMSCs also include a content adaptation service that attempts to modify the multimedia content into a format suitable for the recipient’s handset.

If the receiver’s handset is not MM1 capable, the message can be delivered to a web based service and the receiver can view the content from a normal Internet browser. The URL for the content can be sent to the receiver in an SMS text message. Using this method, non-MM1 capable recipients can still receive MMS content.

The method for determining whether a handset is MMS capable is not specified by the standards. A database is usually maintained by the operator, and in it each mobile phone number is marked as being associated with a legacy handset or not. It can be a bit hit and miss since customers can change their handset at will and this database is not usually updated dynamically.

Email and web-based gateways from MMSC to the Internet use the MM3 content interface. On the receiving side, the content servers can typically receive service requests both from WAP and normal HTTP browsers, so delivery via the web is simple. For sending from external sources to handsets, most carriers allow MIME encoded message to be sent to the receiver’s phone number with a special domain.


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

Logging and reporting

Leave a reply

Logging and reporting

The default log device settings must be modified so that system performance is not compromised. The FortiGate unit, by default, has all logging of FortiGate features enabled, except for traffic logging. The default logging location will be either the FortiGate unit’s system memory or hard disk, depending on the model. Units with a flash disk are not recommended for disk logging.

 

Log management

When the FortiGate unit records FortiGate activity, valuable information is collected that provides insight into how to better protect network traffic against attacks, including misuse and abuse. There is a lot to consider before enabling logging on a FortiGate unit, such as what FortiGate activities to enable and which log device is best suited for your network’s logging needs. A plan can help you in deciding the FortiGate activities to log, a log device, as well as a backup solution in the event the log device fails.

 

This plan should provide you with an outline, similar to the following:

  • What FortiGate activities you want and/or need logged (for example, security features).
  • The logging device best suited for your network structure.
  • If you want or require archiving of log files.
  • Ensuring logs are not lost in the event a failure occurs.

After the plan is implemented, you need to manage the logs and be prepared to expand on your log setup when the current logging requirements are outgrown. Good log management practices help you with these tasks.

Log management practices help you to improve and manage logging requirements. Logging is an ever-expanding tool that can seem to be a daunting task to manage. The following management practices will help you when issues arise, or your logging setup needs to be expanded.

  • Revisit your plan on a yearly basis to verify that your logging needs are being met by your current log setup. For example, your company or organization may require archival logging, but not at the beginning of your network’s lifespan. Archival logs are stored on a FortiGate unit’s local hard drive, a FortiAnalyzer unit, or a FortiCloud server, in increasing order of size.
  • Configure an alert message that will notify you of activities that are important to be aware about. For example: if a branch office does not have a FortiGate administrator, you will need to know at all times that the IPsec VPN tunnel is still up and running. An alert email notification message can be configured to send only if IPsec tunnel errors occur.
  • If your organization or company uses peer-to-peer programs such as Skype or other instant messaging software, use the IM usage dashboard widget or the Executive Summary’s report widget (Top 10 Application Bandwidth Usage Per Hour Summary) to help you monitor the usage of these types of instant messaging software. These widgets can help you in determining how these applications are being used, including if there is any misuse and abuse. Their information is taken from application log messages; however, application log messages should be viewed as well since they contain the most detailed information.
  • Ensure that your backup solution is up-to-date. If you have recently expanded your log setup, you should also review your backup solution. The backup solution provides a way to ensure that all logs are not lost in the event that the log device fails or issues arise with the log device itself.
  • When downloading log messages and viewing them on a computer, the log file will be downloaded like any other file. Log file names contain their log type and date in the name, so it is recommended to create a folder in which to archive your log messages, as they can be sorted easily.

 

System memory and hard disks

If the FortiGate unit has a hard disk, it is enabled by default to store logs. This also means that you do not have to enable this and configure the settings for logging to the hard disk, but modify these settings so that it is configured for your network logging requirements.

If the FortiGate unit has only flash memory, disk logging is disabled by default, as it is not recommended. Constant rewrites to flash drives can reduce the lifetime and efficiency of the memory. It must be enabled in the CLI under config log disk setting.

For some low-end models, disk logging is unavailable. Check a product’s Feature Matrix for more information. In either case, Fortinet recommends using either a FortiAnalyzer unit or the FortiCloud service.

 


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!

Wireless

Leave a reply

Wireless

The following section contains a list of best practices for wireless network configurations with regard to encryption and authentication, geographic location, network planning, power usage, client load balancing, local bridging, SSIDs, and the use of static IPs.

 

 

Encryption and authentication

It is best practice to always enable the strongest user authentication and encryption method that your client supports. Fortinet recommends the following security, in order of strongest to weakest:

  • WPA2 – Enterprise 802.1x/EAP – Personal pre-shared key (8-63 characters)
  • WPA – Enterprise 802.1x/EAP – Personal pre-shared key (8-63 characters)
  • WEP128 – 26 Hexadecimal digit key
  • WEP64 – 10 Hexadecimal digit key
  • None – Open system

 

Geographic location

Ensure that the FortiGate wireless controller is configured for your geographic location. This ensures that the available radio channels and radio power are in compliance with the regulations in your region.

The maximum allowed transmitter power and permitted radio channels for Wi-Fi networks depend on the region in which the network is located. By default, the WiFi controller is configured for the United States. If you are located in any other region, you need to set your location before you begin configuring wireless networks.

The location setting can only be changed from CLI. To change the country to France, for example, enter the following:

config wireless-controller setting set country FR

end

To see the list of country codes, enter a question mark (‘?’) in place of the country code.

Using an incorrect geographic location is a common error that can lead to unpredicable results on the client side.

 

Network planning

It is recommended that you perform a proper site survey prior positioning the wireless access point. In order to evaluate the coverage area environment, the following criteria must be taken into account:

  • Size of coverage area
  • Bandwidth required
  • Client wireless capabilities

After completing a RF site survey, you’ll have a good idea of the number and location of access points needed to provide users with adequate coverage and performance.

However, prior to installing the access points, be sure to determine the RF channel(s) you plan to use. This will ensure that users can roam throughout the facility with substantial performance.

To avoid co-channel interference, adjacent Wi-Fi APs must be configured to use non-overlapping channels. Otherwise, you’ll find poor performance will degrade because of interference between access points.

It is recommended to statically configure the non-overlapping channels on every access point, using one Custom AP profile per AP (or group of APs). If static configuration cannot be used, the FortiOS Wi-Fi Controller includes the Automatic Radio Resource Provisioning (ARRP) feature.

 

Lowering the power level to reduce RF interference

Relevant Product(s): FortiAP

Reducing power reduces unwanted coverage and potential interference to other WLANs. Areas of unwanted coverage are a potential security risk. If possible, reduce the transmitter power of your wireless access point so that the signal is not available beyond the areas where it is needed. Auto Tx Power Control can be enabled to automatically adjust the transmit power.

In cases where customers complain about slow wireless traffic through a FortiAP, it might be necessary to try to reduce the possibility of RF interference. It is best practice not to locate FortiAPs near steel beams or other interfering materials. You can try using a wireless sniffer tool to collect the wireless packets and then analyze the extent of air interference.

A common mistake is spacing FortiAPs based upon the 5Ghz radio frequency. The 2.4Ghz signal travels further. You have two options when confronted with slow wireless traffic through a FortiAP:

Option #1: Reducing transmit power

Perform a speed test and record the results. Set one of the radios on a FortiAP to be in dedicated monitoring mode. Then observe how many APs are detected. If the number of APs is too high (i.e., greater than 20), try reducing the transmit power in the WTP profile for the FortiAPs until the number of dedicated APs has dropped significantly.

Repeat the speed test.

 

Option #2: Ensuring that VAPs are distributed over the available channels

No built-in tools are available to measure RF interference directly. However, FortiOS 5.0 does allow for automatic power adjustment, which should minimize the occurrence of RF interference.

 

Wireless client load balancing

Wireless load balancing allows your wireless network to more efficiently distribute wireless traffic among wireless access points and available frequency bands. FortiGate wireless controllers support the following types of client load balancing:

  • Access Point Hand-off – The wireless controller signals a client to switch to another access point.
  • Frequency Hand-off – The wireless controller monitors the usage of 2.4GHz and 5GHz bands, and signals clients to switch to the lesser-used frequency.

 

Local bridging

Whenever possible, use local bridging to offload the CAPWAP tunnel. Note that in this case, Wi-Fi client devices obtain IP addresses from the same DHCP server as wired devices on the LAN. The vlan ID can only be configured

from the CLI:

config wireless-controller vap edit “vaplocalbridge”

set vdom “root”

set ssid “testvaplocalbridge” set local-bridging enable

set vlanid 40 —> only available in CLI

next end

 

Advertising SSIDs

  • It is highly recommended to advertise the SSID. It makes it easier for customers and wireless clients. Also, if you ‘hide’ the SSID (known as ‘network cloaking’), then clients will always look for it when they’re outside the coverage area, which searches for known SSIDs, in effect leaking the SSID anyway. Refer to RFC 3370. Furthermore, many of the latest Broadcom drivers do not support hidden SSID for WPA2.
  • For security reason, you might want to prevent direct communication between your wireless clients. In this case, enable Block Intra-SSID Traffic (in the SSID configuration).
  • In a network with multiple wireless controllers, you need to change the mesh SSID so that each mesh root has a unique SSID. Other controllers using the same mesh root SSID might be detected as fake or rogue APs. Go to WiFi & Switch Controller > SSID to change the SSID. Fortinet also recommends that you create a new preshared key instead of using the default.

 

Using static IPs in a CAPWAP configuration

In a large FortiAP deployment with more than 20 FortiAPs connecting to a Fortigate Wireless Controller (AC), it is recommended to use static IPs on the access points instead of DHCP, setting the AC IP statically and the AC discovery type to static (Type 1), instead of learning it through broadcast, multicast, or DHCP.

This makes management of the APs easier since you know the exact IP of each access point. Troubleshooting also becomes easier as the debug of the AC controller won’t continuously attempt the different discovery methods in sequence (broadcast > multicast > static).

 


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!

Explicit proxy

Leave a reply

Explicit proxy

  • For explicit proxies, when configuring limits on the number of concurrent users, you need to allow for the number of users based on their authentication method. Otherwise you may run out of user resources prematurely.
  • Each session-based authenticated user is counted as a single user using their authentication membership (RADIUS, LDAP, FSSO, local database etc.) to match users in other sessions. So one authenticated user in multiple sessions is still one user.
  • For all other situations, the source IP address is used to determine a user. All sessions from a single source address are assumed to be from the same user.
  • Set the explicit web proxy and explicit FTP proxy Default Firewall Policy Action to Deny. This means that a firewall policy is required to use these explicit proxies, allowing you to control access and impose security features.
  • Do not enable the explicit web or FTP proxy on an interface connected to the Internet. This is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address. If you must enable the proxy on such an interface make sure authentication is required to use the proxy.

 


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!

Virtual Domains (VDOMs)

Leave a reply

Virtual Domains (VDOMs)

VDOMs can provide separate firewall policies and, in NAT/Route mode, completely separate configurations for routing and VPN services for each connected network or organization. This section provides a list of best practices for configuring VDOMs.

 

Per–VDOM resource settings

While Global resources apply to resources shared by the whole FortiGate unit, per-VDOM resources are specific to only one Virtual Domain.

By default all the per-VDOM resource settings are set to no limits. This means that any single VDOM can use up all the resources of the entire FortiGate unit if it needs to do so. This would starve the other VDOMs for resources to the point where they would be unable to function. For this reason, it is recommended that you set some maximums on resources that are most vital to your customers.

 

Virtual domains in NAT/Route mode

Once you have enabled virtual domains and created one or more VDOMs, you need to configure them. It is recommended that you perform the following tasks in the order given (while you may not require all for your network topology):

1. Change the management virtual domain.

2. Configure FortiGate interfaces in a NAT/Route VDOM.

3. Configure VDOM routing.

4. Configure security policies for NAT/Route VDOMs.

5. Configure UTM profiles for NAT/Route VDOMs.

6. Test the configuration.

 

Virtual clustering

If you decide to disable override for clurstering, as a result of persistent renegotiating, you should disable it for both cluster units.

 


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!