Policy-Based Routing (PBR) on a Juniper ScreenOS Firewall

Here comes an example on how to configure policy-based routing (PBR) on a Juniper ScreenOS firewall. The requirement at the customers site was to forward all http and https connections through a cheap but fast DSL Internet connection while the business relevant applications (mail, VoIP, ftp, …) should rely on the reliable ISP connection with static IPv4 addresses. I am showing the five relevant menus to configure PBR on the ScreenOS GUI.

[UPDATE] I later on wrote an article with policy-based routing with two different virtual routers. See it here.[/UPDATE]

The software version running during this test on the Juniper SSG5 was 6.3.0r16a.0.

Policy within five Submenus

The PBR configuration is straightforward through the five submenus under Network -> Routing -> PBR. The Extended ACL defines the relevant IP & Port connections which are grouped in a Match Group. The Action Group defines the forwarding to the DSL router. The Match and Action Group are tied together in a Policy which is then added to an interface in the Policy Binding.

As always, here are my configuration screenshots:

I was not quite sure on which VR/Zone/Interface the policy must be binded to. This document from Juniper points to the interface while this refers to the zone and the interface. However, it worked after binding the policy to the interface only and it worked after an additional binding to the zone, too.

Of course, a security policy must also be configured. For the sake of completeness I am showing my single policy with a SNAT, too:

PBR with different Virtual Routers

I also tried the concept with two virtual routers – one for each ISP connection. In this way, incoming connections through the DSL router would be possible, e.g., for VPNs, because it has its own default route back to the Internet. Unfortunately I was not able to correctly configure the policy-based routing to another virtual router though I followed this document from Juniper. Maybe I misunderstood something about the “self-referenced host route”. However, in my opinion this concept from Juniper looks not reliable at all. Therefore, I am using the normal PBR scenario without having the possibility to accept incoming connections.

[UPDATE] Solved. See this blog post for details with different virtual routers.[/UPDATE]

Links

11 thoughts on “Policy-Based Routing (PBR) on a Juniper ScreenOS Firewall

  1. Great article! My requirement is to forward traffic from a specific computer to one specific ISP. How different is the configuration?

    1. Hi John,

      in the first screenshot, you see the ACL which specifies what traffic to forward on the special policy. In my case, it is a whole /24 network with the port 80 and 443.
      In your case, you must specify that ACL which the source IP address of your specific computer with a destination port of any. All other settings should be applied appropriate to your situation (e.g., take your gateway IPs of the other ISP, etc.)

      1. I still can’t get it to work.

        Here is my set up

        Juniper ssg20 with two ISP (IPS1 as the main ISP and ISP2 as the failover ISP)
        ISP1 is on ethernet0/0 ISP2 is on ethernet0/1 and my trusted internal network is on ethernet0/2 which is 192.168.1.0 /24 network.

        All internet traffic is currently defaulted to ISP1.

        What I want to do is have one specific server in my 192.168.1.0 /24 network to send its traffic to ISP2 instead of the defaulted ISP1. I followed your instructions and this is what i did:

        For extended ACL
        1 192.168.1.50/24 1~65535 0.0.0.0/0 1~65535 TCP N/A Remove

        For Match group I put:
        seq no 1 and acl – ext name 1

        For Action group i put:
        Seq No 1 and Next Interface/Next Hop xxx.xxx.xx.xx (my ISP2)

        For policy I match the mat and action together

        For policy binding i binded the policy to the ethernet0/1

        I also created a policy from Trust to Untrust as you did in your tutorial

        When I go to that one specific server and do a tracert to a random website, it’s still using the ISP1 has the default route.

        Any help would be appreciated

        John

        1. Ah, that might still be related to your ACL, since you set it only to all ports of TCP. Create two more ACL entries (Add Seq No), both with the same source IP, but one with “UDP” for all ports and one with “ICMP”.

          1. your interface 0/5.10 is that the interface your IPS is connected to? also, you bind it under DMZ zone. mine screen just have trust and untrust zone.

    1. Hi John.
      – No, interface 0/5.10 is the one which is connected to the network that shall use the other ISP for its outgoing connections. My second ISP is under 0/3 (see the third screenshot). Since my interface 0/5.10 is in the DMZ zone, I bound the policy to that interface. If you are coming from the trust zone, you need to bind your policy to exactly that zone.
      – To verfiy which IP connections are used, traceroute is a good option. Furthermore, I am using some what-is-my-ip pages such as my own under http://ip.webernetz.net
      – Have you set up the source NAT translation correctly in the security policy for your second ISP?
      – Have you looked at the policy hits? Do you have “Bytes Sent” and “Bytes Received” values? Or only “Bytes Sent”? If so, there might be someting wrong with your NAT.

  2. Hi Johannes,

    PBR with two sequential VRs:
    – Install PBR on ingress VR
    – in the ActionGroup set only next hop ip-address (Gateway behind egress VR) without Interface !
    – there must be a route for the next hop ip-address in ingress vr to egress-vr
    – route next hop ip-address/32 in egress-vr to to next hop ip-address (self-referenced host route) !

    for me it works

Leave a Reply

Your email address will not be published. Required fields are marked *