Connecting the world…

ip

FortiGate – IPSec with dynamic IP

Site-to-site VPN connections are a common way to connect a branch office to the corporate network. In the Netherlands it is still common to have a internet connection at a branch office with a dynamic IP address. The usage of dynamic IP address is not ideal when configuring a site-to-site VPN connection, because the configuration almost always relies on static IP addresses.

I recently configured an IPSec VPN between two FortiGate appliances and the branch appliance is using a dynamic IP address. I used Fortinet’s DDNS feature to configure the VPN.

To configure the branch FortiGate for DDNS, I had to configure the WAN interface to retrieve its IP address via DHCP. Next I configured DDNS.

config system ddns
edit 1
set ddns-server FortiGuardDDNS
set ddns-domain “branche01-booches.fortiddns.com”
set monitor-interface “wan1”
next
end

This can also be done in the GUI.

FortiDDNS

The VPN configuration on the hub firewall for dynamic DNS support is the same as the configuration of a regular VPN connection. The only difference is the configuration of the peer IP address. Instead of a static IP, you configure the DDNS FQDN.

config vpn ipsec phase1-interface
edit “vpn_p1_branche01”
set type ddns
set interface “wan1”
set proposal 3des-sha1
set dhgrp 2
set remotegw-ddns “branche01-booches.fortiddns.com”
set psksecret P$k-VPN!
next
end

And as you can image, this can also be done via the GUI.

FortiDDNS IPSec - HQ

Check the status of the VPN connection via the regular methods like cli (get vpn ike gateway or get vpn ipsec tunnel name <tunnel-name>) or via the GUI.

Citrix Secure Gateway via https-only

Configuring a Citrix Secure Gateway (CSG) server is simple, but provides a powerful solution to access resource from remote locations. CSG is an application installed on a DMZ server. Mostly I also configure the Citrix WebInterface on the same server. The CSG instance listens on TCP/443 and the WI instance listens on TCP/80. To improve the user friendliness of the solution you have to configure a redirect. This redirect changes the protocol from the unsecure http protocol to the secure https protocol. It also redirect the user to the correct login portal, like redirecting http://portal.booches.nl to https://portal.booches.nl/Citrix/XenApp/auth/login.aspx. The HTML code for the redirect is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Refresh" content="1 ;URL=https://portal.booches.nl/Citrix/XenApp/auth/login.aspx" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>Citrix Secure Gateway-Booches</title>
</head>
<body>  
<p>
        Please click <a href=’https://portal.booches.nl/Citrix/XenApp/auth/login.aspx’>here</a> if you are not automatically redirected.
</p>
</body>
</html>

This configuration requires you to allow the http and https protocols from the internet to the server. When accessing the login page the remote user connects to the CSG instance over https and the CSG instance connects to the WI instance over http. A customer noticed that a user could change the login URL from https to the unsecure http. This means that the remote user connects directly to the WI instance and bypasses the CSG instance. This behavior is not allowed and also unsecure, because username and password are sent clear text over the internet.

I wanted to change this behavior so the user isn’t allowed to connect over http to the login page, but the default redirect from http to https should still be allowed. I looked at solutions on the internet to redirect all IIS traffic from http to https, but this introduced some problems and errors. In the end I simply configured IP Address and Domain Restriction on the /Citrix/XenApp virtual directory. Only the CSG instance needs to connect to the WI instance, so the IP restrictions only allow the localhost and the server IP address. I also changed the default behavior to deny all unspecified clients.

csg-wi-ip

Catalyst 3750X licensing

While making a kit list for a network design with Cisco Catalyst 3750X switches, I got confused while looking at the different licensing features. The Cisco Catalyst 3750X switches are available with multiple licensing options, which can be upgraded.

A new switch can be ordered with two licensing options. These are LAN Base (Enhanced Intelligent Services) and IP Base (Baseline Enterprise Services). However an additional license is available: IP Services (Enterprise Services). The LAN Base feature is relative new for this switch. A normal Cisco Catalyst 3750 is a multilayer switch with routing capabilities by default. The LAN Base licensing only allows the usage of layer 2 “switching” features and no routing capabilities.

The LAN Base feature set offers enhanced intelligent services that includes comprehensive Layer 2 features. The IP Base feature set provides baseline enterprise services in addition to all LAN Base features. IP Base also includes the support for routed access, StackPower, and MACsec. The IP Services feature set provides full enterprise services that includes advanced Layer 3 features such as Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), Protocol Independent Multicast (PIM), and IPv6 routing such as OSPFv3 and EIGRPv6. IP Services feature set also includes the Embedded Event Manager (EEM) and IP service-level agreements (SLAs) initiator functionalities. All software feature sets support advanced security, QoS, and management features. The IP Services feature set is only available as an upgrade option at the time of ordering or through a license at a later time; there is no dedicated IP Services switch model. [Source]

As I mentioned before, by default, the Cisco Catalyst 3750X can only be ordered with the LAN Base or IP Base license. Customers have the ability to upgrade from LAN Base to IP Base or from IP Base to IP Services. Below you see the article numbers for the different upgrades:

C3750X-24-L-S C3750X-24 LAN Base to IP Base Paper License
C3750X-48-L-S C3750X-48 LAN Base to IP Base Paper License
L-C3750X-24-L-S C3750X-24 LAN Base to IP Base E-License
L-C3750X-48-L-S C3750X-48 LAN Base to IP Base E-License
LL-C3750X-24-L-S C3750X-24 LAN Base to IP Base E-License for Used Switch
LL-C3750X-48-L-S C3750X-48 LAN Base to IP Base E-License for Used Switch
C3750X-24-IOS-S-E C3750X-24 IP Base to IP Services factory IOS Upgrade
C3750X-48-IOS-S-E C3750X-48 IP Base to IP Services factory IOS Upgrade
C3750X-24-L-E C3750X-24 IP Base to IP Services Paper License
C3750X-48-L-E C3750X-48 IP Base to IP Services Paper License
L-C3750X-24-L-E C3750X-24 IP Base to IP Services E-License
L-C3750X-48-L-E C3750X-48 IP Base to IP Services E-License
LL-C3750X-24-L-E C3750X-24 IP Base to IP Services E-License for Used Switch
LL-C3750X-48-L-E C3750X-48 IP Base to IP Services E-License for Used Switch

Hhhhmm, as you can see you have multiple choices for upgrading from LAN Base to IP Base or from IP Base to IP Services. But what do they all mean?!?! I didn’t know exactly and had doubts, so I asked our Cisco account manager and he gave me the following information.

Factory IOS Upgrade You can directly upgrade from IP Base to IP Services at the moment you buy the switch. To receive a switch with an IP Services software image, you simply have to add the “IP Base to IP Services Factory Upgrade”. The article number contains only the license which can be used with a brand new switch.
Paper License You need to order this license if you already have the switch or if you are already using the switch. With the Paper License you receive a PAK code in paper format
E-License Comparable to Paper License, but the license is delivered via e-mail.
E-License for Used Switch This license is delivered via e-mail and needs to be ordered if you would like to upgrade a refurbished switch

The above explanation cleared a lot of my confusion about the new licensing mechanism. Hope it will help you too.

VMware: upgrade VMware Tools and Virtual Hardware for Microsoft ISA array

Today I have been troubleshooting problems with a Microsoft ISA array. The array didn’t function anymore after moving the Configuration Storage Server and one array member from a VMware 3.5 environment to a VMware 4.0 environment. After moving the array member the VMware Tools were upgraded and also the Virtual Hardware was upgraded. After rebooting the moved array member the customer received multiple error messages, like duplicate IP addresses and users not able to access resource through the reverse proxy.

A Microsoft ISA array uses Network Load-Balancing and NLB was the cause of all problems. After upgrading the VMware Tools and the Virtual Hardware, NLB needs to be reconfigured. The complete configuration of NLB was lost. I reconfigured NLB (multicast with IGMP support) and the problem was resolved. The array members were functioning properly again.

Moving and upgrading the second array member resulted in the same problems with the same cause. Reconfiguring NLB on the second array member did the trick. So be careful when moving ISA array members with NLB configured from a VMware 3.5 to a VMware 4.0 environment, especially when upgrading VMware Tools and the Virtual Hardware.

IPplan – IP address management

A lot of customers have different methods for their IP address management. Most of them use some kind of static documentation, like an Excel sheet. In the past I implemented IPplan multiple times. I like this tool, because it dynamically scans multiple IP subnets, using ICMP and/or Nmap. Another advantage of IPplan is its ability to perform hostname lookups.

Often I install IPplan on an active management system, like CactiEZ. The following howto shows the steps to implement IPplan under CactiEZ.

The first step is downloading the appropriate tar.gz file and extract his file in /var/www/html, like shown below.

tar zxvf ipplan-4.92a.tar.gz

Next I change the ownership and permissions of the ipplan directory.

chown –R apache:apache ipplan
chmod –R 750 ipplan

After changing the permissions I create the necessary database for ipplan.

mysql –u root –p
mysql> create database ipplan;

This creates a database called ipplan. Now we need to create a user with the appropriate permissions for the ipplan database.

mysql> GRANT SELECT,INSERT,UPDATE,DELETE on ipplan.* \
    -> TO ipplan@localhost IDENTIFIED by ‘password’;

You can change the value ‘password’ to a password you wish. Change the credentials, configured in the previous step, in the file called config.php.

Open a web browser and point it to the installation script in the admin directory (http://ip-address/ipplan/admin/install.php). You will be prompted to create the database schema. The user created above does not have enough permissions to create tables so you will need to either copy the statements into the database, or temporarily change the database password in the config.php file to a database user that has enough rights to do this. You could be asked to enter user credentials for the website. This user credentials can be found in config.php.

I always load the statements by copying the display output from the install.php script into a file (ipplan.sql) and then executing the file using mysql statements.

mysql –u root –p ipplan < ipplan.sql

The basic installation is now complete. We will now go ahead and create a private menu. Open the file config.php and find the section START OF MENU EXTENSION. Change this section into the following to create a private menu.

// private menu extensions to the ipplan menu system
define(“MENU_PRIV”, TRUE);
define(“MENU_EXTENSION”,
“.|4IP
..|Show used area’s|http://<ip address>/ipplan/user/modifyarearange.php?cust=1
..|Show used subnets|http://<ip address>/ipplan/user/treeview.php
..|Create new subnets|http://<ip address>/ipplan/user/createsubnetform.php
..|Edit subnets|http://<ip address>/ipplan/user/modifybaseform.php

);

The IPplan poller needs to be added to the crontab configuration. The IPplan poller uses a custom file to know which IP addresses the scan. I normally create a .txt file. The following output show the syntax for the .txt file.

172.22.2.0/24
10.10.0.0/22

I configure the poller to run every day at 9, 12 and 15. You can edit the crontab with the command:

crontab –e

# Crontab for IPplan poller
0 9,12,15 * * * php /var/www/html/ipplan/contrib/ipplan-poller.php -hostnames -c 1 -f /var/www/html/ipplan/4IP-Networks.txt

There is one last step to take. When you manually execute the command above, you will receive the following error message:

Cannot find NMAP!

The last step is to install NMAP and configure its location in config.php. CactiEZ uses yum to install packages. So I use the following command to install nmap.

yum install nmap

Nmap can be found in the directory /usr/bin/. Look for the nmap section in config.php and change the nmap configuration to the following.

//define(“NMAP”, ”);
define(“NMAP”, ‘/usr/bin/nmap’);

The rest of the configuration needs to be done through the web interface. My advise is to configure some user groups and users, before adding subnets to IPplan. You can also change more settings in config.php to match it to your own environment, like the e-mailserver and helpdesk e-mail address.

Sometimes you receive Fatal error: require_once(): Failed opening required ‘../adodb/adodb.inc.php’ message. I resolved this issue by changing line 42 & 43 in ipplan-poller.php from:

require_once(“../adodb/adodb.inc.php”);
require_once(“./config.php”);

to

require_once(“/var/www/html/ipplan/adodb/adodb.inc.php”);
require_once(“/var/www/html/ipplan/config.php”);

This should solve the problem.