Connecting the world…

backup

FortiGate – backup via auto-script

One of the features I would like to see in a FortiGate is the ability to automatically create backups and copy them to offline storage. Of course, this can be accomplished by adding FortiManager to the solution, but why would I need FortiManager if I only have one FortiGate (cluster). Another option would be using scripts, like Python or PowerShell, with scheduled tasks on servers to pull a backup from the FortiGate firewalls.

A very basic option would be the usage of system auto-script in FortiOS 5.4 and higher. Use this command to create CLI command scripts that can be saved and run. This gives you the possibility to auto-script the execute backup full-config commando. A disadvantage of this command is that you only have the option to use (T)FTP. There is no option to use a secure protocol like SFTP.

An example of an auto-script:


The example executes the backup command and sends the backup via TFTP to the TFTP server. The script runs every 24 hours (86400 seconds). It repeats infinite and starts automatically.

The script can also be configured via the GUI (Global >> System >> Advanced >> Configuration Scripts). More information about the feature can be found here.

ISDN Backup – still alive?

Nowadays everybody wants redundancy within their network, especially when using remote sites. Customers are using multiple ISP’s for redundancy and/or configure BGP solutions. In the old days (hear me talking with my 27 years) ISDN was often used for backup purposes and I still use it sometimes as redundancy mechanism. Everybody knows that bandwidth is the main limitation for ISDN connections, but for emergency purposes or for low-bandwidth applications, ISDN could be the ideal backup mechanism.

Lets take a look at the scenario, where two networks (HQ and branch office) are isdn_backupconnected by an IP VPN connection. This connection is the primary channel for communication between the HQ and the branch office. The IP VPN connection is terminated by a Cisco router or something comparable. Both locations also have a backup connection based on ISDN technology. The ISDN connection is also terminated on a Cisco router. You can also terminate both connections on the same router, but to increase the availability you should use separate routers. The IP VPN is preferred over the secondary ISDN connection. Both routers within the same location are configured with HSRP and the IP VPN router is the active gateway for its LAN.

The failover from the primary to the secondary connection should be performed automatically. This requires at least the configuration of a routing protocol. Since I often use Cisco routers, I would configure EIGRP as routing protocol to exchange routing information. You could also choose to use OSPF. Choosing EIGRP or OSPF as the preferred routing protocol could be worth a blog post on its own.

To form an adjacency between to routers, both routers need to be neighbors of each other. I normally configure a GRE tunnel between the two IP VPN routers, so they become “directly connected”. Both IP VPN routers can now exchange routing information. Next I would configure the dial-up connection. Mostly all traffic is directed from the branch office to the HQ, so the branch office would dial the HQ.

The ISDN router could participate in the EIGRP process. If you do so you need to exclude the EIGRP packet from the ISDN interesting traffic to prevent the ISDN connection from dialing to the HQ. There are more choices to make, like letting the ISDN routers form adjacencies when the ISDN connection is active. You can also use floating static routes on the ISDN routers and redistribute these routes into the routing protocol. You can tweak the HSRP operation by using HSRP tracking to promote the ISDN router to the active default gateway, when the IP VPN connection is unavailable.

In my opinion ISDN connections could still be a very valid way to provide a backup connection between two network locations. What is your opinion about this technology?

Automated eSafe backup

After configuring an eSafe appliance you have the option to export the configuration through the management interface, but you have to do this manually. eSafe has also a build in command line option to create a backup of the required files.

The command line allows backing up and restoring files using standard backup/restore commands. The command line option creates a tar.gz file; the same file that is created when backing up via the eSafe Appliance Manager.

I did some simple scripting to create a backup file, which is copied to a FTP server daily at 05:00 AM. When using the build in backup feature, the tar.gz file is created in the folder /var/esafe. I created two additional files (backup.sh and ftp_file) to automate the backup proces.

Below you see the content of both files:

backup.sh

#/bin/bash

cd /var/esafe
# Remove old backups
rm -rf *.tar.gz

# Create the backup with build-in eSafe backup
/opt/eSafe/esgapi –createbackup

# FTP files to Management server
ftp -inv </var/esafe/ftp_file &

ftp_file

# FTP files to Management server
open 10.10.1.10
user username password
lcd /var/esafe
cd /backup/esafe
put *.tar.gz
bye
quit

These commands create the necessary tar.gz backup file and copies this file to the FTP server. The last step is configuring the crontab to execute the command daily at 05:00 AM.

crontab

# Backup eSafe configuration
# Backup is copied via FTP to Management server
0 5 * * * bash /var/esafe/backup.sh

I guess the script couldn’t be more easy, but it works perfectly (for me).

When running the build in backup command (/opt/eSafe/esgapi –-createbackup) eSafe looks in the file /opt/eSafe/backup.list to determine the files to backup. You could decide to extend this list with the location of the Anti-Spam & URL filtering database (/opt/eSafe/eSafeCR/ConfigFilter/ofdb/*.fdb). This saves some downloading time when restoring an eSafe appliance.

Auto Backup Configurations

Till recently I didn’t have a decent way to backup configurations from routers and switches without using some kind of management tool, like Cacti or Nagios. I wanted to automatically backup configurations by only using a TFTP or FTP server on a network.

I started looking and found the solution by using the archive and kron configurations. I decided to look for methods to backup configurations when one of the following occurrences happen:

  1. Somebody enters the save running-config to startup-config command (write memory);
  2. A certain time of day threshold is reached;

The following example configuration shows both occurrences.

archive
path tftp://192.168.1.100/C2960-01/$h
write-memory

!

kron occurrence SCHEDULE-TO-BACKUP-CONFIG at 20:00 recurring
policy-list BACKUP-CONFIG
!
kron policy-list BACKUP-CONFIG
cli write memory

The configuration above copies the configuration to TFTP server 192.168.1.100 at 20:00h every day. The configuration is also copied to the TFTP server after issuing a write memory. The syntax of the file name on the TFTP server is hostname-seq.number (e.q. SWITCH01-1, the following file would be SWITCH01-2).

I used it several times now and it works great. I use Tftpd32 as TFTP server on Windows, because it is freeware and can be configured as service.