Connecting the world…


FortiMail – Howto configure DLP

The previous post showed the steps necessary to enable DLP. This post describes the workflow to configure DLP. I needed DLP to relay outbound messages to a specific mail relay based on header information.

At first I create a DLP rule to define the matching conditions. I match specific header information, which is added to a message by the internal MS Exchange server.

DLP Rule

You can match multiple conditions, like subject, recipient, sender, body or attachments and you can also use regular expressions. This makes it very powerful to match specific or multiple characteristics from a message. You can also add exceptions to the DLP rule.

The next steps involves creating a DLP Profile. The DLP profile sets the action, when the DLP rule is matched. You need to specify a default action and you can overwrite is by defining specific actions for specific DLP rules. I create an action to deliver mail to an alternate host. The action can be configured from the DLP profile pane or you can configure the action under the Content Profile Actions. I needed to configure an outbound action, which needs to be created under the Content Profile Action.Relay Action

I use the above action as default in the DLP Profile and set my scan rule to use the default action.

DLP Profile

The DLP profile can be assigned to an IP Policy or Recipient Policy. I need to relay message in the outbound direction, so I create an Outbound Recipient Policy and assign the DLP profile.

FML DLP Recipient Policy

FortiClient SSLVPN – export profiles

I am using the FortiClient SSLVPN lightweight application for SSL VPN access to client networks. In the GUI you don’t have options to export the configured profiles as you have with the full-featured FortiClient SSLVPN. The profiles for the lightweight version are stored in the registry, so you can export and import from there. The registry location is:



Useful command: netsh wlan

The management of wireless networks can be done via the Windows command “netsh wlan”. This command is especially useful when using Windows 8. You can use other “netsh” subcommands to retrieve other system information, like “netsh lan” to get information about your Wired AutoConfig Service settings.

The following table describes some options for “netsh wlan”.

Command Description
show profiles show all save profiles
delete profile name=”profile name” delete a specific profile
show profile name=”profile name” key=clear retrieve saved WPA2 PSK
show wlanreport report showing recent wireless session information
export profile “profile name” folder=c:\export export a profile with all settings to the directory c:\export
add profile filename=”c:\export\filename” user=all import a profile with all settings to all users profiles
show profile “profile name” display information on the specific wifi network
show interfaces shows a list of the wireless LAN interfaces on the system
show all display information on all currently available wifi networks
set profileorder name=”profile name” interface=”Wi-Fi” priority=1 change the priority of a wifi network

There are a lot more useful commands available. You can always use the question mark to get more options.

Aruba WPA2 with MAC authentication

Configuring an SSID with WPA2 Pre-Shared key or Enterprise authentication and encryption is very common. Sometimes you would like to add an extra authentication method. Although this method isn’t very secure, MAC authentication is still used as an extra method to strengthen the level of security of a wireless or wired network.

These days I have been configuring a Aruba Networks wireless network with one master en two local controllers. The customer is using WPA2 security and wanted to add MAC authentication as extra authentication method. The configuration of MAC authentication for Aruba Mobility Controllers is very straightforward. This blog provides an example of the MAC authentication configuration. The configuration of a MAC Authentication Profile and the definition the MAC database are key in the solution.

While testing I noticed that MAC authentication only worked when I configured the parameter “Max Authentication Failures = 1” of the MAC Authentication Profile. The MAC address of the client is blacklisted if it’s unknown. When blacklisted, the client cannot associate with any SSID for at least one hour. This wasn’t exactly what I wanted to happen.

The following log contains the user-debug information during the authentication process, when the parameter is still set to 0.

Dec 14 09:01:20 :522005: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP= User entry deleted: reason=essid change
Dec 14 09:01:20 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=N/A User data downloaded to datapath, new Role=authenticated/54, bw Contract=0/0,reason=Station resetting role
Dec 14 09:01:20 :522042: <NOTI> |authmgr| User Authentication Failed: username=cc:08:e0:5e:2c:7b MAC=cc:08:e0:5e:2c:7b IP= auth method=MAC auth server=Internal
Dec 14 09:01:22 :522026: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP= User miss: ingress=0x1200, VLAN=666
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP= User role updated, existing Role=WA-Test_role/none, new Role=WA-Test_role/WA-Test_role, reason=First IP user created
Dec 14 09:01:22 :522006: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP= User entry added: reason=Sibtye
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP= User role updated, existing Role=WA-Test_role/WA-Test_role, new Role=WA-Test_role/WA-Test_role, reason=User not authenticated for inheriting attributes
Dec 14 09:01:22 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP= User data downloaded to datapath, new Role=WA-Test_role/59, bw Contract=16385/16385,reason=New user IP processing

To me it looked like the authentication was using an OR statement instead of and AND statement. Eventually, with the help of cjoseph from Airheads Social, I noticed that after WPA2 authentication, the user gets the initial role of the AAA profile. I configured this profile as authenticated (allow all). Next MAC authentication is performed. If MAC authentication fails, the user still has the initial role from the AAA profile. If MAC authentication succeeds, the client is elevated to the MAC authentication role from the AAA profile.

I want both authentication methods to be successful before the client is granted access to the network. The only thing to change was, changing the initial role from the AAA profile to deny all.

aaa profile "WA-Test_aaa_prof"
   initial-role "denyall"
   authentication-mac "MAC_auth_prof"
   mac-default-role "WA-Test_role"
   mac-server-group "MAC-auth_srv"
   authentication-dot1x "default-psk"

Aruba: Split Tunnel with a RAP-5WN

Split Tunneling is technique, which is used very often in (SSL) VPN scenario’s. The RAP-5WN access points has multiple Ethernet ports to connect different components, like workstations or printers. You can configure the usual user roles and other settings on these Ethernet ports.

You can also configure Split Tunneling per Ethernet port. When using Split Tunneling the connected components received an IP address from the company DHCP server. By using access-control lists you can specify the traffic, which is tunnel through the RAP to the central controller. Traffic, which isn’t tunneled, is NAT’ted to the local network by using the IP address of the RAP on the local network.

The configuration example below shows you how to configure Split Tunneling for an Ethernet port on a RAP-5WN. I don’t show you the provision and creation of a VAP for the remote access points. I assume that the RAP is already provisioned and currently all traffic is tunneled to the central controller.

1. The first step involves the creation of the access-control list to specify the traffic to tunnel and the traffic to bridge locally. The access-list shows that the DHCP services (udp/67 and udp/68) and traffic to the network is tunnel to the central controller and all other traffic is locally bridged. This is the most important step when configuring Split Tunneling.

ip access-list session rap-split-tunnel-policy
any network any  permit
any any svc-dhcp  permit
any any any  route src-nat

2. Next you need to create a user role and associate the previously create access-list to the user role.

user-role rap-split-tunnel-port-role
access-list session rap-split-tunnel-policy

3. The user role needs to be tied to a AAA profile.

aaa profile “rap-split-tunnel-aaa_prof”
initial-role “rap-split-tunnel-port-role”

4. The following step contains the configuration of a wired-ap-profile.. The wired-ap-profile contains the VLAN information for the connected component, the forward-mode and you can enable/disable the Ethernet port. The configured wired-ap-profile puts the client in VLAN 50, enables the port and puts the port in Split Tunnel mode.

ap wired-ap-profile “rap-split-tunnel-wired-ap_prof”
forward-mode split-tunnel
switchport access vlan 50

5. You have all the basics configured and next you need to configure the Ethernet port profile. This profile combines the AAA profile and the wired-ap-profile.

ap wired-port-profile “rap-split-tunnel-wired-port_prof”
wired-ap-profile “rap-split-tunnel-wired-ap_prof”
no rap-backup
aaa-profile “rap-split-tunnel-aaa_prof”

6. The last step is to tie the wired-port-profile to the appropriate AP group. I configured a separate group for remote access points, called remote-o1. The configuration ties the wired-ap-profile to Ethernet 4 on the RAP-5WN.

ap-group “remote-01”
enet4-port-profile “rap-split-tunnel-wired-port_prof”

You are now ready to go!!