home

Supported platforms

Vyatta documentation

Learn how to install, configure, and operate the Vyatta Network Operating System (Vyatta NOS) and Orchestrator, which help drive our virtual networking and physical platforms portfolio.

Application aware firewall - DPI support

Deep packet inspection (DPI) is a mechanism whereby the content of packets beyond the basic IP and transport (TCP/UDP) headers is inspected.

The application aware firewall feature allows you to apply DPI processing to firewall rules in a stateful firewall session. The recommended use case is to restrict or limit the expected protocol on a port. For example, if you have opened a port for SMTP traffic, you can use the application aware firewall to ensure that the port is used only for SMTP. You can also open a port and then restrict the set of applications that can run on the port.

When a stateful firewall session is created, the system determines the application that is running over the session, and bases decisions on the fate of packets on that application. The processing applies to TCP or UCP packets only. All packets in the session are passed until a rule in the ordered list of application firewall rules matches, or until too much traffic has passed without achieving a match.

The following example shows one method of configuring the vRouter to limit traffic on the 'smtp' port to SMTP only.

The first set of commands defines the application firewall 'ensure-SMTP' and includes a description, numbered rules, and a no-match action. (The no-match action is included for completeness; it is not required in this context, because the default value is 'dropped'.)

The second group of commands defines a standard stateful firewall and specifies the behavior for firewall rule 10. The final command ties this configuration back to the application firewall that is configured in the first set of commands by enabling the firewall state and behavior and specifying that the 'ensure-SMTP' application firewall will run within the firewall session.

set security application firewall name ensure-SMTP description 'Only allow an
SMTP session'
set security application firewall name ensure-SMTP no-match-action 'drop'
set security application firewall name ensure-SMTP rule 10 action 'accept'
set security application firewall name ensure-SMTP rule 10 name 'smtp‘


set security firewall name DPI-example rule 10 action 'accept'
set security firewall name DPI-example rule 10 description 'Allow SMTP'
set security firewall name DPI-example rule 10 destination port 'smtp'
set security firewall name DPI-example rule 10 protocol 'tcp'
set security firewall name DPI-example rule 10 session application firewall
'ensure-SMTP'

The following configuration achieves the same result as the previous example. In this simplified case, an application firewall is not defined as a container for additional configuration. Instead, this configuration applies firewall rule 10 directly to any session with application name 'smtp.' You can apply this type of configuration to sessions based on application name, application type, or application protocol.

set security firewall name DPI-example rule 10 action 'accept'
set security firewall name DPI-example rule 10 description 'Allow SMTP'
set security firewall name DPI-example rule 10 destination port 'smtp'
set security firewall name DPI-example rule 10 protocol 'tcp'
set security firewall name DPI-example rule 10 session application name ‘smtp’

Comparison of protocol and application name matching

Protocol matching and application matching can have similar results, but there are differences between the two. Consider the following commands:

set security application firewall name <name> rule <rule-number> name <app-name> 

set security application firewall name <name> rule <rule-number> protocol <app-protocol>

The first command matches a specific application by name, while the second command matches the application protocol.

For example, if the application 'facebook' is running over HTTP, the protocol layers include IP, TCP, HTTP, and facebook. The first command would specify facebook, while the second command would specify HTTP.

An issue can occur if a future release of the DPI engine gains the ability to identify a new application over HTTP, The current DPI engine cannot identify 'newapp' traffic, so it classifies it with the protocol 'http' and the application name 'http.' The updated DPI engine would continue to identify 'newapp' traffic with protocol 'http,' but the application name would change from 'http' to 'newApp.' The necessary application level rule would have to specify 'newapp' as the application name.

Best practices for protocol and application matching:

  • Use a protocol rule if you want to match any applications that use that protocol.
  • Use an application rule if you want to match only a specific named application.
  • Use more specific rules (such as application name rules) earlier in the ruleset, and more general rules (such as protocol rules) later in the ruleset as a catch-all