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.
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.
I use the above action as default in the DLP Profile and set my scan rule to use the default action.
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.
FortiMail has the option to use Data Loss Prevention as enhanced security mechanism. This feature is introduced in firmware 5.3, according to the release notes. By default the DLP option is not visible on the GUI.
DLP can be enabled via the CLI, but it is a well hidden feature. The option can be enabled from the “system global” configuration. When you do a “get” or “set ?” from the “system global” menu, you don’t see the option, but you are able to type it manually.
mail # config system global
mail (global) # set data-loss-prevention enable
mail (global) # end
This enables DLP and adds a new configuration menu to the GUI.
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
set ddns-server FortiGuardDDNS
set ddns-domain “branche01-booches.fortiddns.com”
set monitor-interface “wan1”
This can also be done in the GUI.
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
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!
And as you can image, this can also be done via the GUI.
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.