Connecting the world…

address

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

Microsoft UAG – Invalid External Port bug

Last week I have installed a Microsoft UAG array. I installed Microsoft ForeFront Unified Access Gateway 2010 including Service Pack 1. When using an array configuration you have to deploy Microsoft’s Network Load Balancing (NLB) for redundancy and load balancing purposes. I configured NLB with multicast and IGMP support. I had configured some HTTPS trunks and some HTTP trunks for http-to-https redirection.

Everything was working perfectly and I decided to install the update KB2585140 (ForeFront UAG SP1 Update 1). The main reason for installation was the introduction of SharePoint 2010 with Office Web Apps and Lync web services publishing.

The installation process was easy and completed without any errors. I noticed that after installing the update I couldn’t activate any configuration changes. Everything I hit Activate I receive the following error message:

uag-error-update1

The Activation works again by deleting all HTTP trunks and only use HTTPS trunks. The customer started a support call with Microsoft and Microsoft acknowledges this behavior when installing the update on an array configuration. At first Microsoft advised to “break” the array and use a stand-alone server deployment. If that isn’t an option we should uninstall the update. We are told that the current configuration will get to the configuration state prior to the installation.

This morning the customer received another e-mail from Microsoft stating at more and more calls were logged with the same issues. The issues now has the highest priority for the Microsoft UAG developers. Microsoft couldn’t tell when the issue will be fixed, but I guess very soon.

So when using a Microsoft UAG array configuration DON’T install Microsoft UAG SP1 Update-1.

TrendMicro IMSVA – reject unknown recipients via LDAP

With the configuration and implementation of an anti-virus, anti-spam solution, I always check if the security appliance has the option to block unknown recipients via LDAP. This prevents unnecessary e-mail from being sent to the backend servers.

While configuring a TrendMicro IMSVA 8.0 I noticed that the LDAP option was available, as shown below.

ldap-check

The option can be found under Administration – IMSVA Configuration – SMTP routing. I enabled the option and configured a LDAP connection to the backend database. I started testing the LDAP check via telnet and noticed that all secondary e-mail addresses were rejected by the security appliance.

I started looking at the specific LDAP records from an user with a LDAP browser, like Softerra LDAP Browser. I noticed that all secondary e-mail addresses are under the name ProxyAddresses and the primary e-mail address falls under the name mail.

I started searching the TrendMicro knowledge base but couldn’t find a solution. I found an article about the problem, which also provided the correct solution. To enable TrendMicro IMSVA to check secondary e-mail addresses you have to login to the appliance via a SSH session and change some settings within the PostgreSQL database. You need to execute the following commands:

[root@mail ~]# cd /opt/trend/imss/PostgreSQL/bin/
[root@mail bin]# ./psql -U sa -d imss
Welcome to psql 8.1.3, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

imss=# update tb_global_setting set value=’proxyAddresses’ where name =’mail_attr’;

UPDATE 1
imss=# \q
[root@mail bin]#

Next I needed to reboot the server. After the reboot I did some more testing and this time all secondary e-mail addresses were accepted by the security appliance.

You can check your newly added entry in the PostgreSQL database with the following command:

imss=# select * from tb_global_setting where value=’proxyAddresses’;
section |   name    |     value      | inifile  | notes
———+———–+—————-+———-+——-
LDAP    | mail_attr | proxyAddresses | ldap.ini |
(1 row)

At the end I found the solution but I am very curious why this isn’t default behavior. I mean, I guess I am not the only one who is using secondary e-mail addresses?!?!

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.