Corelan Cybersecurity Research

Scenario : you have 1 Juniper firewall, which has 2 internet connections : an expensive but reliable 4Mbit connection, and a fast, less expensive, but less reliable 20Mbit connection.

Goal : use the reliable connection for smtp traffic (1Mbit) and http traffic (3Mbit), and route all other internet traffic over the other connection

The techniques that we’ll use to make this work are : routing, policy based routing, traffic shaping and policies

This is how it is done :

Routing

When you only have one internet connection, the default route on your firewall points to the ISP router. But now we have 2 ISP routers, so we’ll have to make a choice :

• route all traffic to ISP router 1 by default (not recommended, because most traffic should go to ISP 2)
• route all traffic to ISP router 2 by default (looks better, but we still need to find a solution for the smtp and http traffic)
• use Equal Cost Multipath routing by creating 2 default routes with the same preference, and point each route to another ISP router (not recommended here, because ECMP routing is used to equally load balance internet traffic, on a session basis. We need to be very specific in what needs to be routed to ISP1 and what needs to be routed to ISP2)
• use PBR (Policy Based Routing) => this is what we need. Using PBR, you can specify a next-hop and filter on IP addresses, ports, ToS bits, which suits our needs here

In order to use PBR, we need to

• Create an extended access list
• Create a match group
• Assign the extended access list to the group
• Create action groups to identify the next-hop router for each ISP
• Create PBR policy
• Enable PBR on the ingress interface
• Apply PBR to the ingress zone and bind the policy to the zone
• Create a policy to allow traffic

There are 2 ways to route the traffic : either you set the default route to the ISP that will carry the majority of the traffic and use an ACL to send traffic to the other ISP (preferred and easiest configuration), or do it the hard way (without default route) and separate/reroute traffic using 2 access lists.

If you want to use the easy config (default route to 2.2.2.2), then you only need to create an acl that kicks in for the smtp and http traffic.  But since I want to demonstrate the possibilities of PBR, I’ll do it the hard way in this example :

## set up the access-lists
ssg5-> set vrouter trust-vr
ssg5(trust-vr)-> set access-list extended 10 dst-port 25-25 protocol tcp entry 1
ssg5(trust-vr)-> set access-list extended 10 dst-port 80-80 protocol tcp entry 2

ssg5(trust-vr)-> set access-list extended 20 dst-port 1-24 entry 1
ssg5(trust-vr)-> set access-list extended 20 dst-port 26-79 entry 2
ssg5(trust-vr)-> set access-list extended 20 dst-port 81-65535 entry 3
ssg5(trust-vr)-> set access-list extended 20 dst-port 25-25 protocol udp entry 4
ssg5(trust-vr)-> set access-list extended 20 dst-port 80-80 protocol udp entry 5

## create the match groups and assign the extended acl to the group
ssg5(trust-vr)-> set match-group name ISP4MBit
ssg5(trust-vr)-> set match-group ISP4MBit ext-acl 10 match-entry 10

ssg5(trust-vr)-> set match-group name ISP20Mbit
ssg5(trust-vr)-> set match-group ISP20Mbit ext-acl 20 match-entry 10

## create action groups and set next hop
ssg5(trust-vr)-> set action-group name toISP4MBit
ssg5(trust-vr)-> set action-group toISP4MBit next-hop 1.1.1.2 action-entry 1

ssg5(trust-vr)-> set action-group name toISP20MBit
ssg5(trust-vr)-> set action-group toISP20MBit next-hop 2.2.2.2 action-entry 1

## create pbr and bind action group with match group
ssg5(trust-vr)-> set pbr policy name separate-traffic
ssg5(trust-vr)-> set pbr policy separate-traffic match-group ISP4MBit action-group toISP4MBit 1
ssg5(trust-vr)-> set pbr policy separate-traffic match-group ISP20MBit action-group toISP20MBit 1
ssg5(trust-vr)-> exit

## enable PBR on the ingress interface (in the LAN zone !!!!)
ssg5-> set interface ethernet0/0 pbr

## enable the PBR policy on the entire zone
ssg5-> set zone LAN pbr separate-traffic

## create policy to allow traffic
ssg5-> set policy from Lan to Internet any any any nat src permit

As explained earlier, in this example we have created an access-list that will cover all non smtp and http traffic. Hence, there is no need for a default route on the firewall. The action-groups will ensure that all traffic go the the correct ISP routers.  The drawback of this configuration is that, if you want to extend the ACL for the 4MbitISP, then you’ll need to change both ACLs, and this will increate complexity without increasing flexibility.

Again, this was just an example, in case you need to use multiple access lists and multiple entries per access list, but it is not the recommended setup.

So far so good, but the smtp and http traffic sessions will take as much bandwidth as they can. One of the requirements was to limit the amount of bandwidth that can be taken by SMTP to 1Mbit, and to limit the amount of bandwidth that can be taken by HTTP to 3Mbit.

In fact, we’ll give SMTP 512KB guaranteed, allow burst to 1Mbit, and we’ll give HTTP 2Mbit guaranteed, burst to 3Mbit.  This can be done with traffic shaping :

Set up traffic shaping

Add the following 2 policies BEFORE the any any any policy that we have created above

set policy from Lan to Internet "Any" "Any " "SMTP" nat src permit traffic
     gbw 512 priority 0 mbw 1024
set policy from Lan to Internet "Any" "Any " "HTTP" nat src permit traffic
     gbw 2048 priority 0 mbw 3072

The gbw parameter indicates the guaranteed bandwdith, the mbw parameter refers to the maximum bandwidth

As soon as you create one policy with traffic shaping parameters, traffic shaping becomes active.  You can globally disable traffic shaping again by using “set traffic-shaping mode off”

You can view the traffic shaping statistics by looking at the policy information.  Suppose the SMTP policy has id 5, then you can see all stats by executing the following command :  “get policy id 5”

Set bandwidth restrictions on an interface

This option is not required for our example, but if you want to enforce interface based bandwidth restrictions, this is how it can be done :

Suppose you want to limit the amount of bandwidth on interface ethernet0/1 to 4Mbit, then use these commands :

set interface e0/1 bandwidth ingress mbw 4096
set interface e0/1 bandwidth egress mbw 4096

As you can see, you can specify different bandwidth parameters based on ingress or egress traffic flow.

What if one of your internet connections uses DHCP ?

If one of your internet connections uses DHCP, this will have an impact on the cost of the default route. You can put one of the links in another vrouter, so you can play with the PBR in your trust-vr and send traffic via the custom vrouter

http://8021q.blogspot.com/2007/09/juniper-netscreen-dual-untrust.html

Some notes

1. Cross-VR PBR :

If you have multiple VR’s and you need to redirect traffic via PBR to another VR, then make sure that the action-group only contains a next-hop entry and not a next-interface entry. Especially with some older ScreenOS versions, when configuring this via the WebGui, the “next-interface null” statement may be added and the setup would not work.  Check out http://kb.juniper.net/index?page=content&id=KB9404&actp=search&searchid=1231989420431 for more information. (KB also contains some information about a routing table host entry (/32) for referencing the next-hop value.

© 2008 – 2021, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.

Similar/Related posts:

Getting connected to the internet over IPv6 using Juniper/screenos Using OSPF on Juniper Netscreen Firewalls Juniper ScreenOS : default route manipulations and redistributions IPSec VPN between Windows Server 2008 and Juniper ScreenOS Using Fedora 9 as an OSPF / BGP router (Quagga / Zebra) and set up BGP between Linux and Juniper ScreenOS