Screen OS

Hi All,

I've got an SSG140 with two untrust interfaces; a cheap and fast VDSL line and an expensive, reliable but slow (2Mbit) leased line.  We use both lines for redundant route-based VPNs; the leased line is used first unless it goes down (handled nicely by OSPF).

I'd like to set up the SSG so that any other outgoing traffic traverses the faster VDSL line first resorting to the leased line only when the VDSL is down.  I do not want to use ECMP routing as I want to dedicate the leased line to VPN use.

Through my brief testing it seems that with ECMP disabled the vrouter will use the first interface it finds for outgoing traffic - this is great as the VDSL is eth0/0.  I can then simulate a failure on eth0/0 and then the leased line on eth0/1 is used.  So far so good, the problem I saw is that when eth0/0 comes back up outgoing traffic continues to use eth0/1 whereas I'd like it to failback.

Is this at all possible?  Could PBR help?

I'd appreciate any assistance anyone can provide.

Many thanks in advance.

Hi,

Referring to your query, I found a page which has resolution. Please check

http://www.matthewjwhite.co.uk/blog/2011/11/07/configuring-juniper-ssg-firewalls-to-failover-between-internet-connections/

Hope this helps.

Regards,

Arvinder

Thanks for your reply Arvinder.  This does indeed look interesting.  As long as I can implement this without breaking the dual VPN setup then it could be ideal.

I'll come back with feedback after testing.

Cheers.

The method of using backup interface will break your backup IPSEC scenario if I understand you setup correctly.  I think you are saying you have two active IPSEC tunnels on the two services and use OSPF to select the preferred tunnel and failover to the backup tunnel when the primary is down.

The backup interface function holds the inactive interface physically down and has the active interface up.  When the primary interface fails or the track-ip on the primary interface fails that interface will be taken down and the backup interface will be brought up.

When track ip succeeds again on the primary interface this interface is brought back up and the backup interface is brought down.

If this is your scenario, you can still use track-ip to bring down the service interface on failure.  And have policy based routing or route preferences configured to use your preferred connections when both services are up and running.

Thanks for your post Steve.  In this scenario both public interfaces stay up when they are active so my two route-based VPNs are unaffected - there is no notion of primary/backup interfaces here.  I've successfully tested this setup this morning and it works brilliantly.

To recap what I was after.  My quick, cheap but unreliable ISP is on eth0/0 and my slow, expensive but reliable ISP is on eth0/1.  For day-to-day operation I'd like to use eth0/0 for local internet access and use eth0/1 for the primary VPN back to head office.  A failover VPN also exists on eth0/0 but should only be used if the primary on eth0/1 goes down.  Likewise if eth0/0 goes down then internet access should be possible on eth0/1 but once both interfaces are back up as normal then everything should settle back down to the preferred setup.

This is how I've done it.  I moved the Untrust zone into untrust-vr and assigned eth0/0 to it.  I then created a new vrouter called untrust2-vr, created a new zone called Untrust2 for it and assigned eth0/1 to this new zone.  Each vrouter had a static route created so that they can reach their respective next-hop gateways.

I then created route maps and export rules for untrust-vr and untrust2-vr to trust-vr.  The rule for untrust-vr is set to preserve the route preference value of 20 whereas for the untrust2-vr rule it is not.  This means the imported route from untrust2-vr ends up with a lower preference value of 140 (the default for imported routes) and so the route out through untrust-vr is always used if it is up.

Lastly, policies for 'Trust to Untrust' and 'Trust to Untrust2' were created to permit outgoing traffic.

The original link posted by Arvinder outlines everything needed for this setup but I'd like to highlight a few points;

1. I simplified the route maps to use the respective interface rather than employ the use of access lists.
2. Remember that interface-based NAT applies only to traffic sent to the Untrust zone.  My Untrust2 routing didn't work at first until I remembered this. I ended up setting my Trust interface mode to Route and enabling source translation in the two outgoing policies instead.
3. I enabled track IP monitoring on both eth0/0 and eth0/1 to their respective ISP's DNS servers.  This means that the interfaces can be bought down even if the physical links to the ISP supplied modems are up.
4. The only downside I can see with this setup is the need to maintain two separate outgoing traffic policies.  If you have particularly complex outgoing rules then it might be a pain for you to have to specify them twice.  It's a shame that you can't create 'Zone to Multiple-Zone' policies on SSG devices (can you on other brands?).

Once this setup is in place then you can quite happily create whatever VPN setup you like over the top.  In my case I utilise OSPF to manage two VPNs; both are always up but only one route is active at any one time.

If I get a moment I may try and document the whole setup including the OSPF managed dual route-based VPN stuff - let me know of this would be of interest to anyone.

Thanks again to Arvinder for posting that crucial link, I'd have been nowhere without it.

Regards,

Zinc666