How to route only SMTP traffic through a specific interface (e.g. Secondary WAN)

03/26/2020 44 14347

DESCRIPTION:

This article explains how to route only SMTP traffic through a specific interface (e.g. Secondary WAN). When a SonicWall has two Internet Service Providers, and you want to force only SMTP traffic out through one specific ISP, you must create a policy based route for SMTP traffic originating from the mail server.

RESOLUTION:

This example will show forcing of SMTP to the X2, which is the Secondary WAN.

Background:

Before the procedure is covered, you must learn about some default address objects in SonicOS, and how they have changed over time.  When a WAN interface is configured, either in static or DHCP or PPPoE or L2TP modes, a gateway IP address is either configured or learned through the dynamic connection with the upstream devices.  That gateway has an address object defined for it and is used in static routes which pertain to traffic being pushed on a specific WAN connection.  Those gateway objects have changed dramatically, as SonicOS has gone from a maximum of two WAN connections, to 4 or more WAN connections in Load Balancing code.

In SonicOS Enhanced versions 5.4 and earlier, including all Gen4 products, there are two objects named Default Gateway and Secondary Default Gateway

In SonicOS Enhanced versions 5.5 and later, there are ALSO objects named X1 Default Gateway, X2 Default Gateway or X3 Default Gateway, etc., depending on which interface you use as a secondary WAN.  The previous objects Default Gateway and Secondary Default Gateway also exist in the newer versions of SonicOS, because we must allow upgrades from earlier versions of firmware. 

It is important to know that, In SonicOS Enhanced versions 5.5 and later, the Default Gateway and Secondary Default Gateway objects are frozen in time and should not be used in any static routes or policy-based routes.

Procedure:

First we must create an address object for the private IP address of the mail server. From the left side menu click Network and the click Address Objects. Scroll to the bottom of the page, and click Add to add a new address object.

Next, we need to create the policy based route. From the left side menu click Network and the click Routing. Scroll to the bottom of the page click Add to create a static route. The source will be the address object of the mail server’s private IP address, the destination will be “Any”, and the service will be “SMTP (Send Email)”. 

NOTE:  the choice of the Gateway: address object depends on which version of SonicOS you are using.  Below you see examples of both:

In SonicOS Enhanced versions 5.4 and earlier, use Secondary Default Gateway in the route statement
In SonicOS Enhanced versions 5.5 and later, use X2 Default Gateway in the route statement

Probe-Enabled Policy Based Routing Configuration

When configuring a static route, you can optionally configure a Network Monitor policy for the route. When a Network Monitor policy is used, the static route is dynamically disabled or enabled, based on the state of the probe for the policy.

Step 1: In the Probe pulldown menu select the appropriate Network Monitor object or select Create New Network Monitor object... to dynamically create a new object.

Step 2: Typical configurations will not check the Disable route when probe succeeds checkbox, because typically administrators will want to disable a route when a probe to the route’s destination fails. This option is provided to give administrators added flexibility for defining routes and probes.

Step 3: Select the Probe default state is UP to have the route consider the probe to be successful (i.e. in the “UP” state) when the attached Network Monitor policy is in the “UNKNOWN” state. This is useful to control the probe-based behavior when a unit of a High Availability pair transitions from “IDLE” to “ACTIVE,” because this transition sets all Network Monitor policy states to “UNKNOWN.”

Step 4: Click OK to apply the configuration.

To determine which Gateway to send SMTP traffic through, you must determine which interface is the Primary WAN.  By default, this is X1.

On the left side menu bar, click Network, and the click WAN Failover & LB. On this page, the SonicWall will display which interface is the Primary WAN Ethernet Interface, and which interfaces are Alternate WANs.

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

This example will show forcing of SMTP to the X2, which is the Secondary WAN.

Background:

Before the procedure is covered, you must learn about some default address objects in SonicOS, and how they have changed over time.  When a WAN interface is configured, either in static or DHCP or PPPoE or L2TP modes, a gateway IP address is either configured or learned through the dynamic connection with the upstream devices.  That gateway has an address object defined for it and is used in static routes which pertain to traffic being pushed on a specific WAN connection.  Those gateway objects have changed dramatically, as SonicOS has gone from a maximum of two WAN connections, to 4 or more WAN connections in Load Balancing code.

In SonicOS Enhanced versions 5.4 and earlier, including all Gen4 products, there are two objects named Default Gateway and Secondary Default Gateway

In SonicOS Enhanced versions 5.5 and later, there are also objects named X1 Default Gateway, X2 Default Gateway or X3 Default Gateway, etc., depending on which interface you use as a secondary WAN.  The previous objects Default Gateway and Secondary Default Gateway also exist in the newer versions of SonicOS, because we must allow upgrades from earlier versions of firmware. 

It is important to know that, In SonicOS Enhanced versions 5.5 and later, the Default Gateway and Secondary Default Gateway objects are frozen in time and should not be used in any static routes or policy-based routes.

Procedure:

First we must create an address object for the private IP address of the mail server.

1. Login to Sonicwall Management Interface
2. Click Manage in the top navigation menu
3. Navigate to Objects | Address Objects
4. Click Add to add an address object

Next, we need to create the policy based route.

1. Navigate to Network | Routing |  Route Policies.
2. Click Add to create a static route. The source will be the address object of the mail server’s private IP address, the destination will be “Any”, and the service will be “SMTP (Send Email)”. 
   
   

   Probe-Enabled Policy Based Routing Configuration

   When configuring a static route, you can optionally configure a Network Monitor policy for the route. When a Network Monitor policy is used, the static route is dynamically disabled or enabled, based on the state of the probe for the policy.

   Step 1: In the Probe pulldown menu select the appropriate Network Monitor object or select Create New Network Monitor object... to dynamically create a new object.

   Step 2: Typical configurations will not check the Disable route when probe succeeds checkbox, because typically administrators will want to disable a route when a probe to the route’s destination fails. This option is provided to give administrators added flexibility for defining routes and probes.

   Step 3: Select the Probe default state is UP to have the route consider the probe to be successful (i.e. in the “UP” state) when the attached Network Monitor policy is in the “UNKNOWN” state. This is useful to control the probe-based behavior when a unit of a High Availability pair transitions from “IDLE” to “ACTIVE,” because this transition sets all Network Monitor policy states to “UNKNOWN.”

    Step 4: Click OK to apply the configuration.