7

I have been working with the Netscreen, and then Juniper firewall products for the past five years and am still learning new and interesting features they offer. One thing that I have been configuring more and more recently are secondary Internet connections and fail-over between them for clients. This post runs through the steps required to configure an SSG firewall to use track-IP to monitor IP addresses on the Internet and then automatically fail-over and fail-back an Internet connection.

The first thing we need to do is move the interfaces that will contain the Internet connections so each is in their own virtual router. This will allow us to have an active default route for each connection and they can behave independently of each other.

1

2

3

4

5

6

7

8

set interfaceethernet0/0zone null

set interfaceethernet0/1zone null

set zone untrust vrouter untrust-vr

set vrouter name adsl-vr

set zone name BackupUntrust

set zone BackupUntrust vrouter adsl-vr

set interfaceethernet0/0zone Untrust

set interfaceethernet0/1zone BackupUntrust

For this example I am using the 192.0.2.0/24 address range for my WAN connections – this was defined by the IETF as a subnet to be used for testing and documentation in RFC 5735. As these interfaces are both public facing I am also going to restrict the management to secure protocols only

1

2

3

4

5

6

7

8

9

10

11

12

set interfaceethernet0/0ip192.0.2.2/29

set interfaceethernet0/0route

set interfaceethernet0/0manage-ip192.0.2.3

set interfaceethernet0/0manage ping

set interfaceethernet0/0manage ssh

set interfaceethernet0/0manage ssl

set interfaceethernet0/1ip192.0.2.10/29

set interfaceethernet0/1route

set interfaceethernet0/1manage-ip192.0.2.11

set interfaceethernet0/1manage ping

set interfaceethernet0/1manage ssh

set interfaceethernet0/1manage ssl

Now we need to setup the default routes out of each virtual router so that each connection can communicate with the rest of the Internet

1

2

3

4

5

6

set vrouter untrust-vr

set route0.0.0.0/0interfaceethernet0/0gateway192.0.2.1

exit

set vrouter adsl-vr

set route0.0.0.0/0interfaceethernet0/1gateway192.0.2.9

exit

We need to ensure that our internal users are able to route to both the untrust-vr and adsl-vr. This can be done by exporting the default static route from the untrust-vr and adsl-vr

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

set vrouter"untrust-vr"

set access-list1

set access-list1permit ip0.0.0.0/01

set route-map name"untrust-vr_export"permit1

set match ip1

set preserve preference

exit

set export-tovrouter"trust-vr"route-map"untrust-vr_export"protocol static

set vrouter"adsl-vr"

set access-list1

set access-list1permit ip0.0.0.0/01

set route-map name"adsl-vr_export"permit1

set match ip1

exit

set export-tovrouter"trust-vr"route-map"adsl-vr_export"protocol static

This will import both default routes to the trust-vr and set maintain the preference of the export from the untrust-vr at 20 whilst setting the metric of the adsl-vr export to 140.

Now that our users can connect to the Internet we need to make sure that should there be an issue with the primary internet circuit the backup circuit can be used for Internet access. This is achieved by using track-ip to monitor a number of hosts on the Internet and should they become unreachable shut the interface down.

In this example we are using the IP address of some of the root DNS servers as the addresses the firewall will use to check for a valid Internet connection but they could be any IP addresses that you expect to remain online and will respond to PING requests

1

2

3

4

5

6

7

8

9

10

set interfaceethernet0/0threshold75

set interfaceethernet0/0monitor track-ip ip

set interfaceethernet0/0monitor track-ip threshold75

set interfaceethernet0/0monitor track-ip weight75

set interfaceethernet0/0monitor track-ip ip192.58.128.30threshold25

set interfaceethernet0/0monitor track-ip ip192.58.128.30weight25

set interfaceethernet0/0monitor track-ip ip192.36.148.17threshold25

set interfaceethernet0/0monitor track-ip ip192.36.148.17weight25

set interfaceethernet0/0monitor track-ip ip193.0.14.129threshold25

set interfaceethernet0/0monitor track-ip ip193.0.14.129weight25

This will PING the three addresses every second and will consider the address to have failed when the test has failed 25 times consecutively. Summing these three failures together will hit the weight and threshold limits of 75 needed to shut down the interface.

UPDATE: Since this was written Juniper released newer firmware that allowed you to specify the interface threshold for failure in addition to the Track-IP threshold. This would mean that track-ip would fail at 75 but the interface default was set to 255 for failover, the config above has been amended accordingly to reflect this change in behaviour.

If you want to test the status of the track-ip monitoring you can issue the following commands

1

2

get interfaceethernet0/0monitor

get interfaceethernet0/0monitor track-ip

and you will be able to see the failure statistics as well as whether the interface is failed or not.

When the interface is shut down the default route no longer becomes valid in the untrust-vr and will be deleted in the trust-vr leaving the export from the adsl-vr active and Internet traffic will continue to function as normal. In the background, the management address on the primary connection will continue to poll the IP addresses configured and when they become available the weight and threshold will be below the failure values, the interface comes back up and the untrust-vr route export re-appaers in the trust-vr.

The only other thing to consider here is inbound services on the backup line such as MX records to permit mail delivery to a MIP or VIP on the secondary circuit

If this is all configured correctly the only things the user should notice is that any websites/services that login and use session data (eg online banking) will need to login after fail-over or fail-back as their existing session will no longer be valid.

The only remaining task is to commit the changes you have made to flash

I show a “monitor track-ip” command being used on the secondary interface. Any configuration I’ve seen only shows this command being used on the primary interface. Is it incorrect procedure for this command to be used on the secondary, or will it basically have no effect? Current behavior shows that the secondary path is NOT coming up after the primary fails. Please clear this up for me.

Good question Joe. It looks like he is only monitoring the primary WAN. When it goes down, WAN2 becomes active (working or not). When WAN1 comes back up, WAN1 becomes active. This passive behavior may be by design. I wish the author would reply. Maybe he forgot a patch of code.

Hi Joe, Apologies for not replying to this sooner but my blog has been somewhat neglected. The reason to monitor both connections would be in the event that you want to route different traffic across the connections and failover to the second in the event that either has an outage (eg your internal network is split into corporate and guest networks and under normal load they should use different connections but if one were to fail then the two internal networks will share one Internet connection.

If the secondary path is not coming up then you should check that the interface has actually failed. Later releases of ScreenOS added a weight into the interface as a whole so whilst track-ip failed at 75 this wasn’t sufficient for the whole interface to fail. I have updated the post accordingly

How are you applying the config to the SSG, I am assuming that these changes are being applied via SSH or via console access to the firewall itself. I have never been that much of a fan of trying to load the changes in and trusting the web interface to merge the two files together.

I think I have missed out another line where eth0/1 is placed into the BackupUntrust zone.

I have updated the blog to include this but once you create the BackupUntrust zone try adding the following lines:

set int eth0/0 zone Untrust
set int eth0/1 zone BackupUntrust

one final thing with the configuraiton would be to issue a save command to the configuration when working via the CLI, its something that happens in the webUI automatically but needs to be specified manually in the CLI

As for hire, I work for a UK based managed services provider so not that easy to get bits of work done outside of that however I do know some people who would possibly be able to do some remote work if you can let me know what you are looking to do I can see if they are interested.

Is there any sort of notification mechanism to give me a head’s up that the primary WAN connection has failed? We get billed by the GB for the backup connection and would really like to know if we’re using it rather than our primary WAN connection.

I guess you can get the appliance to send SNMP traps to a management station when the state of the interface changes possibly but I haven’t checked this out too much.

The alternative would be to have something inside the network monitor a site like whatismyip.com and if it doesnt return your primary IP address to alert at that stage. I would have thought that most network monitoring tools should be able to do this out of the box with little customisation.

you would probably be able to do this with a combination of CLI commands however the main thing is that you need to strip back all references to your interface before reassociating the IP address.

I would probably use additional interfaces to build this redundant-IF up and then go through changing out the config in an maintenance window. If you can get the unset commands in the right order you can paste it in but just need to make sure they all succeed.