Netscreen policy based routing cross virtual router

EDIT: Also read the comments, before implementing.

For a customer at work i was implementing PBR on his Netscreen NS25. Normally you have just 1 virtual router called trust-vr, which contains your trust and untrust interfaces. Inside this trust-vr you then have a routing table with a 0.0.0.0/0 route towards your ISP gateway. My customer had a second ISP connection in place to offload some of the traffic trough this connection. I connected the 2nd ISP to an unused interface and placed it in the “trust-vr” virtual router.
Problem: My new interface was not static, but PPoE (same like DHCP) and thus get it’s IP address automatically. However also the gateway is automatically received and set in the virtual router. Unfortunately automatically received gateway is set as connected type with a higher priority then any statically set default gateway. This means i got a second entry for 0.0.0.0/0 with ISP2 gateway and higher priority (thus making it the default), and all traffic went over this 2nd ISP instead of the 1st. This was not desired.

What to do ?
Make a new virtual router, for example call it “ISP2-vr” and a new zone “ISP2”. Assign your interface with the ISP2 connection to zone “ISP2” and to virtual router “ISP2-vr”. This means your automatically received default gateway is placed in the routing table of “ISP2-vr” and nothing get’s messed up.

Redirect traffic.
To redirect the desired traffic, in my case http & https, i use PBR (Policy based routing). Note the PBR should be created inside “trust-vr” virtual router, because there the traffic is originating. First we create an extended ACL. Give the ACL a number, for example 10 and assign a sequence (example number 1). In this sequence you provide the requirements. Let’s say all trafic to port 80 (http) should be redirected, then you just choose port 80, protocol TCP and leave the rest blank. Next you create a match group what basically is just an ID and name where you can assign multiple ACL’s to. Next you make an action group, where you can define an action. Now this action should be next-hop ISP2gatewayIP (this is important !) and not contain an interface. The reason is that the interface is not known to “trust-vr” virtual router so it won’t work. Combine it all in a PBR policy and assign the policy to the trust-vr.

For the next-hop action to work we need to do some tricks. First of all inside the routing table for “ISP2-vr” you need to create route like this: ISP2-gateway/32 to ISP2-gateway/32 interfaceX. Don’t ask me why but this is needed for the PBR and explained in a Juniper KB.

Now normally this should do it. But in my case my ISP2-gateway IP was not inside the ISP2-ip and subnetmask. This appears strange but is mostly the case when using PPoE. To get around this, i need to add a route in the “trust-vr” virtual router for ISP2-gatewayIP to “ISP2-vr” virtual router. That’s it PBR is operational.

You should create a policy from “Trust” zone to “ISP2” zone and allow traffic AND important enable SOURCE NAT on this policy, because your NAT set on the Trust interface won’t work because you are not routing to Untrust.

In this CLI example ethernet1 is the Trust interface, ethernet3 is the Untrust interface and ethernet4 is my ISP2.

set vrouter "trust-vr"
set source-routing enable
set sibr-routing enable
unset add-default-route
set route 0.0.0.0/0 interface ethernet3 gateway 81.246.22.xx
set route 212.71.0.yy gateway ISP2-vr
set access-list extended 20 dst-port 80-80 protocol tcp entry 1
set match-group name port80
set match-group port80 ext-acl 20 match-entry 10
set action-group name toISP2
set action-group toISP2 next-hop 212.71.0.yy action-entry 2
set pbr policy name PBRport80
set pbr policy PBRport80 match-group port80 action-group toISP2 1
exit
set vrouter "ISP2-VR"
set source-routing enable
set sibr-routing enable
set route 212.71.0.yy/32 interface ethernet4 gateway 212.71.0.yy
exit
set interface ethernet1 pbr PBRport80

  1. Hi Stan,

    Thanks for this explanation, i have almost the same situation, but my problem is that the second ISP link is an ADSL PPoE which means you got the IP address from the ISP automatically, in that case i won’t be able to define the IP address of the gateway as i don’t know it and it is been changed every time you reset the line, do you have any idea how can i follow the same steps you added but use the Interface as a gate way instead of the IP?!!
    Thanks.
    Best Regards,
    Yasser

  2. Hi yasser,
    Luckily for me the ADSL PPoE was static.
    Sometimes even with dynamic PPoE connections the gateway always stays the same. If that’s the case for you, then you can follow my example.

    If not, then you have a problem.
    1) You could put the interface back in trust-vr and find some way to make your statically set gateway a higher priority. I didn’t found out how to to do it, and someone on the juniper forum said you just can’t. But you never know.

    2) If the above fails (likely) then the only option i see is to buy a cheap router or put your ADSL modem in router mode (if it can do that). Next you can choose, either give your router a LAN IP inside your current LAN-Trust subnet. In your PBR on trust-vr you then just set next-hop lan-ip-new-router.
    Or create a new private subnet and connect that statically to your ISP2-vr and ISP2 zone set interface. Follow my example above to route traffic out trough the chosen interface.

    On both these approaches the router will do NAT and you do not need to do it on the Netscreen for this traffic. In the last approach you will need policies allowing traffic from trust to ISP2, but this last approach will also allow bandwidth shaping, while intra-zone (Trust-Trust) traffic won’t. Another note is that the last approach makes sure users never put the router-lan-ip as std. gateway instead of the Netscreen.

    Hope this helps !
    Regards Stan

  3. Just an update on this.
    The client is by now running on an SSG140 with ScreenOS 6 and there I found an option on the trust-vr virtual router to change the preference value of PPOE and DHCP connected interfaces.

    In my example this now results in all interfaces being put in Untrust and the statically assigned interfaces has the highest preference. You can still use PBR policies to force some traffic the way you want and you even have automatic failover if an interface goes down (completely down, i.e. disconnected). On ScreenOS 5 there is a problem with VIPS on multiple Untrust interfaces.

Leave a Reply