Quantcast
Channel: Johannes Weber – Weberblog.net
Viewing all articles
Browse latest Browse all 311

Policy-Based Routing on ScreenOS with different Virtual Routers

$
0
0
ScreenOS PBF with VRs featured image

I already puslished a blog post concerning policy-based routing on a Juniper firewall within the same virtual router (VR). For some reasons, I was not able to configure PBR correctly when using multiple VRs. Now it works. 😉 So, here are the required steps:

(This document from Juniper explains it all. I just made a few screenshots.)

My lab looks like that:

Juniper ScreenOS PBR with different VRs

The steps are quite similar to the PBR guide without multiple VRs. However, the “action group” must be set WITHOUT a “next-interface”. This CANNOT be done through the WebGUI, because it ALWAYS sets the “next-interface”, even if the checkmark is not checked! You MUST use the CLI such as this:

set vrouter trust-vr action-group name Action-Surf-DSL
set vrouter trust-vr action-group Action-Surf-DSL next-hop 10.49.254.1 action-entry 1

After this, the WebGUI correctly shows this entry without the next-interface. There is a “Note” on the Juniper page that exactly describes this for early ScreenOS 5.3/5.4 versions. However, in my current 6.3.0.r19 version, this is still the case. Furthermore, instead of the self-referenced host route I am using a default route (0.0.0.0/0) to the next-hop value, since it actually is my default router. With this default route, the PBR on the trust-vr works even without this so called self-referenced host route inside the untrust-vr. (Of course, there might be scenarios in which the next-hop value is not the default router. In these situations, you must configure this self-referenced host route.)

Here we go. Refer to the descriptions under the screenshots for more details:

Extended ACL for defining the policy-routed traffic. Match Group, simply referencing the ACL. Action Group which was configured through the CLI!! Policy, referencing the match group and action group. Policy binded to the DMZ interface. Host route inside the trust-vr to the "next-hop" via the untrust-vr. In my case: The default route inside the untrust-vr to the "next-hop" value. I am doing source NAT on all outgoing connections to the Untrust2 zone. Policy Traffic Log shows the translated source addresses.

The complete CLI commands (without policies/NAT) are the following:

set vrouter "untrust-vr"
set route 0.0.0.0/0 interface ethernet0/3 gateway 10.49.254.1 permanent
exit

set vrouter "trust-vr"
set access-list extended 1 src-ip 192.168.110.0/24 dst-ip 0.0.0.0/0 dst-port 80-80 protocol tcp entry 1
set access-list extended 1 src-ip 192.168.110.0/24 dst-ip 0.0.0.0/0 dst-port 443-443 protocol tcp entry 2
set access-list extended 1 src-ip 192.168.110.0/24 dst-port 30001-30005 protocol tcp entry 3
set access-list extended 1 src-ip 192.168.110.0/24 dst-port 33002-33002 protocol tcp entry 4
set match-group name Match-Surf-DSL
set match-group Match-Surf-DSL ext-acl 1 match-entry 1
set action-group name Action-Surf-DSL
set action-group Action-Surf-DSL next-hop 10.49.254.1 action-entry 1
set pbr policy name Policy-Surf-DSL
set pbr policy Policy-Surf-DSL match-group Match-Surf-DSL action-group Action-Surf-DSL 1
exit

set interface ethernet0/5.10 pbr Policy-Surf-DSL

 

FIN.


Viewing all articles
Browse latest Browse all 311

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>