Installing and configuring Rancid

If you have more than a couple devices in your network, you might find backing up conifig files to be a tedious task. If you have more than a handful (which most network admins will); it can become a quest..

This is where Rancid comes in, it's a small application for Linux which lets you automate the process You can also make it execute commands on the same remote devices automatically (good for clearing tunnels or other resets). It's also good because it supports Fortinet FortiGates (which for their all-in-one nature and cheapness are on the rise). But the most difficult thing I found was trying to get it installed and configured properly.

First you'll want to install your favourite flavour of linux; I'll be using Ubuntu simply due to it's popularity and available repositories.

Open up a terminal window and get to installin'

sudo apt-get install rancid

This will install Rancid onto your machine into /var/lib/rancid. It will also create a new user called rancid to be used with the application. I couldn't find any documentation on what the default password is for this user (however at least one person suggested it was rancid, that didn't work for me) so we'll want to go ahead and change it.

sudo passwd rancid

You'll be prompted to input a new password and confirm it, for simplicity's sake I just stuck with rancid.

Now we can start to configure Rancid itself. It nests devices in groups, you can execute commands to a group as a whole which makes management a lot easier. To add a group you'll have to edit the rancid.conf file, you can find this in /etc/rancid/

You'll see a bunch of commented lines in there already; we need to add one to the bottom. If you're not familiar with VI, use the arrow keys to get down to the line you want to input on, press i to enter INSERT mode and begin typing. Once you're finished, hit ESC and type :wq to write to the file and quit VI and return to the terminal.

vi /etc/rancid/rancid.conf    LIST_OF_GROUPS="toronto montreal vancouver"   :wq

Each group name is seperated by blank space, you can put in as many as you like; we'll be adding our devices to these groups afterwards.

Now that we have our groups in order, we need to generate the CVS files for them. We'll want to run this command as our rancid user.

sudo su -c /var/lib/rancid/bin/rancid-cvs -s /bin/bash -l rancid

This will generate a directory for each of the groups you defined earlier in /var/lib/rancid/
Each directory will contain a router.db file, this is where we'll be storing our device information
So back into VI we go!

sudo vi /var/lib/rancid/toronto/router.db

The router.db files have a specific syntax and if you mess it up, it won't work; so be careful!
For a basic entry you'll need to input the following

#toronto-c1811
192.168.2.1:cisco:up

This will point at a Cisco device with the IP of 192.168.2.1 and tell Rancid that the device is up. Each variable is separated by a colon. If the status is set to down the script will ignore that device. Rancid supports the use of FQDNs in place of IP addresses, however I do not use them. Lines beginning with # are comments, it would be good habit to comment each device you add (even if you're using an FQDN). For the entire list of options refer to the man page from Shrubbery Networks

So Rancid knows where to find our devices, but like hell it'll be able to login; so we need to define that as well. Rancid keeps all it's login information in .cloginrc located in /var/lib/rancid/. When I installed Rancid, this file wasn't auto-generated (apparently there's a sample-cloginrc but I wasn't able to find it on my machine) so I had to create it with VI:

sudo vi /var/lib/rancid/.cloginrc

Quick linux note: anything starting with a period is a "hidden" file and will not show up with ls

We should have a blank VI file open right now, get into INSERT mode and put in your box's login creds.

add method 192.168.2.1 ssh
add user 192.168.2.1 cisco
add password 192.168.2.1 cisco cisco

The first line will define what protocol to connect with, in the case you have SSH and Telnet enabled (which I would advise against but whatever)
You can put in:

add method 192.168.2.1 ssh telnet

Rancid will first attempt to connect on SSH, then fall back to Telnet in the event of a failure. The second line is the username, and the third is both the password and the enable password. Now there is a lot of other options you can put here which I don't personally use, but feel free to browse them on the man page.

I found that for Rancid to run we'll have to give our rancid user ownership of rancid install directory and turn our new login file into read/writeble (but not exedcuteable) only by it's owner (which we're about to make rancid)

sudo chmod 600 /var/lib/rancid/.cloginrcsudo 

chown -R rancid:rancid /var/lib/rancid

Now we're ready to run Rancid!

sudo su -c /var/lib/rancid/bin/rancid-run -s /bin/bash -l rancid

It should take a little bit to run (depending on how many devices you have an how big their config files are)
Once it's finished you can check the log in /var/log/rancid and check your config file in /var/lib/rancid/toronto/configs/192.168.2.1

And thats it! Put it on a cron job and you'll never have to do it manually again.

Observium Integration

This was a very annoying task to get to work, but once it's work its bloody brilliant.
You'll have to do things a little differently because Observium uses hostnames opposed to IP addresses for adding devices. So I went and edited my /etc/hosts file to reflect the devices I was adding.

Open your config file for Observium and point towards your Rancid configs:

vi /opt/observium/config.php 

$config['rancid_configs'][]              = '/var/lib/rancid/toronto/configs/';
$config['rancid_ignorecomments']        = 0;

Now provided your config files are showing up with hostnames opposed to IP addresses. Everything should  work. However this is where I got stuck, and it's the most linux of problems; user groups. Observium will be accessing the Rancid config  using the apache's www-data user, which isn't in our rancid user group.

usermod -a -G rancid www-data

Now once you restart your apache service (service apache2 restart) you should be good to go! You'll know its working because Observium will add a config tab to the device page.

NOTE: I had installed Rancid on top of Turnkey's Observium distro and found that telnet was not installed by default; apt-get install telnet to fix.

 

Implementing NSRP

NetScreen Redundancy Protocol (NSRP) is a proprietary protocol that provides configuration, run time object (RTO) redundancy, and device failover for NetScreen devices in a high availability (HA) cluster.

Connection

Juniper has pre-configured their more powerful devices with an HA zone. This zone allows the devices in the cluster to transfer and receive NSRP data and information from one another.

The SSG140 and above have this zone pre-installed. For devices that do not natively support it, a license from Juniper and manual configuration is required.

On some NetScreen devices, there are multiple dedicated (physical) HA interfaces. Each interface handles different kinds of HA communication as well as act as a back-up interface should one fail. By default, HA1 handles control messages and H2 handles data messages.

On NetScreen devices that do not have dedicated HA interfaces, you must bind one or two physical ethernet interfaces to the HA zone. For this demonstration we'll be using ethernet1/4.

set int eth1/4 zone "HA"

The devices will now know which interface to listen for NSRP messages. Input the NSRP commands to set up the cluster; the cluster ID must be identical on both devices. An NSRP cluster acts similar to a cluster in any other technology; it simply groups devices together.

set nsrp cluster id <#>
set nsrp cluster name <name>

Priority

A VSD group is a set of physical devices that make up a single virtual security device (VSD). One physical device acts as the primary of the VSD group. The virtual security interface (VSI) of the VSD is bound to the physical interface of the primary device. The other physical device acts as the backup. A VSD acts similar to a RAID array; a single virtual device made up of a cluster of physical devices.

We need to tell the firewalls which one is the master, and which one is the backup. The priority of the preferred backup should be a higher value, as the lower priority takes precedence. We want the device we're configuring to be the master but because we don't want it to take over until we're ready, we'll go ahead and set the priority to 200.

set nsrp vsd-group id 0 priority 200

Ctrl-S

At this point we'll want to save the configurations we've made so they don't conflict when loading the mirror configuration over.

save

Ctrl-C

Because we're configuring a brand new ISG, no extensive config exists. But we've set up NSRP already, and our backup has a configuration, so lets just copy that over.

exec nsrp sync global-config save

NOTE: Because this is an exec command, it has to be issued via a console connection

After this command is input, the device needs to be reset by simply issuing the reset command. Upon reboot, we should go through the configuration to make sure everything is correct. After POST it will tell you which commands (if any) failed, but it never hurts to be thorough.

Sync

Defining a NetScreen device as a member of a cluster and specifying RTO synchronization automatically enables the local device to send and receive RTOs. By default, NSRP cluster members do not synchronize RTOs. Before enabling RTO synchronization, you must first synchronize the configurations between the cluster members. Unless the configurations on both members in the cluster are identical, RTO synchronization might fail.

set nsrp rto-mirror sync

Run-time objects (RTOs) are code objects created dynamically in memory during normal operation. Some examples of RTOs are session table entries, ARP cache entries, DHCP leases, and IPSec security associations (SAs). In the event of a failover, it is critical that the current RTOs be maintained by the new master to avoid service interruptions. To accomplish this, RTOs are backed up by the members of an NSRP cluster. Working together, each member backs up the RTOs from the other, which allows RTOs to be maintained should the master of either VSD group in an active/active HA scheme step down.

Taking Control

Enable the preempt option for a device that you want to be master of the VSD group (which is the one we're configuring). Normally, that device also has the better priority number (closer to 1). In the event of a failover resulting in the new master having a lower priority than the previous master, when the previous master—with the preempt option set—becomes operable and eligible again, it automatically regains mastership of the VSD group. So basically, if our master fails and the backup takes over, but the master recovers it will regain control of the cluster. Because we are configuring a NEW master, once connected and configured it will automatically take over. We'll also want to lower the priority back down to 1.

WARNING: Before making this device the master we'll have to recable

set nsrp vsd-group id 0 priority 1
set nsrp vsd-group id 0 preempt 

Monitor

Now what we have configured the device for NSRP, we need to tell it which connection to monitor. The interface we choose will typically be the WAN interface, if this interface goes down the fail-over initiates and the back-up device takes over control of the VSD.

set nsrp monitor int eth1/3

Restoring Order

Everything is configured as it should be. Now we'll just want to make some tweaks.
First we would want to change the hostname of the device, so we can distinguish between the two.

set hostname <hostname>

If we want to have remote access to the device we'll need to setup management IP interfaces for us to use.

set interface ethernet1/1 manage-ip 192.168.1.2
set interface ethernet1/3 manage-ip 192.168.2.1

Now we'll be able to remote in through 192.168.1.2 and 192.168.2.1

We'll also need to change the speed and duplex settings on the interfaces as these do not get copied over

set int ethernet1/1 phy full 100mb
set int ethernet1/3 phy full 100mb

This will set eth1/1 and eth1/3 to full/100.

And that's it! We're finished and your device should be up and running as before.

EasyVPN LDAP Authentication

The following is a tutorial on how to enable an ASA to use LDAP (Active Directory) group policy for log-in authentication when connecting via Cisco EasyVPN.

LDAP stands for Lightweight Directory Access Protocol, which is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Or in simpler terms, LDAP lets you access AD.

For the sake of this tutorial we will be adding a group to an ASA 5510

Add the AD group to the attribute map

We need to tell the ASA what domain and group to look at for the authentication process.

An attribute map for our purposes, is essentially a list of VPN groups that we want to use.
CN=Foobar VPN is setting Foobar VPN as the AD group. This is the exact name configured on the AD Server.
OU=VPN Groups is setting the OU as "VPN Groups". This is the OU that contains the Foobar VPN group on the AD Server.
DC=foobar, DC=com sets the domain as foobar.com
and lastly FoobarVPN is the local (the ASA's) name for this group.

ldap attribute-map LDAPAttMap
 map-value memberOf "CN=Foobar VPN,OU=VPN Groups,DC=foobar,DC=com" FoobarVPN

Define a group policy

So the ASA knows about the Windows server, but we don't have a local group policy set up for the VPN group. There's a whole whack of attributes that can be defined so lets get crackin'.

We won't be using a WINS server so here we define that as none. But we do have two local DNS servers, 192.168.1.11 and .12. The group policies allow you to define how many users that we're going to allow in at once. For this group we only want three at any one time.The vpn-filter is just an ACL to be applied to this tunnel. vpn-tunnel-protocol allows us to choose which encryption protocol we wish to use for the tunnel, here we've chosen SSL. This VPN is a split-tunnel , which allows users to access a public network (the internet) as well as a LAN at the same time using the same physical connection. Which LANs are accessible can be defined using the split-tunnel-network-list command. The value is simply another ACL. default-domain simply defines the domain this VPN will be accessing. address-pools lets us choose the DHCP pool we'll be using for addressing the connected clients. And lastly, we tell the ASA that the clients will be connecting through WebVPN and that the Cisco AnyConnect installer should remain installed after use.

group-policy FoobarVPN internal
group-policy FoobarVPN attributes
 wins-server none
 dns-server value 192.168.1.11 192.168.1.12
 vpn-simultaneous-logins 3
 vpn-filter value FoobarFilter
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value FoobarVPN_Split
 default-domain value foobar.com
 address-pools value VPNPool
 webvpn
 anyconnect keep-installer installed

Setup a tunnel-group for remote access

Now that we have the ASA aware of the AD server and the group we need to use. We have to setup a tunnel group for our users. Tunnel groups contain a small number of attributes that pertain to creating the tunnel itself. Tunnel groups include a pointer to a group policy that defines user-oriented attributes.

Firstly, we have to set the FoobarVPN group that we defined previously as a remote-access group.
Now we can start to define some general attributes.

address-pool VPNPool defines VPNPool as the DHCP address pool (this pool is not defined in this tutorial). You can set up to 10 external DHCP servers and 6 pools. Because we are using the ASA as the DHCP server, it is not explicitly defined here.

authentication-server-group Foobar_LDAP specifies Foobar_LDAP as the AAA server group. This tutorial assumes this as been pre-defined. I'll include a snippet on how to quickly configure it at the bottom of this page.

default-group-policy FoobarVPN tells the ASA that the FoobarVPN we created in step two is the default policy group for this tunnel-group.

Going into the webvpn-attributes sub-tree we can enable WebVPN to use the FoobarVPN we defined in step two.

tunnel-group FoobarVPN type remote-access
tunnel-group FoobarVPN general_attributes
 address-pool VPNPool
 authentication-server-group Foobar_LDAP
 authentication-server-group (Internal) Foobar_LDAP
 default-group-policy FoobarVPN
tunnel-group FoobarVPN webvpn-attributes
 group-alias FoobarVPN enable

Bonus Round! Setting up the Authentication Server!

Welcome to the bonus round! This snippet will help you in initially configuring your ASA (or if you have the unfortunate pleasure of owning a PIX) to use an LDAP server.

So we're using LDAP so lets tell the ASA that: aaa-server Foobar_LDAP protocol ldap defines our server as Foobar_LDAP and specifies the protocol as LDAP .

Okay we told it a server exists, now we need to tell the ASA where to find it: aaa-server Foobar_LDAP (Internal) host 192.168.1.2 associates the Foobar_LDAP server we defines two seconds ago with the 192.168.1.2 IP address and lets the ASA know it's an internal server.

Then we specify the domain in which the server exists, foobar.com

And finally we give it the password, domain log-in, and tell the ASA that the server is running Windows.

aaa-server Foobar_LDAP protocol ldap
aaa-server Foobar_LDAP (Internal) host 192.168.1.2
 ldap-base-dn dc=foobar,dc=com
 ldap-group-base-dn dc=foobar,dc=com
 ldap-scope subtree
 ldap-naming-attribute saMAccountName
 ldap-login-password *****
 ldap-login-dn vpnasa@foobar.com
 server-type microsoft
 ldap-attribute-map LDAPAttMap

Creating a VIP in ScreenOS

Port-forwarding in the Juniper world is done by creating MIPs, VIPs and DIPs. A virtual IP (VIP) address maps traffic received at one IP address to another address based on the destination port number in the TCP or UDP segment header. Mapped IP (MIP) is a direct one-to-one mapping of one IP address to another(public ip to private ip ) that means hiding some resources (server) from the public. A dynamic IP (DIP) address pool is a range of IP addresses from which the device can dynamically take addresses to use when performing NAT on the source IP address of outgoing or incoming IP packets.

You can link three types of interfaces to Dynamic IP (DIP) pools: physical interfaces and sub-interfaces for network and VPN traffic, and tunnel interfaces for VPN tunnels only

The most common use for a VIP is to map several DMZ intranet servers to a single public ip address on very small firewalls.

Setup

NOTE: a VIP must be created in the same network as the interface. If you want to forward from another subnet, you need to use NAT-DST

You can create a VIP under two conditions:
1. Your client's Public IP address is on the same network as the Firewall's Untrust interface IP address
2. Your client's Public IP address is the same IP address as the Firewall's Untrust interface IP address

You can assign the IP for the VIP in three ways.
1. Interface IP
2. Zone IP (Untrust)
3. Statically assign it

The address you assign your VIP must be on the same subnet as your Untrust (or the same address entirely), this only comes in to play when using option 3

interface-ip is your best bet for a dynamic address but will only work on ver 6.1 and up
untrust-ip is your next best alternative for use with a dynamic address, but if you have multiple interfaces in the untrust zone, it will choose the default (usually e0/0)
static is if you have the privledge of having a static IP adddress on the interface

For every port you wish you forward, you have to create a unqiue VIP
For example, if you want IMAP and SMTP traffic forwarded to your server at 192.168.1.101 you'll need to set up two VIPs on your outside interface:

set int e0/0 vip interface-ip 143 "IMAP" 192.168.1.101
set int e0/0 vip interface-ip 25 "SMTP" 192.168.1.101

Switcharoo

Sometimes you will need to forward unconventional ports; usually it's either to hide which ports you have open, or simply to accommodate software.
To do this you will need to explicitly define the service.

Say I want to use port 15011 for my BitTorrent traffic because the standard 69xx ports are being blocked; well Juniper doesn't know what operates on port 15011 because it's a non-standard port, therefore I'll have to define it. Because I know BitTorrent operates on 6881-6999, I can narrow down what traffic is forwarded.

set service "BitTorrent_15011" protocol tcp src-port 6881-6999 dst-port 15011-15011

Execution

Now we'll be able to apply this service to a policy (ACL on Cisco appliances)

set policy id 100 from "Untrust" to "Trust" "Any" "VIP(ethernet0/0)" "HTTP" permit log
set policy id 100
set service "BitTorrent_15011"

This will allow all traffic inbound to port 6881-6999 to be forwarded to my 192.168.1.101 client on port 15011.

Mind you, whatever your destination client is, has to be configured to be listening on the port the traffic is being forwarded to. In this case 15011.

Bouncing a tunnel on ScreenOS

So the tunnels down and the head resides on an SSG520 and you have no idea how to bounce it. Well you're in luck, this'll show you how to do it!

First! Connect to the SSG520. Make sure you don't muck around in this box because you can break many many things if you're not careful.

You'll need to connect via telnet or SSH depending on what's configured

Information Gathering

You'll need three commands to find VPN Tunnel information.

The first is:

get ike gateway

You'll be shown the IKE gateway configurations and the Phase 1 proposals as seen below.

SSG520-1(M)-> get ike gateway
 Id  Name            Gateway Address Gateway ID      Mode Proposals
---- --------------- --------------- --------------- ---- ---------
   2 foobardevice    192.168.1.2                     Main pre-g2-3des-sha

The second is:

get vpn

To see the VPN association with the IKE gateway and the Phase 2 proposals

SSG520-1(M)-> get vpn
Name            Gateway                  Mode RPlay 1st Proposal         Monitor Use Cnt Interface 
--------------- ----------------------- ---- ----- -------------------- ------- ------- ----------
foobardevice    foobardevice-isr        tunl No    g2-esp-3des-sha      on            0 eth3/0    

And lastly;

get sa

To examine the security association information.

SSG520-1(M)-> get sa | i 192.168.1.2

00000007<    192.168.1.2   500 esp:3des/sha1 7b0f24a1  2668 unlim A/U    -1 0
00000007>    192.168.1.2   500 esp:3des/sha1 4d512b11  2668 unlim A/U    -1 0

Insight

Now we have a plethora of information, but we still haven't bounced the tunnel. Lets use the information we've gathered to do that.

There's two things you'll need to clear, Phase 1 and Phase 2.

Since the editors at Wikipedia can explain this better than I can, I've provided a snippet below detailing Phase 1 and 2 for those who are unfamiliar with the process:

IKE consists of two phases: phase 1 and phase 2. IKE phase 1's purpose is to establish a secure authenticated communication channel by using the Diffie–Hellman key exchange algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP Security Association (SA). The authentication can be performed using either pre-shared key (shared secret), signatures, or public key encryption. Phase 1 operates in either Main Mode or Aggressive Mode. Main Mode protects the identity of the peers; Aggressive Mode does not. During IKE phase 2, the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like IPsec. The negotiation results in a minimum of two unidirectional security associations (one inbound and one outbound). Phase 2 operates only in Quick Mode.

Tear Down

So you're a little bit smarter, and know what we'll be clearing. Let us proceed!

Phase 1 comes first.

The first command we issued provided us with an "IKE Gateway". This is just the public address of the peer (a peer is the other end of the tunnel).

Phase 1 is stored in an IKE cookie (not chocolate chip, think a browser cookie and you'll have a better understanding of how it works). We'll have to get rid of this cookie to wipe out Phase 1 information for the specific peer.

clear ike-cookie 192.168.1.2 

Sometimes just clearing Phase 1 will cause the tunnel to rebuild. If it does not we'll have to clear Phase 2 information (it's usually safer to tear the entire tunnel down anyway).
Onward to Phase 2!

We need to clear the security association for the tunnel.

If you remember when we input get sa, on the left-hand column we saw a bunch of numbers. These are hexidecimal labels used to identify a specific association.

SSG520-1(M)-> get sa | i 192.168.1.2 
00000007<    192.168.1.2   500 esp:3des/sha1 7b0f24a1  2668 unlim A/U    -1 0
00000007>    192.168.1.2   500 esp:3des/sha1 4d512b11  2668 unlim A/U    -1 0

No we won't be doing hex conversions, don't worry. But you will notice that there are two associations for one peer. One is for inbound, and the other for outbound. You can see which is which by looking at the arrow next to the hex ID.

We'll be using that hex ID to clear that specific association.

clear sa 0x07

If you've never used hex codes before, the preceeding 0x just identifies what proceeds as hexidecimal. We don't need to provide the entire ID as it's all zeros.

And that's it! You've successfully bounced the tunnel from an SSG520.

Rebuild

We tore down the tunnel but it's not coming back up. Probably because the user thinks it's down and isn't trying to use it. A tunnel won't be established until we flood it with interesting traffic. And what could be more interesting than pings!

ping 192.168.1.10 from e3/0

Where the IP address is the VPN address at the remote site, and the interface is the one used with the tunnel.

You can find the tunnel's interface in the output from get vpn command we input earlier.

SSG520-1(M)-> get vpn
Name            Gateway                  Mode RPlay 1st Proposal         Monitor Use Cnt Interface 
--------------- ----------------------- ---- ----- -------------------- ------- ------- ----------
foobardevice    foobardevice-isr         tunl No    g2-esp-3des-sha      on            0 eth3/0    

Upgrading a Fortinet via USB

Upgrade the FortiOS version

Step 1:
Connect the FortiGate to your PC via console-to-serial cable.
Connect to the console port using your favourite terminal emulator.
The default baud rate for the connection should be 9600.

Step 2:
Log-in to the ForiGate, on a fresh box the default credentials are:
Username: admin
Password:

Verify current firmware version

get sys stat

Step 3:
Login to FortiNet Support using credentials you have.
If credentials do not work, login to FortiNet Partner Support
Navigate to the download page related to the current firmware version on the FortiGate.
Download the appropriate FortiOS images.

Be advised that you should not jump builds, download all sequential releases between the current and the desired

Step 4:
Format a USB stick to FAT16 (must be 4GB or smaller)
In Windows CMD use the follow command to format, where E: is the volume letter for that disk:

format E: /fs:fat

Copy firmware to USB stick, renaming the file to "image.out"

Step 5:
If the box is configured for auto-install from USB already, skip to Step 6
Log into the CLI and enter the following commands:

config system auto-install
   set default-image-file <filename>
   set auto-install-image {enable | disable}
end

Step 6:
Insert USB stick into the FortiGate, reboot device using the execute reboot command.
The device should automatically retrieve the image off the USB stick and commence installation upon boot.
Keep an eye on the terminal to see when the firmware update is complete; you will need to remove the USB stick when it initializes an automatic reboot.
Once it recovers, verify the firmware version.

Step 7 (Optional):
Rinse and repeat until you've reached the desired version

Update the configuration file

Step 1:
Back up the existing configuration from the defective box.
To do this, navigate to the WebGUI. Navigate to System > Dashboard > Status
Under the System Information widget, select the Backup button associated with System Configuration

When prompted, save the configuration to your Local PC

Step 2:
Copy the downloaded configuration file to the USB stick
Rename the file to system.conf

Step 3:
If the box is configured for auto-install from USB already, skip to Step 4
Log into the CLI
Enter the following commands:

config system auto-install
   set default-config file <filename>
   set auto-install-config {enable | disable}
end

Step 4:
Insert the USB stick into the FortiGate.
Issue the execute reboot command on the FortiGate. Upon boot, it will automatically retrieve the configuration file stored on the USB stick.
Once complete, remove the USB stick and verify that it was loaded correctly either through CLI or the WebGUI

Implementing QoS on a GRE tunnel

Every night at a client location, we receive disconnects and an inability to run our capture configuration. Apparently they run a massive file backup which cannot be turned off. We decided to implement QoS (Quality of Service) on the tunnel in an attempt to not be disconnected. This was a one time deal so I doubt anyone will have to do this exact implementation again but hopefully this will unconfuse you when it comes to how QoS works.

QoS is basically traffic shaping; I'm not going to go in depth into it because I know less than I probably should considering I'm writing a wiki about it...We're giving priority to certain traffic when the packets are queued outbound.

It works somewhat differently with tunnels because we need to have the packet headers inspected BEFORE encapsulation. To do this we have to declare qos pre-classify; what this does is it creates a copy of the packet and caches it, encapsulates the packet, then when it comes to apply the QoS settings, it refers to the copy rather than the outbound packet itself.

Atlas

The first thing we have to do is define a class-map. Class maps identify traffic flows using a wide array of filtering criteria which are individually defined by match statements within the class map. Multiple match statements can be defined under a single class map.

When multiple match statements are used, the class map can be specified as follows:
match-all - a logical AND operand, meaning that all match statements must be true at the same time for the class map condition to be true
match-any - a logical OR operand, meaning that any of the match statements can be true for the class map condition to be true

You can define the follow criteria to match:

  access-group         Access group
  any                  Any packets
  class-map            Class map
  cos                  IEEE 802.1Q/ISL class of service/user priority values
  destination-address  Destination address
  discard-class        Discard behavior identifier
  dscp                 Match DSCP in IP(v4) and IPv6 packets
  flow                 Flow based QoS parameters
  fr-de                Match on Frame-relay DE bit
  fr-dlci              Match on fr-dlci
  input-interface      Select an input interface to match
  ip                   IP specific values
  mpls                 Multi Protocol Label Switching specific values
  not                  Negate this match result
  packet               Layer 3 Packet length
  precedence           Match Precedence in IP(v4) and IPv6 packets
  protocol             Protocol
  qos-group            Qos-group
  source-address       Source address
  vlan                 VLANs to match

For this specific scenario, we're concerned about SNMP and Telnet traffic:

class-map match-any CM-MANAGE
 match protocol snmp
 match protocol telnet

The next map you'll have to define is the first of two policy-maps. A policy map defines a named object that represents a set of policies to be applied to a set of traffic classes. There's two types of classes you can use, one such as our MANAGE class we defined earlier, and class-default which is the system default class matching otherwise unclassified packets. For our child policy map, we need to use a user-defined class.

Once in place, we can enforce a number of things:

  bandwidth        Bandwidth
  compression      Activate Compression
  drop             Drop all packets
  exit             Exit from class action configuration mode
  fair-queue       Enable Flow-based Fair Queuing in this Class
  log              Log IPv4 and ARP packets
  netflow-sampler  NetFlow action
  no               Negate or set default values of a command
  police           Police
  priority         Strict Scheduling Priority for this Class
  queue-limit      Queue Max Threshold for Tail Drop
  random-detect    Enable Random Early Detection as drop policy
  service-policy   Configure QoS Service Policy
  set              Set QoS values
  shape            Traffic Shaping

Our implementation is farily simple, so we're just giving our SNMP and Telnet traffic a priority. When defining priority, you can specify Kbps or percentage of total bandwidth. For us, we're just giving our traffic a 50Kb window.

policy-map PM-QOS-CHILD
 class MANAGE
  priority 50

For our next map, our parent map, we need to use the class-default class. As noted before, this matches unclassified packets. Within this class, we can refer to our CHILD policy map and implement traffic shaping. We could have implemented policing; policing also puts a limit on the maximum amount of available bandwidth, however, it simply drops off any packets that go over the set limit. Whereas shaping (which we're using here) will queue the traffic, cramming as many packets as possible within the limit given.

Because QoS on tunnels can only be applied ingress, we shape for the maximum upload rate provided by the ISP; in this case it's 500000bps (488Kbps). We also have to declare our child policy we defined earlier. The reason being is you cannot apply LLQ to the default class.

Low Latency Queuing (LLQ) allows delay-sensitive data to be given preferential treatment over other traffic by letting the data to be dequeued and sent first. 

policy-map PM-QOS-PARENT
 class class-default
  shape average 500000
  service-policy PM-QOS-CHILD

Now that we've drawn up our maps, we can apply them to our tunnel interface. Remember that we have to enable pre-classification to the interface otherwise our packets will be filtered after encapsulation.

int tun0
 service-policy output PM-QOS-PARENT
 qos pre-classify

Show

To verify that our QoS setup is working, we can use the show policy-map int tun0 command (replace tun0 with whatever interface you're applying it to).

You'll have to let some appropriate traffic through before this will accumulate any data; for our purpose, I simply spammed the inside with SNMP packets.

The main things we want to look for is any dropped packets, as you can see below there are none at the moment. We also want to make sure that our class-map is matching traffic; if you look under the user-defined class-map you will see a packet count. If this any anywhere higher than zero, it means your traffic is being matched and your QoS should be working.

Tunnel0 

  Service-policy output: PM-QOS-PARENT

    Class-map: class-default (match-any)
      2566 packets, 1453477 bytes
      5 minute offered rate 11000 bps, drop rate 0 bps
      Match: any 
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
      shape (average) cir 500000, bc 131250, be 131250
      target shape rate 500000

      Service-policy : PM-QOS-CHILD

        queue stats for all priority classes:
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: CM-MANAGE (match-any)
          157 packets, 110875 bytes
          5 minute offered rate 11000 bps, drop rate 0 bps
          Match: protocol snmp
            66 packets, 100848 bytes
            5 minute rate 11000 bps
          Match: protocol telnet
            91 packets, 10027 bytes
            5 minute rate 0 bps
          Priority: 50 kbps, burst bytes 1500, b/w exceed drops: 0
          

        Class-map: class-default (match-any)
          2409 packets, 1342602 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any 
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0