SIP request messages

SIP sessions always start with a SIP request message (also just called a SIP request). SIP request messages also establish, maintain, and terminate SIP communication sessions. The following table lists some common SIP request message types.

 

Common SIP request message types

Message Type         Description

INVITE                       A client sends an INVITE request to invite another client to participate in a multimedia session. The INVITE request body usually contains the description of the session.

ACK

The originator of an INVITE message sends an ACK request to confirm that the final response to an INVITE request was received. If the INVITE request did not contain the session description, it must be included in the ACK request.

PRACK                      In some cases, SIP uses provisional response messages to report on the progress of the response to a SIP request message. The provisional response messages are sent before the final SIP response message. Similar to an ACK request message, a PRACK request message is sent to acknowledge that a provisional response message has been received.

OPTIONS

The UA uses OPTIONS messages to get information about the capabilities of a SIP proxy. The SIP proxy server replies with a description of the SIP methods, session description protocols, and message encoding that are supported.

BYE                           A client sends a BYE request to end a session. A BYE request from either end of the SIP session terminates the session.

CANCEL

A client sends a CANCEL request to cancel a previous INVITE request. A CANCEL request has no effect if the SIP server processing the INVITE sends a final response to the INVITE before receiving the CANCEL.

REGISTER                A client sends a REGISTER request to a SIP registrar server with information about the current location (IP address and so on) of the client. A SIP registrar server saves the information it receives in REGISTER requests and makes this information avail- able to any SIP client or server attempting to locate the client.

Info                            For distributing mid-session signaling information along the signaling path for a SIP call. I

Subscribe                 For requesting the current state and state updates of a remote node.

Notify                        Informs clients and servers of changes in state in the SIP network.

Refer                         Refers the recipient (identified by the Request-URI) to a third party according to the contact information in the request.

Message Type         Description

Update                      Opens a pinhole for new or updated SDP information.

Response codes (1xx, 202, 2xx, 3xx, 4xx, 5xx, 6xx)

Indicates the status of a transaction. For example: 200 OK, 202 Accepted, or 400 Bad Request.

SIP messages and media protocols

This section provides an overview of SIP messages and how they communicate information about SIP sessions and how SDP, RTP, and RTCP fits in with SIP communications.

SIP uses clear text messages to start, maintain, and end media sessions between SIP user agent clients (UACs) and user agent servers (UASs). These messages form a SIP dialog. A typical SIP dialog begins with an INVITE request message sent from a UAC to another UAC or to a UAS. The first INVITE request message attempts to start a SIP call and includes information about the sending UAC and the receiving UAC as well as information about the communication session.

If only two UACs are involved as shown below, the receiving UAC (Phone B) responds with a 180 Ringing and then a 200 OK SIP response message that informs Phone A that Phone B received and accepted the request. Phone A then sends an ACK message to notify Phone B that the SIP response was received. Phone A and Phone B can then participate in the RTP media session set up by the SIP messages.

When the phone call is complete, one of the UACs (in the example Phone B) hangs up sending a BYE request message to Phone A. Phone A then sends a 200 OK response to Phone B acknowledging that the session has ended.

 

Basic SIP dialog between two UACs

SIP Phone A (Sending UAC PhoneA@10.31.101.20)

SIP Phone B (Receiving UAC PhoneB@10.31.101.30)

1. 1. INVITE (SIP request message to invite SIP Phone B to start a SIP session)

2. 2. 180 Ringing (SIP ringing response to the INVITE request)

3. 3. 200 OK (SIP response to the INVITE request to inform SIP Phone A that the request is accepted)

4. 4. ACK (SIP request message to confirm that SIP Phone A received the response from SIP Phone B)

5. 5. RTP Media session between Phone A and Phone B.

6. 6. BYE (SIP request message from SIP Phone B to end the SIP session)

7. 7. 200 OK (SIP response to the BYE request to end the SIP session)

 

If a UAS in the form of a SIP proxy server is involved, similar messages are sent and received, but the proxy server participates as an intermediary in the initial call setup. In the example below the SIP proxy server receives the INVITE request from Phone A and forwards it to Phone B. The proxy server then sends a 100 Trying response to Phone A. Phone B receives the INVITE request and responds with a 180 Ringing and then a 200 OK SIP response message. These messages are received by the proxy server and forwarded to Phone A to notify Phone A that Phone B received and accepted the request. Phone A then sends an ACK message to notify Phone B that the SIP response was received. This response is received by the proxy server and forwarded to Phone B. Phone A and Phone B can then participate in the media session independently of the proxy server.

When the phone call is complete Phone B hangs up sending a BYE request message to Phone A. Phone A then sends a 200 OK response to Phone B acknowledging that the session has ended.

 

Basic SIP dialog between UACs with a SIP proxy server UAS

SIP Phone A (Sending UAC PhoneA@10.31.101.20)

SIP Proxy Server

(UAS

10.31.101.40)

SIP Phone B (Receiving UAC PhoneB@10.31.101.30)

1. 1. INVITE (SIP request message to invite SIP Phone B to start a SIP session)

3. 3. 100 Trying (UAS informs Phone A of trying to contact Phone B)

2. 2. INVITE (Forwarded by the UAS to Phone B)

5. 5. 180 Ringing (Forwarded by the UAS to Phone A)

4. 4. 180 Ringing (SIP ringing response to the INVITE request)

7. 7. 200 OK (Forwarded by the UAS to Phone A)

6. 6. 200 OK (SIP response to the INVITE request to inform SIP Phone A that the request is accepted)

8. 8. ACK (SIP request message to confirm that SIP Phone A received the response from SIP Phone B)

9. 9. RTP Media session between Phone A and Phone B.

10. 10. BYE (SIP request message from SIP Phone B to end the SIP session)

11. 11. 200 OK (SIP response to the BYE request to end the SIP session)

The SIP messages include SIP headers that contain names and addresses of Phone A, Phone B and the proxy server. This addressing information is used by the UACs and the proxy server during the call set up.

The SIP message body includes Session Description Protocol (SDP) statements that Phone A and Phone B use to establish the media session. The SDP statements specify the type of media stream to use for the session (for example, audio for SIP phone calls) and the protocol to use for the media stream (usually the Real Time Protocol (RTP) media streaming protocol).

Phone A includes the media session settings that it would like to use for the session in the INVITE message. Phone B includes its response to these media settings in the 200 OK response. Phone A’s ACK response confirms the settings that Phone A and Phone B then use for the media session.

 

Hardware accelerated RTP processing

FortiGate units can offload RTP packet processing to network processor (NP) interfaces. This acceleration greatly enhance the overall throughput and resulting in near speed RTP performance.

SIP with a FortiGate unit

Depending on your security requirements and network configuration FortiGate units may be in many different places in a SIP configuration. This section shows a few examples.

The diagram below shows a FortiGate unit installed between a SIP proxy server and SIP phones on the same network. The FortiGate unit is operating in Transparent mode so both the proxy server and the phones are on the same subnet. In this configuration, called SIP inspection without address translation, the FortiGate unit could be protecting the SIP proxy server on the private network by implementing SIP security features for SIP sessions between the SIP phones and the SIP proxy server.

 

SIP network with FortiGate unit in Transparent mode

1. SIP phones register with SIP proxy server

SIP Phone A (PhoneA@10.31.101.20)

2. Phone A dials Phone B by sending an INVITE request to the SIP proxy server

5. RTP media session opens when Phone B answers

SIP Phone B (PhoneB@10.31.101.30)

FortiGate unit

in Transparent mode

SIP proxy server

10.31.101.50

4. Phone B is notified of incoming call by proxy server

– phone rings

3. The proxy server looks up the SIP address of Phone B and forwards the INVITE request to Phone B

The phones and server use the same SIP dialogs as they would if the FortiGate unit was not present. However, the FortiGate unit can be configured to control which devices on the network can connect to the SIP proxy server and can also protect the SIP proxy server from SIP vulnerabilities.

The following diagram shows a FortiGate unit operating in NAT/Route mode and installed between a private network and the Internet. Some SIP phones and the SIP proxy server are connected to the private network and some SIP phones are connected to the Internet. The SIP phones on the Internet can connect to the SIP proxy server through the FortiGate unit and communication between SIP phones on the private network and SIP phones on the Internet must pass through the FortiGate unit.

 

SIP network with FortiGate unit in NAT/Route mode

FortiGate-620B Cluster In NAT/Route mode

 

00

Port2

10.11.101.1

 

P rt1

Po 172.20.

72.20 120.141

SIP proxy server

Virtual IP: 172.20.120.50

 

SIP Phone A (PhoneA@10.31.101.20)

SIP proxy server

10.31.101.50

 

1. SIP phone B registers with

 

SIP Phone B

1. SIP phone A registers with

SIP proxy server

SIP proxy server

using the SIP proxy server virtual IP

(PhoneB@172.20.120.30)

2. Phone A dials Phone B

by sending an INVITE request to the SIP proxy server

3. The proxy server looks up the SIP address of Phone B and forwards the INVITE request to Phone B

4. Phone B is notified of incoming call by proxy server – phone rings

5. RTP Media session opens when between Phone A and Phone B whe Phone B answers

 

The phones and server use the same SIP dialog as they would if the FortiGate unit was not present. However, the FortiGate unit can be configured to control which devices on the network can connect to the SIP proxy server and can also protect the SIP proxy server from SIP vulnerabilities. In addition, the FortiGate unit has a firewall virtual IP that forwards packets sent to the SIP proxy server Internet IP address (172.20.120.50) to the SIP proxy server internal network IP address (10.31.101.30).

Since the FortiGate unit is operating in NAT/Route mode it must translate packet source and destination IP addresses (and optionally ports) as the sessions pass through the FortiGate unit. Also, the FortiGate unit must translate the addresses contained in the SIP headers and SDP body of the SIP messages. As well the FortiGate unit must open SIP and RTP pinholes through the FortiGate unit. SIP pinholes allow SIP signalling sessions to pass through the FortiGate between phones and between phones and SIP servers. RTP pinholes allow direct RTP communication between the SIP phones once the SIP dialog has established the SIP call. Pinholes are opened automatically by the FortiGate unit. Administrators do not add security policies for pinholes or for RTP sessions. All that is required is a security policy that accepts SIP traffic.

Opening an RTP pinhole means opening a port on a FortiGate interface to allow RTP traffic to use that port to pass through the FortiGate unit between the SIP phones on the Internet and SIP phones on the internal network. A pinhole only accepts packets from one RTP session. Since a SIP call involves at least two media streams (one from Phone A to Phone B and one from Phone B to Phone A) the FortiGate unit opens two RTP pinholes. Phone A sends RTP packets through a pinhole in port2 and Phone B sends RTP packets through a pinhole in port1. The FortiGate unit opens the pinholes when required by the SIP dialog and closes the pinholes when the SIP call is completed. The FortiGate unit opens new pinholes for each SIP call.

Each RTP pinhole actually includes two port numbers. The RTP port number as defined in the SIP message and an RTCP port number, which is the RTP port number plus 1. For example, if the SIP call used RTP port 3346 the FortiGate unit would create a pinhole for ports 3346 and 3347.

Common SIP VoIP configurations

This section describes some common SIP VoIP configurations and simplified SIP dialogs for these configurations. This section also shows some examples of how adding a FortiGate unit affects SIP processing.

 

Peer to peer configuration

In the peer to peer configuration shown below, two SIP phones (in the example, FortiFones) communicate directly with each other. The phones send SIP request and response messages back and forth between each other to establish the SIP session.

 

SIP peer to peer configuration

1. Phone A dials Phone B by sending an INVITE request

2. Phone B is notified of incoming call – phone rings SIP Phone A (PhoneA@10.31.101.20)

3. RTP Media session opens when Phone B answers SIP Phone B (PhoneB@10.31.101.30)

Peer to peer configurations are not very common because they require the SIP phones to keep track of the names and addresses of all of the other SIP phones that they can communicate with. In most cases a SIP proxy or re- direct server maintains addresses of a large number of SIP phones and a SIP phone starts a call by contacting the SIP proxy server.

 

SIP proxy server configuration

A SIP proxy server act as intermediary between SIP phones and between SIP phones (for example, two FortiFones) and other SIP servers. As shown below, SIP phones send request and response messages the SIP proxy server. The proxy server forwards the messages to other clients or to other SIP proxy servers. Proxy servers can hide SIP phones by proxying the signaling messages. To the other users on the VoIP network, the signaling invitations look as if they come from the SIP proxy server.

 

SIP in proxy mode

SIP Proxy Server

1. The proxy server looks up the SIP address of Phone B and forwards the INVITE request to Phone B
2. Phone A dials Phone B by sending an INVITE request to the SIP proxy server SIP phones register with SIP proxy server
3. RTP Media session opens when Phone B answers
4. Phone B is notified of incoming call by proxy server – phone rings

 

SIP Phone A                                                                                    SIP Phone B

 

(PhoneA@10.31.101.20)                          (PhoneB@10.31.101.30)

 

A common SIP configuration would include multiple networks of SIP phones. Each of the networks would have its own SIP server. Each SIP server would proxy the communication between phones on its own network and between phones in different networks.

 

SIP redirect server configuration

A SIP redirect server accepts SIP requests, maps the addresses in the request into zero or more new addresses and returns those addresses to the client. The redirect server does not initiate SIP requests or accept calls. As shown below, SIP clients send INVITE requests to the redirect server, which then looks up the destination address. The redirect server returns the destination address to the client. The client uses this address to send the INVITE request directly to the destination SIP client.

 

SIP in redirect model

SIP Redirect Server

The redirect server looks up the SIP address of Phone B and sends Phone B’s address back to Phone A

1. Phone A dials Phone B by sending an INVITE request to the redirect server
2. SIP phones register with SIP redirect server
3. Phone A sends the INVITE request to Phone B
4. RTP Media session opens when Phone B answers
5. Phone B is otified of incoming call by Phone A – phone rings

 

n

SIP Phone A                                                                                   SIP Phone B

 

(PhoneA@10.31.101.20)                        (PhoneB@10.31.101.30)

 

SIP registrar configuration

A SIP registrar accepts SIP REGISTER requests from SIP phones for the purpose of updating a location database with this contact information. This database can then become a SIP location service that can be used by SIP proxy severs and redirect servers to locate SIP clients. As shown below, SIP clients send REGISTER requests to the SIP registrar.

 

 

SIP registrar and proxy servers

SIP Proxy Server

Phone A dials Phone B

by sending an INVITE request to the SIP proxy server

The SIP proxy server looks up Phone A and Phone B on the registrar

Phone B is notified of incoming call by proxy server – phone rings

RTP Media session opens when Phone B answers

SIP Phone A                                                                                 SIP Phone B

 

(PhoneA@10.31.101.20)

(PhoneB@10.31.101.30)

SIP phones register with the SIP registrar

 

FortiGate VM Initial Configuration

Before you can connect to the FortiGate VM web-based manager you must configure a network interface in the FortiGate VM console. Once an interface with administrative access is configured, you can connect to the FortiGate VM web-based Manager and upload the FortiGate VM license file that you downloaded from the Customer Service & Support website.

The following topics are included in this section: Set FortiGate VM port1 IP address

• Connect to the FortiGate VM Web-based Manager
• Upload the FortiGate VM license file
• Validate the FortiGate VM license with FortiManager
• Configure your FortiGate VM

 

Set FortiGate VM port1 IP address

Hypervisor management environments include a guest console window. On the FortiGate VM, this provides access to the FortiGate console, equivalent to the console port on a hardware FortiGate unit. Before you can access the Web-based manager, you must configure FortiGate VM port1 with an IP address and administrative access.

 

To configure the port1 IP address:

1. In your hypervisor manager, start the FortiGate VM and access the console window.

You might need to press Return to see a login prompt.

 

Example of FortiGate VM console access:

2. At the FortiGate VM login prompt enter the username admin. By default there is no password. Just press Return.

3. Using CLI commands, configure the port1 IP address and netmask. Also, HTTP access must be enabled because until it is licensed the FortiGate VM supports only low-strength encryption. HTTPS access will not work.

For example:

config system interface edit port1

set ip 192.168.0.100 255.255.255.0 append allowaccess http

end

You can also use the append allowaccess CLI command to enable other access protocols, such as auto-ipsec, http, probe-response, radius-acct, snmp, and telnet. The ping, https, ssh, and fgfm protocols are enabled on the port1 interface by default.

4. To configure the default gateway, enter the following CLI commands:

config router static edit 1

set device port1

end

set gateway <class_ip>

 

You must configure the default gateway with an IPv4 address. FortiGate VM needs to access the Internet to contact the FortiGuard Distribution Network (FDN) to validate its license.

5. To configure your DNS servers, enter the following CLI commands:

config system dns

set primary <Primary DNS server>

set secondary <Secondary DNS server>

end

The default DNS servers are 208.91.112.53 and 208.91.112.52.

6. To upload the FortiGate VM license from an FTP or TFTP server, use the following CLI command:

execute restore vmlicense {ftp | tftp} <VM license file name> <Server IP or FQDN> [:server port]

 

You can also upload the license in the FortiGate VM Web-based Manager. See Set FortiGate VM port1 IP address on page 2728.

 

Web–based Manager and Evaluation License dialog box

 

Connect to the FortiGate VM Web-based Manager

When you have configured the port1 IP address and netmask, launch a web browser and enter the IP address that you configured for port1. At the login page, enter the username admin and password field and select Login. The default password is no password. The Web-based Manager will appear with an Evaluation License dialog box.

 

Upload the FortiGate VM license file

Every Fortinet VM includes a 15-day trial license. During this time the FortiGate VM operates in evaluation mode. Before using the FortiGate VM you must enter the license file that you downloaded from the Customer Service & Support website upon registration.

 

To upload the FortiGate VM licence file:

1. In the Evaluation License dialog box, select Enter License.

You can also upload the license file via the CLI using the following CLI command:

execute restore vmlicense [ftp | tftp] <filenmame string>

<ftp server>[:ftp port]

The license upload page opens.

 

License upload page:

2. Select Browse and locate the license file (.lic) on your computer. Select OK to upload the license file.

3. Refresh the browser to login.

4. Enter admin in the Name field and select Login. The VM registration status appears as valid in the License Information widget once the license has been validated by the FortiGuard Distribution Network (FDN) or FortiManager for closed networks.

 

Validate the FortiGate VM license with FortiManager

You can validate your FortiGate VM license with some models of FortiManager. To determine whether your FortiManager unit has the VM Activation feature, see Features section of the FortiManager Product Data sheet.

 

To validate your FortiGate VM with your FortiManager:

1. To configure your FortiManager as a closed network, enter the following CLI command on your FortiManager:

config fmupdate publicnetwork set status disable

end

2. To configure FortiGate VM to use FortiManager as its override server, enter the following CLI commands on your

FortiGate VM:

config system central-management set mode normal

set type fortimanager

set fmg <IPv4 address of the FortiManager device>

set fmg-source-ip <Source IPv4 address when connecting to the FortiManager device>

set include-default-servers disable

set vdom <Enter the name of the VDOM to use when communicating with the FortiManager device>

end

3. Load the FortiGate VM license file in the Web-based Manager. Go to System > Dashboard > Status. In the License Information widget, in the Registration Status field, select Update. Browse for the .lic license file and select OK.

4. To activate the FortiGate VM license, enter the following CLI command on your FortiGate VM:

execute update-now

5. To check the FortiGate VM license status, enter the following CLI commands on your FortiGate VM:

get system status

 

The following output is displayed:

Version: Fortigate-VM v5.0,build0099,120910 (Interim) Virus-DB: 15.00361(2011-08-24 17:17)

Extended DB: 15.00000(2011-08-24 17:09) Extreme DB: 14.00000(2011-08-24 17:10) IPS-DB: 3.00224(2011-10-28 16:39)

FortiClient application signature package: 1.456(2012-01-17 18:27) Serial-Number: FGVM02Q105060000

 

License Status: Valid

BIOS version: 04000002

Log hard disk: Available Hostname: Fortigate-VM Operation Mode: NAT

Current virtual domain: root

Max number of virtual domains: 10

Virtual domains status: 1 in NAT mode, 0 in TP mode

Virtual domain configuration: disable

FIPS-CC mode: disable Current HA mode: standalone Distribution: International Branch point: 511

Release Version Information: MR3 Patch 4

System time: Wed Jan 18 11:24:34 2012

diagnose hardware sysinfo vm full

The following output is displayed: UUID: 564db33a29519f6b1025bf8539a41e92 valid: 1

status: 1

code: 200 (If the license is a duplicate, code 401 will be displayed)

warn: 0 copy: 0 received: 45438 warning: 0

recv: 201201201918 dup:

 

Configure your FortiGate VM

nce the FortiGate VM license has been validated you can begin to configure your device. You can use the Wizard located in the top toolbar for basic configuration including enabling central management, setting the admin password, setting the time zone, and port configuration.

For more information on configuring your FortiGate VM see the FortiOS Handbook at http://docs.fortinet.com.

Deployment example – Citrix XenServer

Once you have downloaded the FORTINET.out.CitrixXen.zip file and extracted the files, you can create the virtual machine in your Citrix Xen environment.

The following topics are included in this section:

• Create the FortiGate VM virtual machine (XenCenter)
• Configure virtual hardware

 

Create the FortiGate VM virtual machine (XenCenter)

 

To create the FortiGate VM virtual machine from the OVF file

1. Launch XenCenter on your management computer.

The management computer can be any computer that can run Citrix XenCenter, a Windows application.

2. If you have not already done so, select ADD a server. Enter your Citrix XenServer IP address and the root logon credentials required to manage that server.

Your Citrix XenServer is added to the list in the left pane. The Virtual Machine Manager home page opens.

3. Go to File > Import. An import dialog will appear.

4. Click the Browse button, find the FortiGate-VM64-Xen.ovf template file, then click Open.

5. Select Next.

6. Accept the FortiGate Virtual Appliance EULA, then select Next.

7. Choose the pool or standalone server that will host the VM, then select Next.

8. Select the storage location for FortiGate VM disk drives or accept the default. Select Next.

9. Configure how each vNIC (virtual network adapter) in FortiGate VM will be mapped to each vNetwork on the Citrix XenServer, then click Next.

10. Click Next to skip OS fixup.

11. Select Next to use the default network settings for transferring the VM to the host.

12. Select Finish.

 

The Citrix XenServer imports the FortiGate VM files and configures the VM as specified in the OVF template. Depending on your computer’s hardware speed and resource load, and also on the file size and speed of the network connection, this might take several minutes to complete.

When VM import is complete, the XenCenter left pane includes the FortiGate VM in the list of deployed VMs for your Citrix XenServer.

 

Configure virtual hardware

Before you start your FortiGate-VM for the first time, you need to adjust your virtual machine’s virtual hardware settings to meet your network requirements.

 

Configuring number of CPUs and memory size

Your FortiGate-VM license limits the number CPUs and amount of memory that you can use. The amounts you allocate must not exceed your license limits.

 

To access virtual machine settings

1. Open XenCenter.

2. Select your FortiGate VM in the left pane.

The tabs in the right pane provide access to the virtual hardware configuration. The Console tab provides access to the FortiGate console.

1. To set the number of CPUs

2. In the XenCenter left pane, right-click the FortiGate VM and select Properties.

The Properties window opens.

3. In the left pane, select CPU.

4. Adjust Number of CPUs and then select OK.

XenCenter will warn if you select more CPUs than the Xen host computer contains. Such a configuration might reduce performance.

 

To set memory size

1. In the XenCenter left pane, select the FortiGate VM.

2. In the right pane, select the Memory tab.

3. Select Edit, modify the value in the Set a fixed memory of field and select OK.

 

Configuring disk storage

By default the FortiGate VM data disk 30GB. You will probably want to increase this. Disk resizing must be done before you start the VM for the first time.

 

To resize the FortiGate data disk

1. In the XenCenter left pane, select the FortiGate VM.

2. Select the Storage tab. Select Hard disk 2 (the 30GB drive), then select Properties.

The ‘Hard disk 2’ Properties window opens.

3. Select Size and Location. Adjust Size and select OK.

Deployment example – OpenXen

Once you have downloaded the FORTINET.out.OpenXen.zip file and extracted virtual hard drive image file fortios.qcow2, you can create the virtual machine in your OpenXen environment.

The following topics are included in this section: Create the FortiGate VM virtual machine (VMM)

 

Create the FortiGate VM virtual machine (VMM)

 

To create the FortiGate VM virtual machine:

1. Launch Virtual Machine Manager (virt-manager) on your OpenXen host server.

 

The Virtual Machine Manager home page opens.

2. In the toolbar, select Create a new virtual machine.

3. Enter a Name for the VM, FGT-VM for example.

4. Ensure that Connection is localhost. (This is the defaul)

5. Select Import existing disk image.

6. Select Forward.

7. In OS Type select Linux.

8. In Version, select Generic 2.4.x.kernel.

9. Select Browse.

 

The Locate or create storage volume window opens.

10. Select Browse Local, find the fortios.qcow2 disk image file.

11. Select fortios.qcow2 and select Choose Volume.

12. Select Forward.

13. Specify the amount of memory and number of CPUs to allocate to this virtual machine. The amounts must not exceed your license limits.

14. Select Forward.

15. Select Customize configuration before install. This enables you to make some hardware configuration changes before VM creation is started.

16. Expand Advanced options. A new virtual machine includes one network adapter by default. Select Specify shared device name and enter the name of the bridge interface on the OpenXen host. Optionally, set a specific MAC address for the virtual network interface. Virt Type and Architecture are set by default and should be correct.

17. Select Finish.

 

The virtual machine hardware configuration window opens.

You can use this window to add hardware such as network interfaces and disk drives.

18. Select Add Hardware. In the Add Hardware window select Storage.

19. Select Create a disk image on the computer’s harddrive and set the size to 30GB.

If you know your environment will expand in the future, it is recommended to increase the hard disk size beyond 30GB. The VM license limit is 2TB.

20. Enter:

Device type                                Virtio disk

Cache mode                               Default

Storage format                          raw

21. Select Network to configure add more the network interfaces. The Device type must be Virtio.

A new virtual machine includes one network adapter by default. You can add more through the Add Hardware window. FortiGate VM requires four network adapters. You can configure network adapters to connect to a virtual switch or to network adapters on the host computer.

22. Select Finish.

23. Select Begin Installation. After the installation completes successfully, the VM starts and the console window opens.