The Firewall Policy configuration section is the "heart" of the firewall. The policies are the primary filter that is configured to allow or disallow certain types of network traffic through the firewall. The policies also regulate how bandwidth management, traffic shaping, is applied to traffic flowing through the WAN interface of the firewall.

When a new connection is being established through the firewall, the policies are evaluated, top to bottom, until a policy that matches the new connection is found. The Action of the rule is then carried out. If the action is Allow, the connection will be established and a state representing the connection is added to the firewall's internal state table. If the action is Drop, the new connection will be refused. The section below will explain the meanings of the various action types available.

• Drop - Packets matching Drop rules will immediately be dropped. Such packets will be logged if logging has been enabled in the Logging Settings page.
• Reject - Reject works in basically the same way as Drop. In addition to this, the firewall sends an ICMP UNREACHABLE message back to the sender or, if the rejected packet was a TCP packet, a TCP RST message. Such packets will be logged if logging has been enabled in the Logging Settings page.
• Allow - Packets matching Allow rules are passed to the stateful inspection engine, which will remember that a connection has been opened. Therefore, rules for return traffic will not be required as traffic belonging to open connections is automatically dealt with before it reaches the policies. Logging is carried out if audit logging has been enabled in the Logging Settings page.

• Source Nets - Specifies the sender span of IP addresses to be compared to the received packet. Leave this blank to match everything.
• Source Users/Groups - Specifies if an authenticated username is needed for this policy to match. Either make a list of usernames, separated by commas, or write Any for any authenticated user. If it's left blank there is no need for authentication for the policy.
• Destination Nets - Specifies the span of IP addresses to be compared to the destination IP of the received packet. Leave this blank to match everything.
• Destination Users/Groups - Specifies if an authenticated username is needed for this policy to match. Either make a list of usernames, separated by commas, or write Any for any authenticated user. If it's left blank there is no need for authentication for the policy.

Either choose a predefined service from the dropdown menu or you make a custom service.

The following custom services exist:

• All - This service matches all protocols.
• TCP+UDP+ICMP - This service matches all ports on either the TCP or the UDP protocol, including ICMP.
• Custom TCP - This service is based on the TCP protocol.
• Custom UDP - This service is based on the UDP protocol.
• Custom TCP+UDP - This service is based on either the TCP or the UDP protocol.

For many services, a single destination port is sufficient. The source port most often be all ports, 0-65535. The http service, for instance, is using destination port 80. A port range can also be used, meaning that a range 137-139 covers ports 137, 138 and 139. Multiple ranges or individual ports may also be entered, separated by commas. For instance, a service can be defined as having source ports 1024-65535 and destination ports 80-82, 90-92, 95. In this case, a TCP or UDP packet with the destination port being one of 80, 81, 82, 90, 91, 92 or 95, and the source port being in the range 1024-65535, will match this service.

If a schedule should be used for the policy, choose one from the dropdown menu, these are specified on the Schedules page. If the policy should always be active, choose Always from the dropdown menu.

The DFL-700 Intrusion Detection/Prevention System (IDS/IDP) is a real-time intrusion detection and prevention sensor that identifies and takes action against a wide variety of suspicious network activity. The IDS uses intrusion signatures, stored in the attack database, to identify the most common attacks. In response to an attack, the IDS protect the networks behind the DFL-700 by dropping the traffic. To notify of the attack the IDS sends an email to the system administrators if email alerting is converted. D-Link updates the attack database periodically. There are two modes that can be configured, either Inspection Only or Prevention. Inspection Only will only inspect the traffic and if the DFL-700 sees anything it will log, email an alert (if configured) and pass on the traffic, if Prevention is used the traffic will be logged the traffic dropped and if configured a email alert will be sent.

Traffic shaping works by measuring and queuing IP packets, in transit, with respect to a number of configurable parameters. Differentiated rate limits and traffic guarantees based on source, destination and protocol parameters can be created; much the same way firewall policies are implemented.

There are three different priorities when configuring the traffic shaping, Normal, High and Critical.

Limit works by limiting the inbound and outbound traffic to the specified speed. This is the maximum bandwidth that can be used by traffic using this policy. Note however that if you have other policies using limit; which in total is more then your total internet connection and have configured the traffic limits on the WAN interface this limit is sometimes lowered to allow traffic with higher priorities to have precedence.

By using Guarantee, you can guarantee a minimum bandwidth to a policy. This will only work if the traffic limits for the WAN interface are configured correctly.

The Port mapping / Virtual Servers configuration section is where you can configure virtual servers like Web servers on the DMZ or similar. It's also possible to regulate how bandwidth management, traffic shaping, is applied to traffic flowing through the WAN interface of the firewall. It is also possible to use Intrusion Detection / Prevention and Traffic shaping on Port mapped services, these are done in the same way as on policies, so see that chapter for more information.

User Authentication allows an administrator to grant or reject access to specific users from specific IP addresses, based on their user credentials.

Before any traffic is allowed to pass through any policies configured with username or groups, the user must first authenticate him/her-self. The DFL-700 can either verify the user against a local database or passes along the user information to an external authentication server, which verifies the user and the given password, and transmits the result back to the firewall. If the authentication is successful, the DFL-700 will remember the source IP address of this user, and any matching policies with usernames or groups configured will be allowed. Specific policies that deal with user authentication can be defined, thus leaving policies that not require user authentication unaffected.

The DFL-700 supports the RADIUS (Remote Authentication Dial In User Service) authentication protocol. This protocol is heavily used in many scenarios where user authentication is required, either by itself or as a front-end to other authentication services.

The DFL-700 can use RADIUS to verify users against for example Active Directory or Unix password-file. It is possible to configure up to two servers, if the first one is down it will try the second server instead.

The DFL-700 can use CHAP or PAP when communicating with the RADIUS server. CHAP (Challenge Handshake Authentication Protocol) does not allow a remote attacker to extract the user password from an intercepted RADIUS packet. However, the password must be stored in plaintext on the RADIUS server. PAP (Password Authentication Protocol) might be defined as the less secure of the two. If a RADIUS packet is intercepted while being transmitted between the firewall and the RADIUS server, the user password can be extracted, given time. The upside to this is that the password does not have to be stored in plaintext in the RADIUS server.

The DFL-700 uses a shared secret when connecting to the RADIUS server. The shared secret enables basic encryption of the user password when the RADIUS-packet is transmitted from the firewall to the RADIUS server. The shared secret is case sensitive, can contain up to 100 characters, and must be typed exactly the same on both the firewall and the RADIUS server.

It is possible to configure a schedule for policies to take affect. By creating a schedule, the DFL-700 is allowing the firewall policies to be used at those designated times only. Any activities outside of the scheduled time slot will not follow the policies and will therefore likely not be permitted to pass through the firewall. The DFL-700 can be configured to have a start time and stop time, as well as creating 2 different time periods in a day. For example, an organization may only want the firewall to allow the internal network users to access the Internet during work hours. Therefore, one may create a schedule to allow the firewall to allow traffic Monday-Friday, 8AM-5PM only. During the non-work hours, the firewall will not allow Internet access. When using schedules it is important to have accurate system time on the firewall via time sync or by entering correct system time by hand.

A service is basically a definition of a specific IP protocol with corresponding parameters. The service http, for instance, is defined as to use the TCP protocol with destination port 80.

Services are simplistic, in that they cannot carry out any action in the firewall on their own. Thus, a service definition does not include any information whether the service should be allowed through the firewall or not. That decision is made entirely by the firewall policies, in which the service is used as a filter parameter.

Allow ICMP errors from the destination to the source - ICMP error messages are sent in several situations: for example, when an IP packet cannot reach its destination. The purpose of these error control messages is to provide feedback about problems in the communication environment.

However, ICMP error messages and firewalls are usually not a very good combination; the ICMP error messages are initiated at the destination host (or a device within the path to the destination) and sent to the originating host. The result is that the ICMP error message will be interpreted by the firewall as a new connection and dropped, if not explicitly allowed by the firewall rule-set. Now, allowing any inbound ICMP message to be able have those error messages forwarded is generally not a good idea.

To solve this problem, DFL-700 can be instructed to pass an ICMP error message only if it is related to an existing connection. Check this option to enable this feature for connections using this service.

ALG - Like other stateful inspection based firewalls, DFL-700 filters on information found in packet headers, for instance in IP, TCP, UDP and ICMP headers.

In some situations though, filtering on header data only is not sufficient. The FTP protocol, for instance, includes IP address and port information in the protocol payload. In these cases, the firewall needs to be able to examine the payload data and carry out appropriate actions. DFL-700 provides this functionality using Application Layer Gateways, also known as ALGs.

To use an Application Layer Gateway, the appropriate Application Layer Gateway definition is selected in the dropdown menu. The selected Application Layer Gateway will thus manage network traffic that matches the policy using this service.

Currently, DFL-700 supports two Application Layer Gateways, one is used to manage the FTP protocol and the other one is a HTTP Content Filtering ALG. For detailed information about how to configure the HTTP Application Layer Gateway, please see the Content Filtering chapter.

An IPSec based VPN, such as DFL-700 VPN, is made up by two parts:

• Internet Key Exchange protocol (IKE)
• IPSec protocols (ESP)

The first part, IKE, is the initial negotiation phase, where the two VPN endpoints agree on which methods will be used to provide security for the underlying IP traffic. Furthermore, IKE is used to manage connections, by defining a set of Security Associations, SAs, for each connection. SAs are unidirectional, so there will be at least two SAs per IPSec connection. The other part is the actual IP data being transferred, using the encryption and authentication methods agreed upon in the IKE negotiation. This can be accomplished in a number of ways; by using the IPSec protocol ESP.

To set up a Virtual Private Network (VPN), you do not need to configure an Access Policy to enable encryption. Just fill in the following settings: VPN Name, Source Subnet (Local Net), Destination Gateway (If LAN-to-LAN), Destination Subnet (If LAN-to-LAN) and Authentication Method (Pre-shared key or Certificate). The firewalls on both ends must use the same Pre-shared key or set of Certificates and IPSec lifetime to make a VPN connection.

Advanced settings for a VPN tunnel is used when one needs to change some characteristics of the tunnel. This is for example some times necessary when trying to connect to a third party VPN Gateway. The different settings to set per tunnel is the following:

With this setting it's possible to limit the MTU (Max Transferable Unit) of the VPN tunnel.

Specify if Main mode IKE or Aggressive Mode IKE should be used when establishing outbound VPN Tunnels. Inbound main mode connections will always be allowed. Inbound aggressive mode connections will only be allowed if this setting is set to aggressive mode.

Here it's possible to configure the Diffie-Hellman group to 1 (modp 768-bit), 2 (modp 1024-bit) or 3 (modp 1536-bit).

If PFS, Perfect Forwarding Secrecy, is enabled, a new Diffie-Hellman exchange is performed for each phase-2 negotiation. While this is slower, it makes sure that no keys are dependent on any other previously used keys; no keys are extracted from the same initial keying material. This is to make sure that, in the unlikely event that some key was compromised; no subsequent keys can be derived.

Here it's possible to configure how the NAT Traversal code should behave.

• Disabled - The firewall does not send the Vendor ID's that include NAT-T support when setting up the tunnel.
• On if supported and need NAT - Will only use NAT-T if one of the VPN gateways is NATed.
• On if supported - Always tries to use NAT-T when setting up the tunnel.

• No keepalives - Keep-alive is disabled.
• Automatic keepalives - The firewall will send ICMP pings to IP Addresses automatically discovered from the VPN Tunnel settings.
• Manually configured IP addresses - Configure the source and destination IP addresses used when sending the ICMP pings

To agree on the VPN connection parameters, a negotiation process is performed. As the result of the negotiations, the IKE and IPSec security associations (SAs) are established. As the name implies, a proposal is the starting point for the negotiation. A proposal defines encryption parameters, for instance encryption algorithm, life times etc, that the VPN gateway supports.

There are two types of proposals, IKE proposals and IPSec proposals. IKE proposals are used during IKE Phase-1 (IKE Security Negotiation), while IPSec proposals are using during IKE Phase-2 (IPSec Security Negotiation).

A Proposal List is used to group several proposals. During the negotiation process, the proposals in the proposal list are offered to the remote VPN gateway one after another until a matching proposal is found.

• Cipher - Specifies the encryption algorithm used in this IKE proposal. Supported algorithms are AES, 3DES, DES, Blowfish, Twofish and CAST128.
• Hash - Specifies the hash function used to calculate a check sum that reveals if the data packet is altered while being transmitted. MD5 and SHA1 are supported algorithms.
• Life Times - Specifies in KB or seconds when the security associations for the VPN tunnel need to be re-negotiated.

• Cipher - Specifies the encryption algorithm used in this IPSec proposal. Supported algorithms are AES, 3DES, DES, Blowfish, Twofish and CAST128.
• HMAC - Specifies the hash function used to calculate a check sum that reveals if the data packet is altered while being transmitted. MD5 and SHA1 are supported algorithms.
• Life Times - Specifies in KB or seconds when the security associations for the VPN tunnel need to be re-negotiated.

Before a VPN tunnel with certificate based authentication can be set up, the firewall needs a certificate of its own and that of the remote firewall. These certificates can either be self-signed certificates, or issued by a CA.

This is a list of all the local identity certificates that can be used in VPN tunnels. A local identity certificate is used by the firewall to prove its identity to the remote VPN peer.

To add a new local identity certificate, click Add new. The following pages will allow you to specify a name for the local identity, and upload the certificate and private key files. This certificate can be selected in the Local Identity field no the VPN page.

This list also includes a special certificate called Admin. This is the certificate used by the web interface to provide HTTPS access.

Note: The certificate named Admin can only be replaced, not deleted or renamed. This is used for HTTPS access to the DFL-700.

This is a list of all certificates of individual remote peers.

To add a new remote peer certificate, click Add new. The following pages will allow you to specify a name for the remote peer certificate and upload the certificate file. This certificate can be selected in the Certificates field on the VPN page.

This is a list of all CA certificates.

To add a new Certificate Authority certificate, click Add new. The following pages will allow you to specify a name for the CA certificate and upload the certificate file. This certificate can be selected in the Certificates field on the VPN page.

Note: If the uploaded certificate is a CA certificate, it will automatically be placed in the Certificate Authorities list, even if Add New was clicked in the Remote Peers list. Similiarly, a non-CA certificate will be placed in the Remote Peers list even if Add New was clicked from the Certificate Authorities list.

This is a list of all the configured Identity lists. An Identity list can be used on the VPN page to limit inbound VPN access from this list of known identities.

Normally, a VPN tunnel is established if the certificate of the remote peer is present in the Certificates field in the VPN section, or if the remote peer's certificate is signed by a CA whose certificate is present in the Certificates field in the VPN section. However, in some cases it might be necessary to limit who can establish a VPN tunnel even among peers signed by the same CA.
The Identity list can be selected in the Identity List field on the VPN page.
If an Identity List is configured, the firewall will match the identity of the connecting remote peer against the Identity List, and only allow it to open the VPN tunnel if it matches the contents of the list.
If no Identity List is used, no identity matching is done.

DFL-700 HTTP content filtering can be configured to scan all HTTP content protocol streams for URLs or for web page content.

You can configure URL blacklist to block all or just some of the pages on a website. Using this feature you can deny access to parts of a web site without denying access to it completely.

The HTTP content filter can also be configured to strip contents like ActiveX, Flash and cookies.

There is also a URL whitelist for URLs that should be excluded from all Content Filtering.

To have the URL white/black list match entire sites, you will most likely want to use wildcards before and after the host names, e.g. "*example.com/*". However, this will also trigger on e.g. "myexample.com/", so you may want to split it up in two patterns, e.g. "example.com/*" and "*.example.com/*", to catch the domain name by itself as well as variants with prefixed host names ("www.") without having the filter trigger on domains ending with the same text.

Note: For HTTP URL filtering to work, all HTTP traffic needs to go trough a policy using a service with the HTTP ALG, which is the case for the "http-outbound" service by default.

Also note that the HTTP content filter cannot examine HTTPS (encrypted) connections due to their encrypted nature. If you wish to block access to HTTPS sites, you will need to configure rules in the firewall policy to block access to port 443 (https) on the IP addresses in question.

Active content handling can be enabled or disabled by checking the checkbox before each type you would like to strip. For example to strip ActiveX and Flash enable the checkbox named Strip ActiveX objects. It is possible to strip ActiveX, Flash, Java, JavaScript and VBScript. It is also possible to block cookies.