With our VPN being over utilized I had to implement split tunneling on our vpn. However there are some web services that require a known IP address to access. Unfortunately these services are on AWS which the IP address changes often. I built this script to lookup the addresses and then update the Fortigate firewalls VPN Routing list to make sure that the traffic goes over the vpn tunnel and through our known IP address to access the service.

#!/usr/bin/python3
#Update Epsilon on the Fortigate Firewall VPNs

from nslookup import Nslookup
from netmiko import ConnectHandler
import cred

device1 = {
    “host”: cred.hostname,
    “username”: cred.rancid_username,
    “password”: cred.rancid_password,
    “device_type”: “fortinet”,
    “secret”: cred.rancid_password,
}

#Connect to the Fortinet
net_connect = ConnectHandler(**device1)

#Listing of the domains to query
DOMAIN_FILE = open(“domains.txt”, “r”)
#DNS Server to query
DNS_SERVER = [‘x.x.x.x’]

def LOOKUP_DOMAIN():
    #queries the specified dns server to get the info for the urls and writes the data to a config file
    dns_query = Nslookup(dns_servers=(DNS_SERVER))
    ips_record = dns_query.dns_lookup(line)
    ORDERNUMBER = 1
        for x in ips_record.answer:
            FILE_CONFIG.write(“edit ” + line + “_” + str(ORDERNUMBER) + ‘\n’)
            FILE_CONFIG.write(“set subnet ” + x + ” 255.255.255.255″ +’\n’)
            FILE_CONFIG.write(“next” +’\n’)
            ORDERNUMBER = (ORDERNUMBER + 1)

FILE_CONFIG = open(‘config.txt’,’w’)
FILE_CONFIG.write(“config firewall address” +’\n’)

for line in DOMAIN_FILE:
line = line.rstrip(‘\n’)
LOOKUP_DOMAIN()

FILE_CONFIG.write(“end” +’\n’)

FILE_CONFIG.close()

# write to the Fortigate
output2 = net_connect.send_config_from_file(config_file=”config.txt”)

Because I forget this and it always seems to cause me more pain than it should to have to rebuild one. I’ve had this happen 3 times in the 8 years of dealing with the physical 1600 LTMs all of them have failed due to some power problem that won’t let them startup completely and I end up spending 8 or more hours having to rebuild them and figure out what the heck happened to them. Luckily they have always been in a fault tolerant pair so I haven’t been down completely, but have never wanted to push the amount of time one is down because of how important they are to my company.

Steps:

Call into Support and open a ticket with the s/n of the failed unit and the error message on the screen.

If you don’t already have enhanced 4 hour replacement ask for an upgrade to it via credit card. Waiting more than 4 hours is very painful and dangerous for us.

Wait 4 hours for the new unit to come in.

While waiting:
Unrack the currently failed unit making sure that all of the cables are correctly labeled and ready to be plugged into the new unit.

Download the current version ISO along with any hot fixes to match the current install version. Download your latest backup for the unit and have it all ready and waiting to go on your laptop.

On the active unit make sure to clear out any ssh keys if needed from the failover interface

Also Reset the Device Trust under Device Management/Device Trust on the active unit

When the new unit finally arrives rack it and plug in at least the serial cable and the management ethernet cable. Before powering on plug in the recovery USB stick if it came with one that has the version of LTM that you need on it. This will greatly simplify the upgrade process and get it to at least the major version you need.

Once the unit has been upgraded to at least the major base version that you need. Login via the serial console with root/default and type config. This will let you set the management IP address for the unit.

Once the management address is set, connect to it via the browser with admin/default and start going through the licensing and configuration process.

Upload the hot fixes if necessary to the replacement unit and update to the version needed to restore the backup file. Once the hot fixes are done updating go ahead and restore the backup to the failed unit.

Hookup the failover ethernet cable.

Set backup the HA configuration between the units and ensure that you can ssh between the units on their failover interfaces.

Push the configuration from the Active unit to the new unit with an override, if it fails or there is any issue during the time run this command on the failed unit to see what the issue is:

tmsh show cm sync-status

Once it’s all done and happy it should be back in sync and in an active/standby state.

Then plug in the last of the cables for the internal/external interfaces and then you should be done.

Pack the old unit up and ship it out.