Routing Concepts in Cyberoam

Routing concepts in Cyberoam

Article explains routing concepts implemented in Cyberoam, how to define static routes and route
policies. It includes following sections:
Static route
Firewall based routes
Destination specific route
Policy based route
Explicit Source based route
Routing order

What is routing?
Routing is termed as a process of sending packets from network of one device to another network
on a different device.

Static routes (Destination based routes)

A static route is a manually configured mapping of an IP address to a next-hop destination.
By default, the Cyberoam routing table contains a single default route. You can add routing
information to the routing table by defining additional static routes.
Add static routes when you want to route traffic destined for specific network/host via a different
next hope instead of a default route. To add static route it is required to know Destination
network/Host, netmask for destination network & Next hope IP address. The gateway address
specifies the next-hop router to which traffic will be routed.
A static route causes packets to be forwarded to a different next hope other than the configured
default gateway. By specifying through which interface/gateway the packet will leave and to which
device the packet should be routed, static routes control the traffic exiting Cyberoam.
Example:
The following example walks you through the process of creating a static route when Cyberoam is
deployed as Gateway.
Cyberoam is connected to LAN via switch and configured with multiple links. As Cyberoam is
configured with multiple Internet connectivity for load balancing, it will load balance web server
traffic via both the gateways Gateway 1 and 2.
It is required that all the outbound packets destined to externally hosted wed server should be
routed through a particular gateway i.e. Gateway 2 only and not through the Gateway 1. To
forward the packets for web server through Gateway 2, we need to define a static route.
IP schema
Gateway 1: 1.1.1.2
Gateway 2: 2.2.2.2
Web server hosted externally: 5.5.5.5

Routing Concepts in Cyberoam

Configuration:
Step 1. Log on to Console through ssh / telnet.
Select option 3 Route Configuration in Main Menu to go to the Router Management menu.

Step 2. In Route Management, go to option 1 Configure Static-routes/ACLs

Routing Concepts in Cyberoam

Enable configuration mode and define static route by executing command from the command
prompt as below:
router> enable <cr>
router# configure terminal
router(config)# ip route <destination IP address/netmask> <gateway IP address>
for our example, destination IP address is the IP address of the Web server i.e. 5.5.5.5/32
and gateway IP address is the IP address of the gateway through which the requests are
to be routed i.e. 2.2.2.2
router(config)# write
Write command saves the route permanently in the routing table

Routing Concepts in Cyberoam

Firewall based route

A static route 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. Static
routing method satisfies most of the requirements, but is limited to forwarding based on destination
address only.
Firewall based routing is extended static routes which provide more flexible traffic handling
capabilities. It allows for matching based upon source address, service/application, and gateway
weight for load balancing. Hence, it offers granular control for forwarding packets based upon a
number of user defined variables like:
Destination
Source
Application
Combination of all of the above
The following examples walk through how to create routes with the help of Firewall along with
other features.

1. Destination specific route

Destination specific route is same as the static route creation except that it is created from firewall
page of Web Admin Console while static route is created from Console.
Required when:
Internal users require access to externally hosted servers
Packets for external server should always be routed through a designated gateway and not
the default gateway
Example:
Cyberoam is connected to LAN via switch and configured with multiple links. Mail server is
deployed in LAN.
LAN users requests for the externally hosted server should be routed through designated gateway
i.e. Gateway 2 only and should not be load balanced.
IP schema
Gateway 1: 1.1.1.2
Gateway 2: 2.2.2.2
SMTP server (external): 5.5.5.5
Cyberoam WAN IP address:1.1.1.1/24 and 2.2.2.1/24
WAN Alias IP address: 2.2.2.5
Mail server (internal): 172.16.16.100

Routing Concepts in Cyberoam

Step 1: Go to Firewall > Host > Add and define a host i.e. IP address for the external server. You
can also add from within the firewall rule as shown in the below given screen shot.

Step 2: Go to Firewall > Create Rule to add LAN to WAN rule for the host i.e. external server
5.5.5.5

Routing Concepts in Cyberoam

Routing Concepts in Cyberoam

2. Policy based route

Required when:
Server is hosted internally and required to NAT the outbound packets
Packets from internal server should always be routed through a designated gateway and
should not be load balanced.
Example:
Cyberoam is connected to LAN via switch and configured with multiple links. Mail server is
deployed in LAN.
The traffic originated by mail server should be routed through a designated gateway and request
should be forwarded with alias IP address i.e. source NATted.
IP schema
Gateway 1: 1.1.1.2
Gateway 2: 2.2.2.2
Cyberoam WAN IP address:1.1.1.1/24 and 2.2.2.1/24
WAN Alias IP address: 2.2.2.5
Mail server (internal): 172.16.16.100

Configuration:
Step 1: Go to Firewall > Host > Add and define a host i.e. IP address for the external server. You
can also add from within the firewall rule as shown in the below given screen shot.

Routing Concepts in Cyberoam

Step 2. Go to Firewall > SNAT Policy > Create to forward the entire outbound traffic from internal
mailer to the specified IP address. For our example, specify WAN Alias IP address - 2.2.2.5

Step 3: Go to Firewall > Create Rule to add LAN to WAN rule to forward the mail server traffic to
the external server through designated gateway after natting the packets.

Routing Concepts in Cyberoam

Routing Concepts in Cyberoam

Explicit Source based routing from Gateway

Required for
Half open connections whose information is not available in Cyberoam
Example: Mail server hosted internally is used by remote users to send and receive mails and the
packets from mail server should explicitly be routed through Gateway 2.
IP schema
Gateway 1: 1.1.1.2
Gateway 2: 2.2.2.2
Cyberoam WAN IP address:1.1.1.1/24 and 2.2.2.1/24
WAN Alias IP address: 2.2.2.5
Mail server (internal): 172.16.16.100

Configuration:
To explicitly route the traffic of a particular host/network from a designated gateway, one has to
add host/network under the designated gateway.
Step 1: Go to System > Gateway > Manage Gateway(s) and define the all the gateways other than
the default gateway. Default gateway is defined at the time of Deployment.

Routing Concepts in Cyberoam

Step 2: Go to System > Gateway > Manage Gateway(s) and click the gateway for which
host/network is to be added

Traffic from the specified host/network will be routed from the selected gateway.

Note:
If explicit source based routing is not defined then in above mentioned cases, the first return

Routing Concepts in Cyberoam

packet (Syn + Ack) from mail server may be routed through either of the gateway, resulting into
incomplete 3-way handshake. But incase of TCP packet, firewall maintains session information
only when 3-way handshake is complete. Hence it is required to explicitly route such half open
connection from the gateway itself.

Routing Order
Cyberoam provides number of ways to define routes when configured to use multiple gateways.
When more than one route is configured, Cyberoam processes route in the following order:
1. Static route (Destination based route)
2. Firewall based routes (Source, Destination or Application based route)
3. Explicit source based route
4. Default Gateway Default gateway is defined at the time of deployment.

Document version: 2.0-27/12/2007