Policy Based Routing (PBR) Introduction

03/26/2020 486 People found this article helpful 101,627 Views

Download

Print

Share

• LinkedIn
• Twitter
• Facebook
• Email
• Copy URL The link has been copied to clipboard

Description

Policy Based Routing (PBR) Introduction

Resolution

A simple static routing entry specifies how to handle traffic that matches specific criteria, such as destination address, destination mask, gateway to forward traffic, the interface that gateway is located, and the route metric. This method of static routing satisfies most static requirements, but is limited to forwarding based only on destination addressing. SonicWall firewall (UTM) appliances running SonicOS Standard and Firmware 6.x support static routing.

Policy Based Routing (PBR) allows you to create extended static routes to provide more flexible and granular traffic handling capabilities. SonicOS Enhanced PBR allows for matching based upon source address, source netmask, destination address, destination netmask, service, interface and metric. This method of routing allows for full control of forwarding based upon a large number of user defined variables. A metric is a weighted cost assigned to static and dynamic routes. Metrics have a value between 0 and 255. Lower metrics are considered better and take precedence over higher costs. SonicOS Enhanced adheres to Cisco defined metric values for directly connected interfaces, statically encoded routes, and all dynamic IP routing protocols. Although PBR permits traffic routing based on ports and protocols, it does not perform any network and/or port translation. PBR is configured on the Network > Routing page of the web management interface on a SonicWall firewall (UTM) appliance running SonicOS Enhanced firmware.

Although PBR may seem similar to port forwarding, there are significant differences. Port forwarding allows you to create access to multiple internal servers via the same Public IP address. For example, you can allow for access to a Webserver and an FTP server via the same Public IP address even if they are two separate servers. Since the SonicWall supports inbound port forwarding, it is possible to hide internal servers off the WAN IP address. Although the packet coming from the client is destined for the WAN IP Address of the SonicWall, the SonicWall distinguishes whether to send it to the Webserver or FTP server (in our example) based on the Port. If the packet is destined for Port 80, the SonicWall will forward it to the Webserver. If it is destined for Port 21, the Sonicwall will forward it to the FTP server. This forwarding does not perform any routing between differing subnets. The internal and external IP address subnets must be directly assigned to interfaces on the SonicWall appliance or routes for them must already exist by way of implementing Policy Based Routing or use of a dynamic routing protocol. Port forwarding capability is configured on the Network > NAT Policies page of the web management interface on a SonicWall firewall (UTM) appliance running SonicOS Enhanced firmware.

See the following SonicWall Knowledge Base article for an example of Policy Based Routing in a WAN load balancing implementation:

SonicOS: Policy Based Routing and WAN Load Balancing Example on SonicOS Enhanced (KB ID 3707)

Related Articles

• ‘Error sending one-time password’ encountered when connecting to NetExtender
• Supported SonicWall and 3rd party SFP and SFP+ modules that can be used with SonicWall NSsp series
• Supported SonicWall and 3rd party SFP and SFP+ modules that can be used with SonicWall NSA series

Categories

• Firewalls > TZ Series
• Firewalls > SonicWall SuperMassive E10000 Series
• Firewalls > SonicWall SuperMassive 9000 Series
• Firewalls > SonicWall NSA Series