Chapter 28 – VM Installation

This document describes how to deploy a FortiGate virtual appliance in several virtualization server environments. This includes how to configure the virtual hardware settings of the virtual appliance.

 

This document assumes:

•  you have already successfully installed the virtualization server on the physical machine,
• lyou have installed appropriate VM management software on either the physical server or a computer to be used for VM management.

This document does not cover configuration and operation of the virtual appliance after it has been successfully installed and started. For these issues, see the FortiGate 5.2 Handbook.

 

This document includes the following sections:

• FortiGate VM Overview
• Deployment example – VMware
• Deployment example – MS Hyper-V
• Deployment example – KVM
• Deployment example – OpenXen
• Deployment example – Citrix XenServer

 

What’s new in FortiOS 5.4

 

FortiGate VM Overview

• The following topics are included in this section: FortiGate VM models and licensing
• Registering FortiGate VM with Customer Service & Support Downloading the FortiGate VM deployment package Deployment package contents
• Deploying the FortiGate VM appliance

 

FortiGate VM models and licensing

Fortinet offers the FortiGate VM in five virtual appliance models determined by license. When configuring your FortiGate VM, be sure to configure hardware settings within the ranges outlined below. Contact your Fortinet Authorized Reseller for more information.

 

FortiGate VM model information

Technical Specification                               FG-VM00   FG-VM01   FG-VM02   FG-VM04   FG-VM08

Virtual CPUs

(min / max)

1 / 1             1 / 1             1 / 2             1 / 4             1 / 8

 

Virtual Network

Interfaces (min / max)

2 / 10

 

Virtual Memory

(min / max)

1GB /1GB

1GB /2GB

1GB /4GB

1GB /6GB

1GB/12GB

 

Virtual Storage

(min / max)

 

Managed Wireless APs

(tunnel mode / global)

30GB / 2TB

 

 

32 / 32         32 / 64       256 / 512     256 / 512        1024 /

4096

 

Virtual Domains

(default / max)

1 / 1           10 / 10         10 / 25         10 / 50        10 / 250

 

After placing an order for FortiGate VM, a license registration code is sent to the email address used on the order form. Use the registration number provided to register the FortiGate VM with Customer Service & Support and then download the license file. Once the license file is uploaded to the FortiGate VM and validated, your FortiGate VM appliance is fully functional.

 

FortiGate VM evaluation license

FortiGate VM includes a limited embedded 15-day trial license that supports:

• 1 CPU maximum
• 1024 MB memory maximum
• low encryption only (no HTTPS administrative access)
• all features except FortiGuard updates

You cannot upgrade the firmware, doing so will lock the Web-based Manager until a license is uploaded. Technical support is not included. The trial period begins the first time you start FortiGate VM. After the trial license expires, functionality is disabled until you upload a license file.

 

Registering FortiGate VM with Customer Service & Support

To obtain the FortiGate VM license file you must first register your FortiGate VM with Customer Service & Support.

 

To register your FortiGate VM:

1. Log in to the Customer Service & Support portal using an existing support account or select Sign Up to create a new account.

2. In the main page, under Asset, select Register/Renew.

 

The Registration page opens.

3. Enter the registration code that was emailed to you and select Register. A registration form will display.

4. After completing the form, a registration acknowledgement page will appear.

5. Select the License File Download link.

6. You will be prompted to save the license file (.lic) to your local computer. See “Upload the license file” for instructions on uploading the license file to your FortiGate VM via the Web-based Manager.

 

 

Downloading the FortiGate VM deployment package

FortiGate VM deployment packages are included with FortiGate firmware images on the Customer Service & Support site. First, see the following table to determine the appropriate VM deployment package for your VM platform.

 

Selecting the correct FortiGate VM deployment package for your VM platform

VM Platform                                                              FortiGate VM Deployment File

Citrix XenServer v5.6sp2, 6.0 and later                          FGT_VM64-v500-buildnnnn-FORTINET. out.CitrixXen.zip

OpenXen v3.4.3, 4.1                                                      FGT_VM64-v500-buildnnnn-FORTINET. out.OpenXen.zip

Microsoft Hyper-V Server 2008R2 and 2012                   FGT_VM64-v500-buildnnnn-FORTINET. out.hyperv.zip

KVM (qemu 0.12.1)                                                        FGT_VM64-v500-buildnnnn-FORTINET. out.kvm.zip

 

VM Platform                                                              FortiGate VM Deployment File

VMware ESX 4.0, 4.1

ESXi 4.0/4.1/5.0/5.1/5.5

FGT_VM32-v500-buildnnnn-FORTINET. out.ovf.zip (32-bit)

FGT_VM64-v500-buildnnnn-FORTINET. out.ovf.zip

 

For more information see the FortiGate product datasheet available on the Fortinet web site, http://www.fortinet.com/products/fortigate/virtualappliances.html.

The firmware images FTP directory is organized by firmware version, major release, and patch release. The firmware images in the directories follow a specific naming convention and each firmware image is specific to the device model. For example, the FGT_VM32-v500-build0151-FORTINET.out.ovf.zip image found in the v5.0 Patch Release 2 directory is specific to the FortiGate VM 32-bit environment.

You can also download the FortiOS Release Notes, FORTINET-FORTIGATE MIB file, FSSO images, and SSL VPN client in this directory. The Fortinet Core MIB file is loc- ated in the main FortiGate v5.00 directory.

 

To download the FortiGate VM deployment package:

1. In the main page of the Customer Service & Support site, select Download > Firmware Images.

 

The Firmware Images page opens.

2. In the Firmware Images page, select FortiGate.

3. Browse to the appropriate directory on the FTP site for the version that you would like to download.

4. Download the appropriate .zip file for your VM server platform.

 

You can also download the FortiGate Release Notes.

5. Extract the contents of the deployment package to a new file folder.

 

Deployment package contents

 

Citrix XenServer

The FORTINET.out.CitrixXen.zip file contains:

• fortios.vhd: the FortiGate VM system hard disk in VHD format
• fortios.xva: binary file containing virtual hardware configuration settings
• in the ovf folder:
• FortiGate-VM64.ovf: Open Virtualization Format (OVF) template file, containing virtual hardware settings for Xen
• fortios.vmdk: the FortiGate VM system hard disk in VMDK format
• datadrive.vmdk: the FortiGate VM log disk in VMDK format

The ovf folder and its contents is an alternative method of installation to the .xva and VHD disk image.

 

OpenXEN

The FORTINET.out.OpenXen.zip file contains only fortios.qcow2, the FortiGate VM system hard disk in qcow2 format. You will need to manually:

• create a 30GB log disk
• specify the virtual hardware settings

 

Microsoft Hyper-V

The FORTINET.out.hyperv.zip file contains:

• in the Virtual Hard Disks folder:
• fortios.vhd: the FortiGate VM system hard disk in VHD format
• DATADRIVE.vhd: the FortiGate VM log disk in VHD format
• In the Virtual Machines folder:
• fortios.xml: XML file containing virtual hardware configuration settings for Hyper-V. This is compatible with Windows Server 2012.
• Snapshots folder: optionally, Hyper-V stores snapshots of the FortiGate VM state here

 

KVM

The FORTINET.out.kvm.zip contains only fortios.qcow2, the FortiGate VM system hard disk in qcow2 format. You will need to manually:

• create a 30GB log disk
• specify the virtual hardware settings

 

VMware ESX/ESXi

The FORTINET.out.ovf.zip file contains:

• fortios.vmdk: the FortiGate VM system hard disk in VMDK format
• datadrive.vmdk: the FortiGate VM log disk in VMDK format
• Open Virtualization Format (OVF) template files:
• FortiGate-VM64.ovf: OVF template based on Intel e1000 NIC driver
• FortiGate-VM64.hw04.ovf: OVF template file for older (v3.5) VMware ESX server
• FortiGate-VMxx.hw07_vmxnet2.ovf: OVF template file for VMware vmxnet2 driver
• FortiGate-VMxx.hw07_vmxnet3.ovf: OVF template file for VMware vmxnet3 driver

 

Use the VMXNET3 interface (FortiGate-VMxx.hw07_vmxnet3.ovf template) if the virtual appliance will distribute workload to multiple processor cores.

 

Deploying the FortiGate VM appliance

Prior to deploying the FortiGate VM appliance, the VM platform must be installed and configured so that it is ready to create virtual machines. The installation instructions for FortiGate VM assume that

• You are familiar with the management software and terminology of your VM platform.
• An Internet connection is available for FortiGate VM to contact FortiGuard to validate its license or, for closed environments, a FortiManager can be contacted to validate the FortiGate VM license. See “Validate the FortiGate VM license with FortiManager”.

For assistance in deploying FortiGate VM, refer to the deployment chapter in this guide that corresponds to your VMware environment. You might also need to refer to the documentation provided with your VM server. The deployment chapters are presented as examples because for any particular VM server there are multiple ways to create a virtual machine. There are command line tools, APIs, and even alternative graphical user interface tools.

Before you start your FortiGate VM appliance for the first time, you might need to adjust virtual disk sizes and networking settings. The first time you start FortiGate VM, you will have access only through the console window of your VM server environment. After you configure one FortiGate network interface with an IP address and administrative access, you can access the FortiGate VM web-based manager.

After deployment and license validation, you can upgrade your FortiGate VM appliance’s firmware by downloading either FGT_VM32-v500-buildnnnn-FORTINET.out (32-bit) or FGT_VM64-v500-buildnnnn- FORTINET.out (64-bit) firmware. Firmware upgrading on a VM is very similar to upgrading firmware on a hardware FortiGate unit.

Troubleshooting Virtual Domains

When you are configuring VDOMs you may run into some issues, with your VDOM configuration, your network configuration, or your device setup. This section addresses common problems and specific concerns that an administrator of a VDOM network may have.

 

This section includes:

• VDOM admin having problems gaining access
• FortiGate unit running very slowly
• General VDOM tips and troubleshooting

 

VDOM admin having problems gaining access

With VDOMs configured, administrators have an extra layer of permissions and may have problems accessing their information.

 

Confirm the admin’s VDOM

Each administrator account, other than the super_admin account, is tied to one specific VDOM. That administrator is not able to access any other VDOM. It may be possible they are trying to access the wrong VDOM.

 

Confirm the VDOM’s interfaces

An administrator can only access their VDOM through interfaces that are assigned to that VDOM. If interfaces on that VDOM are disabled or unavailable there will be no method of accessing that VDOM by its local administrator. The super_admin will be required to either bring up the interfaces, fix the interfaces, or move another interface to that VDOM to restore access.

 

Confirm the VDOMs admin access

As with all FortiGate units, administration access on the VDOM’s interfaces must be enabled for that VDOM’s administrators to gain access. For example if SSH is not enabled, that is not available to administrators.

To enable admin access, the super_admin will go to the Global > Network > Interfaces page, and for the interface in question enable the admin access.

 

FortiGate unit running very slowly

You may experience a number of problems resulting from your FortiGate unit being overloaded. These problems may appear as:

• CPU and memory threshold limits exceeded on a continual basis
• AV failopen happening on a regular basis
• dropped traffic or sessions due to lack of resources

These problems are caused by a lack of system resources. There are a number of possible reasons for this.

 

Too many VDOMs

If you have configured many VDOMs on your system, past the default ten VDOMs, this could easily be your problem.

Each VDOM you create on your FortiGate unit requires system resources to function – CPU cycles, memory, and disk space. When there are too many VDOMs configured there are not enough resources for operation. This may be a lack of memory in the session table, or no CPU cycles for processing incoming IPS traffic, or even a full disk drive.

Go to Global > System > VDOM and see the number of configured VDOMs on your system. If you are running 500 or more VDOMs, you must have a FortiGate 5000 chassis. Otherwise you need to reduce the number of VDOMs on your system to fix the problem. Even if you have the proper hardware, you may encounter noticeably slow throughput if you are using advanced features such as security profiles or deep content inspection with many configured VDOMs.

 

One or more VDOMs are consuming all the resources

If you have sufficient hardware to support the number of VDOMs you are running, check the global resources on your FortiGate unit. At a glance it will tell you if you are running out of a particular resource such as sessions, or users. If this is the case, you can then check your VDOMs to see if one particular VDOM is using more than its share of resources. If that is the case you can change the resource settings to allow that VDOM (or those VDOMs) fewer resources and in turn allow the other VDOMs access to those resources.

 

Too many Security Features in use

It is likely that reducing the Security Features in use regardless of number of VDOMs will greatly improve overall system performance and should be considered as an option.

Finally it is possible that your FortiGate unit configuration is incorrect in some other area, which is using up all your resources. For example, forgetting that you are running a network sniffer on an interface will create significant amounts of traffic that may prevent normal operation.

 

General VDOM tips and troubleshooting

Besides ping and traceroute, there are additional tools for troubleshooting your VDOM configurations. These include packet sniffing and debugging the packet flow.

 

Perform a sniffer trace

When troubleshooting networks, it helps to look inside the headers of packets to determine if they are traveling along the route you expect that they are. Packet sniffing can also be called a network tap, packet capture, or logic analyzing.

If your FortiGate unit has NP interfaces that are offloading traffic, this will change the sniffer trace. Before performing a trace on any NP interfaces, you should disable off- loading on those interfaces.

 

What sniffing packets can tell you

If you are running a constant traffic application such as ping, packet sniffing can tell you if the traffic is reaching the destination, what the port of entry is on the FortiGate unit, if the ARP resolution is correct, and if the traffic is being sent back to the source as expected.

Sniffing packets can also tell you if the Fortigate unit is silently dropping packets for reasons such as RPF (Reverse Path Forwarding), also called Anti Spoofing, which prevents an IP packet from being forwarded if its Source IP does not either belong to a locally attached subnet (local interface), or be part of the routing between the FortiGate and another source (static route, RIP, OSPF, BGP). Note that RPF can be disabled by turning on asymmetric routing in the CLI (config system setting, set asymmetric enable), however this will disable stateful inspection on the FortiGate unit and cause many features to be turned off.

If you configure virtual IP addresses on your Fortigate unit, it will use those addresses in preference to the physical IP addresses. You will notice this when you are sniffing packets because all the traffic will be using the virtual IP addresses. This is due to the ARP update that is sent out when the VIP address is configured.

 

How to sniff packets

When you are using VDOMs, you must be in a VDOM to access the diag sniffer command. At the global level, the command is not available. This is limit the packets only to the ones on your VDOM, and protects the privacy of other VDOM clients.

The general form of the internal FortiOS packet sniffer command is:

diag sniffer packet <interface_name> <‘filter’> <verbose> <count>

To stop the sniffer, type CTRL+C.

<interface_name>                      The name of the interface to sniff, such as “port1” or “internal”. This can also be “any” to sniff all interfaces.

<‘filter’>

What to look for in the information the sniffer reads.  none indicates no fil- tering, and all packets will be displayed as the other arguments indicate.

The filter must be inside single quotes (‘).

<verbose>                                  The level of verbosity as one of:

1 – print header of packets

2 – print header and data from IP of packets

3 – print header and data from Ethernet of packets

<count>                                      The number of packets the sniffer reads before stopping. If you don’t put a number here, the sniffer will run forever unit you stop it with <CTRL C>.

For a simple sniffing example, enter the CLI command diag sniffer packet port1 none 1 3. This will display the next 3 packets on the port1 interface using no filtering, and using verbose level 1. At this verbosity level you can see the source IP and port, the destination IP and port, action (such as ack), and sequence numbers.

In the output below, port 443 indicates these are HTTPS packets, and 172.20.120.17 is both sending and receiving traffic.

 

Head_Office_620b # diag sniffer packet port1 none 1	3
interfaces=[port1]
filters=[none]
0.545306 172.20.120.17.52989 -> 172.20.120.141.443:	psh	3177924955	ack	1854307757
0.545963 172.20.120.141.443 -> 172.20.120.17.52989:	psh	1854307757	ack	3177925808
0.562409 172.20.120.17.52988 -> 172.20.120.141.443:	psh	4225311614	ack	3314279933

For a more advanced example of packet sniffing, the following commands will report packets on any interface travelling between a computer with the host name of PC1 and the computer with the host name of PC2. With verbosity 4 and above, the sniffer trace will display the interface names where traffic enters or leaves the FortiGate unit. Remember to stop the sniffer, type CTRL+C. Note that PC1 and PC2 may be VDOMs.

FGT# diagnose sniffer packet any “host <PC1> or host <PC2>” 4

or

FGT# diagnose sniffer packet any “(host <PC1> or host <PC2>) and icmp” 4

The following sniffer CLI command includes the ARP protocol in the filter which may be useful to troubleshoot a failure in the ARP resolution (for instance PC2 may be down and not responding to the FortiGate ARP requests).

FGT# diagnose sniffer packet any “host <PC1> or host <PC2> or arp” 4

 

Debugging the packet flow

Traffic should come in and leave the VDOM. If you have determined that network traffic is not entering and leaving the VDOM as expected, debug the packet flow.

Debugging can only be performed using CLI commands. Debugging the packet flow requires a number of debug commands to be entered as each one configures part of the debug action, with the final command starting the debug.

If your FortiGate unit has NP interfaces that are offloading traffic, this will change the packet flow. Before performing the debug on any NP interfaces, you should disable off- loading on those interfaces.

The following configuration assumes that PC1 is connected to the internal interface of the FortiGate unit and has an IP address of 10.11.101.200. PC1 is the host name of the computer.

 

To debug the packet flow in the CLI, enter the following commands:

FGT# diag debug enable

FGT# diag debug flow filter add <PC1> FGT# diag debug flow show console enable FGT# diag debug flow trace start 100

FGT# diag debug enable

 

The start 100 argument in the above list of commands will limit the output to 100 packets from the flow. This is useful for looking at the flow without flooding your log or your display with too much information.

 

To stop all other debug activities, enter the command:

FGT# diag debug flow trace stop

 

The following is an example of debug flow output for traffic that has no matching Firewall Policy, and is in turn blocked by the FortiGate unit. The denied message indicates the traffic was blocked. Note that even with VDOMs not enabled, vd-root is still shown.

id=20085 trace_id=319 func=resolve_ip_tuple_fast line=2825 msg=”vd-root received a packet(proto=6, 192.168.129.136:2854->192.168.96.153:1863) from port3.”

id=20085 trace_id=319 func=resolve_ip_tuple line=2924 msg=”allocate a new session-013004ac”

id=20085 trace_id=319 func=vf_ip4_route_input line=1597 msg=”find a route: gw-192.168.150.129 via port1″

id=20085 trace_id=319 func=fw_forward_handler line=248 msg=” Denied by forward policy check”

HA virtual clusters and VDOM links

FortiGate HA is implemented by configuring two or more FortiGate units to operate as an HA cluster. To the network, the HA cluster appears to function as a single FortiGate unit, processing network traffic and providing normal security services such as firewall, VPN, IPS, virus scanning, web filtering, and spam filtering.

Virtual clustering extends HA features to provide failover protection and load balancing for a FortiGate unit operating with virtual domains. A virtual cluster consists of a cluster of two FortiGate units operating with virtual domains. Traffic on different virtual domains can be load balanced between the cluster units.

With virtual clusters (vclusters) configured, inter-VDOM links must be entirely within one vcluster. You cannot create links between vclusters, and you cannot move a VDOM that is linked into another virtual cluster. If your FortiGate units are operating in HA mode, with multiple vclusters when you create the vdom-link, the CLI command  config system vdom-link includes an option to set which vcluster the link will be in.

 

What is virtual clustering?

Virtual clustering is an extension of the FGCP for FortiGate units operating with multiple VDOMS enabled. Virtual clustering operates in active-passive mode to provide failover protection between two instances of a VDOM operating on two different cluster units. You can also operate virtual clustering in active-active mode to use HA load balancing to load balance sessions between cluster units. Alternatively, by distributing VDOM processing between the two cluster units you can also configure virtual clustering to provide load balancing by distributing sessions for different VDOMs to each cluster unit.

 

Virtual clustering and failover protection

Virtual clustering operates on a cluster of two (and only two) FortiGate units with VDOMs enabled. Each VDOM creates a cluster between instances of the VDOMs on the two FortiGate units in the virtual cluster. All traffic to and from the VDOM stays within the VDOM and is processed by the VDOM. One cluster unit is the primary unit for each VDOM and one cluster unit is the subordinate unit for each VDOM. The primary unit processes all traffic for the VDOM. The subordinate unit does not process traffic for the VDOM. If a cluster unit fails, all traffic fails over to the cluster unit that is still operating.

 

Virtual clustering and heartbeat interfaces

The HA heartbeat provides the same HA services in a virtual clustering configuration as in a standard HA configuration. One set of HA heartbeat interfaces provides HA heartbeat services for all of the VDOMs in the cluster. You do not have to add a heartbeat interface for each VDOM.

 

Virtual clustering and HA override

For a virtual cluster configuration, override is enabled by default for both virtual clusters when you:

• Enable VDOM portioning from the web-based manager by moving virtual domains to virtual cluster 2
• Enter set vcluster2 enable from the CLI config system ha command to enable virtual cluster 2.

Usually you would enable virtual cluster 2 and expect one cluster unit to be the primary unit for virtual cluster 1 and the other cluster unit to be the primary unit for virtual cluster 2. For this distribution to occur override must be enabled for both virtual clusters. Otherwise you will need to restart the cluster to force it to renegotiate.

 

Virtual clustering and load balancing or VDOM partitioning

There are two ways to configure load balancing for virtual clustering. The first is to set the HA mode to active- active. The second is to configure VDOM partitioning. For virtual clustering, setting the HA Mode to active-active has the same result as active-active HA for a cluster without virtual domains. The primary unit receives all sessions and load balances them among the cluster units according to the load balancing schedule. All cluster units process traffic for all virtual domains.

Note: If override is enabled the cluster may renegotiate too often. You can choose to disable override at any time. If you decide to disable override, for best results, you should disable it for both cluster units.

In a VDOM partitioning virtual clustering configuration, the HA mode is set to active-passive. Even though virtual clustering operates in active-passive mode you can configure a form of load balancing by using VDOM partitioning to distribute traffic between both cluster units. To configure VDOM partitioning you set one cluster unit as the primary unit for some virtual domains and you set the other cluster unit as the primary unit for other virtual domains. All traffic for a virtual domain is processed by the primary unit for that virtual domain. You can control the distribution of traffic between the cluster units by adjusting which cluster unit is the primary unit for each virtual domain.

For example, you could have 4 VDOMs, two of which have a high traffic volume and two of which have a low traffic volume. You can configure each cluster unit to be the primary unit for one of the high volume VDOMs and one of the low volume VDOMs. As a result each cluster unit will be processing traffic for a high volume VDOM and a low volume VDOM, resulting in an even distribution of traffic between the cluster units. You can adjust the distribution at any time. For example, if a low volume VDOM becomes a high volume VDOM you can move it from one cluster unit to another until the best balance is achieved. From the web-based manager you configure VDOM partitioning by setting the HA mode to active-passive and distributing virtual domains between Virtual Cluster 1 and Virtual Cluster 2. You can also configure different device priorities, port monitoring, and remote link failover, for Virtual Cluster 1 and Virtual Cluster 2.

From the CLI you configure VDOM partitioning by setting the HA mode to a-p. Then you configure device priority, port monitoring, and remote link failover and specify the VDOMs to include in virtual cluster 1. You do the same for virtual cluster 2 by entering the config secondary-vcluster command.

Failover protection does not change. If one cluster unit fails, all sessions are processed by the remaining cluster unit. No traffic interruption occurs for the virtual domains for which the still functioning cluster unit was the primary unit. Traffic may be interrupted temporarily for virtual domains for which the failed unit was the primary unit while processing fails over to the still functioning cluster unit. If the failed cluster unit restarts and rejoins the virtual cluster, VDOM partitioning load balancing is restored.

Dynamic routing over inter-VDOM links

BGP is supported over inter-VDOM links. Unless otherwise indicated, routing works as expected over inter-VDOM links.

If an inter-VDOM link has no assigned IP addresses to it, it may be difficult to use that interface in dynamic routing configurations. For example BGP requires an IP address to define any BGP router added to the network.

In OSPF, you can configure a router using a router ID and not its IP address. In fact, having no IP address avoids possible confusing between which value is the router ID and which is the IP address. However for that router to become adjacent with another OSPF router it will have to share the same subnet, which is technically impossible without an IP address. For this reason, while you can configure an OSPF router using an IP-less inter-VDOM link, it will likely be of limited value to you.

In RIP the metric used is hop count. If the inter-VDOM link can reach other nodes on the network, such as through a default route, then it may be possible to configure a RIP router on an inter-VDOM link. However, once again it may be of limited value due to limitations.

As stated earlier, BGP requires an IP address to define a router — an IP-less inter-VDOM link will not work with BGP.

In Multicast, you can configure an interface without using an IP address. However that interface will be unable to become an RP candidate. This limits the roles available to such an interface.

Configuring VDOM links

Once VDOMs are configured on your FortiGate unit, configuring inter-VDOM routing and VDOM-links is very much like creating a VLAN interface. VDOM-links are managed through the web-based manager or CLI. In the web-based manager, VDOM link interfaces are managed in the network interface list.

This section includes the following topics:

• Creating VDOM links
• IP addresses and inter-VDOM links
• Deleting VDOM links
• NAT to Transparent VDOM links

 

Creating VDOM links

VDOM links connect VDOMs together to allow traffic to pass between VDOMs as per firewall policies. Inter- VDOM links are virtual interfaces that are very similar to VPN tunnel interfaces except inter-VDOM links do not require IP addresses.

To create a VDOM link, you first create the point-to-point interface, and then bind the two interface objects associated with it to the virtual domains.

In creating the point-to-point interface, you also create two additional interface objects by default. They are called vlink10 and vlink11 – the interface name you chose with a 1 or a 0 to designate the two ends of the link.

Once the interface objects are bound, they are treated like normal FortiGate interfaces and need to be configured just like regular interfaces.

The assumptions for this example are as follows:

• Your FortiGate unit has VDOMs enabled and you have 2 VDOMs called customer1 and customer2 already configured. For more information on configuring VDOMs see Configuring Virtual Domains.
• You are using a super_admin account.

 

To configure an inter-VDOM link – web-based manager:

1. Go to Global > Network > Interfaces.

2. Select Create New > VDOM link, enter the following information, and select OK.

 

Name                                           vlink1

(The name can be up to 11 characters long. Valid characters are letters, numbers, “-”, and “_”. No spaces are allowed.)

Interface #0

	Virtual Domain                  customer1
	IP/Netmask                        10.11.12.13/255.255.255.0
	Administrative Access    HTTPS, SSL
Interface #1
	Virtual Domain                  customer2
	IP/Netmask                        172.120.100.13/255.255.255.0
	Administrative Access    HTTPS, SSL

 

To configure an inter-VDOM link – CLI:

config global

config system vdom-link edit vlink1

end

config system interface edit vlink10

set vdom customer1 next

edit vlink11

set vdom customer2 end

 

Once you have created and bound the interface ends to VDOMs, configure the appropriate firewall policies and other settings that you require. To confirm the inter-VDOM link was created, find the VDOM link pair and use the expand arrow to view the two VDOM link interfaces. You can select edit to change any information.

 

IP addresses and inter-VDOM links

Besides being virtual interfaces, here is one main difference between inter-VDOM links and regular interfaces— default inter-VDOM links do not require IP addresses. IP addresses are not required by default because an inter- VDOM link is an internal connection that can be referred to by the interface name in firewall policies, and other system references. This introduces three possible situations with inter-VDOM links that are:

• unnumbered – an inter-VDOM link with no IP addresses for either end of the tunnel
• half numbered – an inter-VDOM link with one IP address for one end and none for the other end
• full numbered – an inter-VDOM link with two IP addresses, one for each end.

Not using an IP address in the configuration can speed up and simplify configuration for you. Also you will not use up all the IP addresses in your subnets if you have many inter-VDOM links.

Half or full numbered interfaces are required if you are doing NAT, either SNAT or DNAT as you need an IP number on both ends to translate between.

You can use unnumbered interfaces in static routing, by naming the interface and using 0.0.0.0 for the gateway. Running traceroute will not show the interface in the list of hops. However you can see the interface when you are sniffing packets, which is useful for troubleshooting.

 

Deleting VDOM links

When you delete the VDOM link, the two link objects associated with it will also be deleted. You cannot delete the objects by themselves. The example uses a VDOM routing connection called “vlink1”. Removing vlink1 will also remove its two link objects vlink10 and vlink11.

Before deleting the VDOM link, ensure all policies, firewalls, and other configurations that include the VDOM link are deleted, removed, or changed to no longer include the VDOM link.

 

To remove a VDOM link – web-based manager:

1. Go to Global > Network > Interfaces.

2. Select Delete for the VDOM link vlink1.

 

To remove a VDOM link – CLI:

config global

config system vdom-link delete vlink1

end

 

NAT to Transparent VDOM links

Inter-VDOM links can be created between VDOMs in NAT mode and VDOMs in Transparent mode, but it must be done through the CLI, as the VDOM link type must be changed from the default PPP to Ethernet for the two VDOMs to communicate. The below example assumes one vdom is in NAT mode and one is Transparent.

An IP address must be assigned to the NAT VDOM’s interface, but no IP address should be assigned to the Transparent VDOM’s interface.

 

To configure a NAT to Transparent VDOM link – CLI:

config global

config system vdom-link edit vlink1

set type ethernet end

config system interface edit vlink10

set vdom (interface 1 name)

set ip (interface 1 ip)

next

edit vlink11

set vdom (interface 2 name)

end

 

Ethernet-type is not recommended for standard NAT to NAT inter-VDOM links, as the default PPP-type link does not require the VDOM links to have addresses, while Ethernet-type does. VDOM link addresses are explained in IP addresses and inter-VDOM links.

Inter–VDOM configurations

By using fewer physical interfaces to inter-connect VDOMs, inter-VDOM links provide you with more configuration options.

None of these configurations use VLANs to reduce the number of physical interfaces. It is generally assumed that an internal or client network will have its own internal interface and an external interface to connect to its ISP and the Internet.

These inter-VDOM configurations can use any FortiGate model with possible limitations based on the number of physical interfaces. VLANs can be used to work around these limitations.

There are four different types of inter-VDOM configurations:

• Standalone VDOM
• Independent VDOMs
• Management VDOM
• Meshed VDOM

 

Standalone VDOM

The standalone VDOM configuration uses a single VDOM on your FortiGate unit — the root VDOM that all FortiGate units have by default. This is the VDOM configuration you are likely familiar with. It is the default configuration for FortiGate units before you create additional VDOMs.

The configuration shown above has no VDOM inter-connections and requires no special configurations or settings.

The standalone VDOM configuration can be used for simple network configurations that only have one department or one company administering the connections, firewalls and other VDOM-dependent settings.

However, with this configuration, keeping client networks separate requires many interfaces, considerable firewall design and maintenance, and can quickly become time consuming and complex. Also, configuration errors for one client network can easily affect other client networks, causing unnecessary network downtime.

 

Independent VDOMs

The independent VDOMs configuration uses multiple VDOMs that are completely separate from each other. This is another common VDOM configuration.

This configuration has no communication between VDOMs and apart from initially setting up each VDOM, it requires no special configurations or settings. Any communication between VDOMs is treated as if communication is between separate physical devices.

The independent inter-VDOM configuration can be used where more than one department or one company is sharing the FortiGate unit. Each can administer the connections, firewalls and other VDOM-dependent settings for only its own VDOM. To each company or department, it appears as if it has its own FortiGate unit. This configuration reduces the amount of firewall configuration and maintenance required by dividing up the work.

However, this configuration lacks a management VDOM for VDOMs 1, 2, and 3. This is illustrated in Figure 50. This management VDOM would enable an extra level of control for the FortiGate unit administrator, while still allowing each company or department to administer its own VDOM.

 

Management VDOM

In the management VDOM configuration, the root VDOM is the management VDOM. The other VDOMs are connected to the management VDOM with inter-VDOM links. There are no other inter-VDOM connections.

The inter-VDOM links connect the management VDOM to the other VDOMs. This does not require any physical interfaces, and the bandwidth of inter-VDOM links can be faster than physical interfaces, depending on the CPU workload.

Only the management VDOM is connected to the Internet. The other VDOMs are connected to internal networks. All external traffic is routed through the management VDOM using inter-VDOM links and firewall policies between the management VDOM and each VDOM. This ensures the management VDOM has full control over access to the Internet, including what types of traffic are allowed in both directions. There is no communication directly between the non-root VDOMs. Security is greatly increased with only one point of entry and exit. Only the management VDOM needs to be fully managed to ensure network security in this case. Each client network can manage its own configuration without compromising security or bringing down another client network.

The management VDOM configuration is ideally suited for a service provider business. The service provider administers the management VDOM with the other VDOMs as customers. These customers do not require a dedicated IT person to manage their network. The service provider controls the traffic and can prevent the customers from using banned services and prevent Internet connections from initiating those same banned services. One example of a banned service might be Instant Messaging (IM) at a company concerned about intellectual property. Another example could be to limit bandwidth used by file-sharing applications without banning that application completely. Firewall policies control the traffic between the customer VDOM and the management VDOM and can be customized for each customer.

The management VDOM configuration is limited in that the customer VDOMs have no inter-connections. In many situations this limitation is ideal because it maintains proper security. However, some configurations may require customers to communicate with each other, which would be easier if the customer VDOMs were inter- connected.

 

Meshed VDOM

The meshed VDOMs configuration, including partial and full mesh, has VDOMs inter-connected with other VDOMs. There is no special feature to accomplish this—they are just complex VDOM configurations.

Partial mesh means only some VDOMs are inter-connected. In a full mesh configuration, all VDOMs are inter- connected to all other VDOMs. This can be useful when you want to provide full access between VDOMs but handle traffic differently depending on which VDOM it originates from or is going to.

With full access between all VDOMs being possible, it is extra important to ensure proper security. You can achieve this level of security by establishing extensive firewall policies and ensuring secure account access for all administrators and users.

Meshed VDOM configurations can become complex very quickly, with full mesh VDOMs being the most complex. Ensure this is the proper solution for your situation before using this configuration. Generally, these configurations are seen as theoretical and are rarely deployed in the field.

Example configuration: VDOM in Transparent mode

In this example, the FortiGate unit provides network protection to two organizations — Company A and Company B. Each company has different policies for incoming and outgoing traffic, requiring three different security policies and protection profiles.

 

VDOMs are not required for this configuration, but by using VDOMs the profiles and policies can be more easily managed on a per-VDOM basis either by one central administrator or separate administrators for each company. Also future expansion is simply a matter of adding additional VDOMs, whilst not disrupt the existing VDOMs.

For this example, firewalls are only included to deal with web traffic. This is to provide an example without making configuration unnecessarily complicated.

This example includes the following sections:

• Network topology and assumptions
• General configuration steps
• Configuring common items
• Creating virtual domains
• Configuring the Company_A VDOM
• Configuring the Company_B VDOM
• Configuring the VLAN switch and router
• Testing the configuration

 

Network topology and assumptions

Each organization’s internal network consists of a different range of IP addresses:

• 10.11.0.0.0/255.255.0.0 for Company A.
• 10.12.0.0/255.255.0.0 for Company B.

For the procedures in this section, it is assumed that you have enabled VDOM configuration on your FortiGate unit. For more information, see Virtual Domains Overview.

The VDOM names are similar to the company names for easy recognition. The root VDOM cannot be renamed and is not used in this example.

Interfaces used in this example are port1 and port2. Some FortiGate models may not have interfaces with these names. port1 is an external interface. port2 is an internal interface.

 

General configuration steps

The following steps summarize the configuration for this example. For best results, follow the procedures in the order given. Also, note that if you perform any additional actions between procedures, your configuration may have different results.

1. Configuring common items

2. Creating virtual domains

3. Configuring the Company_A VDOM

4. Configuring the Company_B VDOM

5. Configuring the VLAN switch and router

6. Testing the configuration

 

Configuring common items

Both VDOMs require you configure security profiles. These will be configured the same way, but need to be configured in both VDOMs.

The relaxed profile allows users to surf websites they are not allowed to visit during normal business hours. Also a quota is in place to restrict users to one hour of access to these websites to ensure employees do not take long and unproductive lunches.

 

To create a strict web filtering profile – web-based manager:

1. Go to the proper VDOM, and select Security Profiles > Web Filter.

2. Select Create New.

3. Enter strict for the Name.

4. Expand FortiGuard Web Filtering, and select block for all Categories except Business Oriented, and Other.

5. Block all Classifications except Cached Content, and Image Search.

6. Ensure FortiGuard Quota for all Categories and Classifications is Disabled.

7. Select OK.

 

To create a strict web filtering profile – CLI:

config vdom

edit <vdom_name>

config webfilter profile edit strict

config ftgd-wf

set allow g07 g08 g21 g22 c01 c03

set deny g01 g02 g03 g04 g05 g06 c02 c04 c05 c06 c07 end

set web-ftgd-err-log enable end

 

To create a relaxed web filtering profile – web-based manager:

1. Go to the proper VDOM, and select Security Profiles > Web Filter.

2. Select Create New.

3. Enter relaxed for the Name.

4. Expand FortiGuard Web Filtering, and select block for Potentially Security Violating Category, and Spam URL Classification.

5. Enable FortiGuard Quotas to allow 1 hour for all allowed Categories and Classifications.

 

Creating virtual domains

The FortiGate unit supports 10 virtual domains. Root is the default VDOM. It cannot be deleted or renamed. The root VDOM is not used in this example. New VDOMs are created for Company A and Company B

 

To create the virtual domains – web-based manager:

1. With VDOMs enabled, select Global > System > VDOM.

2. Select Create New.

3. Enter Company_A for Name, and select OK.

4. Select Create New.

5. Enter Company_B for Name, and select OK.

 

To create the virtual domains – CLI:

config system vdom edit Company_A next

edit Company_B

end

 

Configuring the Company_A VDOM

This section describes how to add VLAN subinterfaces and configure security policies for the Company_A VDOM. This section includes the following topics:

• Adding VLAN subinterfaces
• Creating the Lunch schedule
• Configuring Company_A firewall addresses
• Creating Company_A security policies

 

Adding VLAN subinterfaces

You need to create a VLAN subinterface on the port2 interface and another one on the port1 interface, both with the same VLAN ID.

 

To add VLAN subinterfaces – web-based manager:

1. Go to Global > Network > Interfaces.

2. Select Create New.

3. Enter the following information and select OK:

Name                                           VLAN_100_int

Interface                                     port2

VLAN ID                                      100

Virtual Domain                          Company_A

4. Select Create New.

5. Enter the following information and select OK:

Name                                           VLAN_100_ext

Interface                                     port1

VLAN ID                                      100

Virtual Domain                          Company_A

 

To add the VLAN subinterfaces – CLI:

config system interface edit VLAN_100_int

set interface port2

set vlanid 100

set vdom Company_A

next

edit VLAN_100_ext

set interface port1 set vlanid 100

set vdom Company_A

end

 

Creating the Lunch schedule

Both organizations have the same lunch schedule, but only Company A has relaxed its security policy to allow employees more freedom in accessing the Internet during lunch. Lunch schedule will be Monday to Friday from 11:45am to 2:00pm (14:00).

 

To create a recurring schedule for lunchtime – web-based manager:

1. In Company_A VDOM, go to Policy & Objects > Schedules.

2. Select Create New.

3. Enter Lunch as the name for the schedule.

4. Select Mon, Tues, Wed, Thu, and Fri.

5. Set the Start time as 11:45 and set the Stop time as 14:00.

6. Select OK.

 

To create a recurring schedule for lunchtime – CLI:

config vdom

edit Company_A

config firewall schedule recurring edit Lunch

set day monday tuesday wednesday thursday friday set start 11:45

set end 14:00 end

 

Configuring Company_A firewall addresses

For Company A, its networks are all on the 10.11.0.0 network, so restricting addresses to that domain provides added security.

 

To configure Company_A firewall addresses – web-based manager:

1. In the Company_A VDOM, go to Policy & Objects > Addresses.

2. Select Create New.

3. Enter CompanyA in the Address Name field.

4. Type 10.11.0.0/255.255.0.0 in the Subnet / IP Range field.

5. Select OK.

 

To configure vdomA firewall addresses – CLI:

config firewall address edit CompanyA

set type ipmask

set subnet 10.11.0.0 255.255.0.0 end

 

Creating Company_A security policies

A security policy can include varying levels of security feature protection. This example only deals with web filtering. The following security policies use the custom security strict and relaxed profiles configured earlier.

For these security policies, we assume that all protocols will be on their standard ports, such as port 80 for http traffic. If the ports are changed, such as using port 8080 for http traffic, you will have to create custom services for protocols with non-standard ports, and assign them different names.

 

The firewalls configured in this section are:

• internal to external — always allow all, security features – web filtering: strict
• internal to external — Lunch allow all, security features – web filtering:relaxed

Security policies allow packets to travel between the internal VLAN_100 interface to the external interface subject to the restrictions of the protection profile. Entering the policies in this order means the last one configured is at the top of the policy list, and will be checked first. This is important because the policies are arranged so if one does not apply the next is checked until the end of the list.

 

To configure Company_A security policies – web-based manager:

1. Go to Policy & Objects > IPv4 Policy.

2. Select Create New.

3. Enter the following information and select OK:

Name                                             CompanyA-lunch

Incoming Interface                         VLAN_100_int

Outgoing Interface                         VLAN_100_ext

Source Address                              CompanyA

Destination Address                      all

Schedule                                          Lunch

Service                                             all

Action                                               ACCEPT

Security Features                            enable

Web Filtering               relaxed

This policy provides relaxed protection during lunch hours — going from strict down to scan for protocol options and web filtering. AntiVirus and Email Filtering remain at strict for security — relaxing them would not provide employees additional access to the Internet and it would make the company vulnerable.

1. Select Create New.

2. Enter the following information and select OK:

Name                                         CompanyA-strict

Incoming Interface                     VLAN_100_int

Outgoing Interface                     VLAN_100_ext

Source Address                          CompanyA

Destination Address                  all

Schedule                                     always

Service                                         all

Action                                          ACCEPT

Security Features                       enable

Web Filtering          strict

This policy enforces strict scanning at all times, while allowing all traffic. It ensures company policies are met for network security.

4. Verify that the policy list arranged By Sequence to make sure the CompanyA-lunch policy is located above the CompanyA-strict policy. If necessary, rearrange the policies so that the appropriate policy is applied to outgoing traffic.

 

To configure Company_A security policies – CLI:

config vdom

edit Company_A

config firewall policy edit 1

set name “CompanyA-lunch” set srcintf VLAN_100_int set dstintf VLAN_100_ext set srcaddr all

set dstaddr all set action accept set schedule Lunch

set webfiltering relaxed next

edit 2

set name “CompanyA-strict” set srcintf VLAN_100_int set dstintf VLAN_100_ext set srcaddr all

set dstaddr all set action accept set schedule always

set webfiltering strict end

 

Configuring the Company_B VDOM

This section describes how to add VLAN subinterfaces and configure security policies for the Company B VDOM. This section includes the following topics:

• Adding VLAN subinterfaces
• Creating Company_B service groups
• Configuring Company_B firewall addresses
• Configuring Company_B security policies

 

Adding VLAN subinterfaces

You need to create a VLAN subinterface on the internal interface and another one on the external interface, both with the same VLAN ID.

 

To add VLAN subinterfaces – web-based manager:

1. Go to Network > Interfaces.

2. Select Create New.

3. Enter the following information and select OK:

Name                                           VLAN_200_int

Interface                                     port2

VLAN ID                                      200

Virtual Domain                          Company_B

4. Select Create New.

5. Enter the following information and select OK:

Name                                           VLAN_200_ext

Interface                                     port1

VLAN ID                                      200

Virtual Domain                          Company_B

 

To add the VLAN subinterfaces – CLI:

config system interface edit VLAN_200_int

set interface internal set vlanid 200

set vdom Company_B

next

edit VLAN_200_ext

set interface external set vlanid 200

set vdom Company_B

end

 

Creating Company_B service groups

Company_B does not want its employees to use any online chat software except NetMeeting, which the company uses for net conferencing. To simplify the creation of a security policy for this purpose, you create a service group that contains all of the services you want to restrict. A security policy can manage only one service or one group.

 

To create a chat service group – web-based manager:

1. Go to Policy & Objects > Services and select Create New > Service Group.

2. Enter Chat in the Group Name field.

3. For each of IRC, AOL, SIP-MSNmessenger and TALK, select the service in the Available Services list and select the right arrow to add it to the Members list.

If a particular service does not appear in the Available Services list, see the list in Policy & Objects > Services. Some services do not appear by default unless edited.

4. Select OK.

 

To create a games and chat service group – CLI:

config firewall service group edit Chat

set member IRC SIP-MSNmessenger AOL TALK

end

 

Configuring Company_B firewall addresses

Company B’s network is all in the 10.12.0.0 network. Security can be improved by only allowing traffic from IP addresses on that network.

To configure Company_B firewall address – web-based manager:

1. In the Company_B VDOM, go to Policy & Objects > Addresses.

2. Select Create New.

3. Enter new in the Address Name field.

4. Type 10.12.0.0/255.255.0.0 in the Subnet / IP Range field.

5. Select OK.

 

To configure Company_B firewall addresses – CLI:

config vdom

edit Company_B

config firewall address edit all

set type ipmask

set subnet 10.12.0.0 255.255.0.0 end

 

Configuring Company_B security policies

Security policies allow packets to travel between the internal and external VLAN_200 interfaces subject to the restrictions of the protection profile.

 

To configure Company_B security policies – web-based manager:

1. Go to Policy & Objects > IPv4 Policy.

2. Select Create New.

3. Enter the following information and select OK:

Name                                        CompanyB-deny-games-chat

Incoming Interface                   VLAN_200_int

Outgoing Interface                   VLAN_200_ext

Source Address                        all

Destination Address                 all

Schedule                                    BusinessDay

Service                                       games-chat

Action                                         DENY

 

This policy prevents the use of network games or chat programs (except NetMeeting) during business hours.

4. Enter the following information and select OK:

Name                                       CompanyB-lunch

Incoming Interface                   VLAN_200_int

Outgoing Interface                   VLAN_200_ext

Source Address                        all

Destination Address                all

Schedule                                    Lunch

Service                                       HTTP, DNS

Action                                        ACCEPT

Security Features                     enable

Web Filter              relaxed

This policy relaxes the web category filtering during lunch hour.

5. Select Create New.

6. Enter the following information and select OK:

Name                                       CompanyB-strict

Incoming Interface                VLAN_200_int

Outgoing Interface                VLAN_200_ext

Source Address                     all

Destination Address             all

Schedule                                 BusinessDay

Service                                    HTTP, DNS

Action                                     ACCEPT

Security Profiles                      enabled

Web Filter          strict

 

This policy provides rather strict web category filtering during business hours.

7. Select Create New.

8. Enter the following information and select OK:

Name                                      CompanyB-after-hours

Incoming Interface                  VLAN_200_int

Outgoing Interface                  VLAN_200_ext

Source Address                       all

Destination Address               all

Schedule                                   always

Service                                      ANY

Action                                       ACCEPT

Security Profiles                      enabled

Web Filter          relaxed

 

Because it is last in the list, this policy applies to the times and services not covered in preceding policies. This means that outside of regular business hours, the Relaxed protection profile applies to email and web browsing, and online chat and games are permitted. Company B needs this policy because its employees sometimes work overtime. The other companies in this example maintain fixed hours and do not want any after-hours Internet access.

 

To configure Company_B security policies – CLI:

config firewall policy edit 1

set name “CompanyB-deny-games-chat” set srcintf VLAN_200_int

set srcaddr all

set dstintf VLAN_200_ext set dstaddr all

set schedule BusinessDay set service Games

set action deny next

edit 2

set name “CompanyB-lunch” set srcintf VLAN_200_int set srcaddr all

set dstintf VLAN_200_ext set dstaddr all

set action accept set schedule Lunch set service HTTP

set profile_status enable set profile Relaxed

next edit 3

set name “CompanyB-strict” set srcintf VLAN_200_int set srcaddr all

set dstintf VLAN_200_ext set dstaddr all

set action accept

set schedule BusinessDay set service HTTP

set profile_status enable set profile BusinessOnly

next edit 4

set name “CompanyB-after-hours” set srcintf VLAN_200_int

set srcaddr all

set dstintf VLAN_200_ext set dstaddr all

set action accept set schedule always set service ANY

set profile_status enable set profile Relaxed

end

 

Configuring the VLAN switch and router

The Cisco switch is the first VLAN device internal passes through, and the Cisco router is the last device before the Internet or ISP.

This section includes the following topics:

• Configuring the Cisco switch
• Configuring the Cisco router

 

Configuring the Cisco switch

On the Cisco Catalyst 2900 ethernet switch, you need to define the VLANs 100, 200 and 300 in the VLAN database, and then add configuration files to define the VLAN subinterfaces and the 802.1Q trunk interface. Add this file to Cisco VLAN switch:

!

interface FastEthernet0/1 switchport access vlan 100

!

interface FastEthernet0/5 switchport access vlan 300

!

interface FastEthernet0/6

switchport trunk encapsulation dot1q switchport mode trunk

!

Switch 1 has the following configuration:

Port 0/1                                       VLAN ID 100

Port 0/3                                       VLAN ID 200

Port 0/6                                       802.1Q trunk

 

Configuring the Cisco router

The configuration for the Cisco router in this example is the same as in the basic example, except we add VLAN_300. Each of the three companies has its own subnet assigned to it.

The IP addressees assigned to each VLAN on the router are the gateway addresses for the VLANs. For example, devices on VLAN_100 would have their gateway set to 10.11.0.1/255.255.0.0.

 

!

interface FastEthernet0/0

switchport trunk encapsulation dot1q switchport mode trunk

!

interface FastEthernet0/0.1 encapsulation dot1Q 100

ip address 10.11.0.1 255.255.0.0

!

interface FastEthernet0/0.3 encapsulation dot1Q 200

ip address 10.12.0.1 255.255.0.0

!

The router has the following configuration:

Port 0/0.1                                    VLAN ID 100

Port 0/0.3                                    VLAN ID 200

Port 0/0                                       802.1Q trunk

 

Testing the configuration

Use diagnostic commands, such as tracert, to test traffic routed through the network.

You should test traffic between the internal VLANs as well as from the internal VLANs to the Internet to ensure connectivity.

For additional troubleshooting, see Troubleshooting Virtual Domains. This section includes the following topics:

• Testing traffic from VLAN_100 to the Internet
• Testing traffic from VLAN_100 to VLAN_200

 

Testing traffic from VLAN_100 to the Internet

In this example, a route is traced from VLANs to a host on the Internet. The route target is www.example.com. From a host on VLAN_100, access a command prompt and enter this command:

C:\>tracert www.example.com

Tracing route to www.example.com [208.77.188.166]

over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms 10.100.0.1

…

14 172 ms 141 ms 140 ms 208.77.188.166

Trace complete.

The number of steps between the first and the last hop, as well as their IP addresses, will vary depending on your location and ISP. However, all successful tracerts to www.example.com will start and end with these lines.

Repeat the tracert for VLAN_200.

The tracert for each VLAN will include the gateway for that VLAN as the first step. Otherwise, the tracert should be the same for each VLAN.

 

Testing traffic from VLAN_100 to VLAN_200

In this example, a route is traced between two internal networks. The route target is a host on VLAN_200. The Windows traceroute command tracert is used.

From VLAN_100, access a Windows command prompt and enter this command:

C:\>tracert 10.12.0.2

Tracing route to 10.12.0.2 over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms 10.100.0.1

2 <10 ms <10 ms <10 ms 10.12.0.2

Trace complete.

You can repeat this for different routes in the topology. In each case the IP addresses will be the gateway for the starting VLAN, and the end point at the ending VLAN.