I’ve been using Netscreen boxes for years now, but I feel like I’ve never had a good comfortable understanding of them until recently. The problem is, most people (me included) are introduced to “routers” by way of setting up some kind of NAT gateway at home. The gateway interfaces are set up in such a way as to make things like port forwarding, DMZ configuration, etc. all very “one button click” style. There is a very clear “WAN” side and a very clear “LAN” side, and the box does it’s job beautifully for you. The problem is, you don’t learn squat about networking and you sacrifice flexibility for ease of use.
What I’ve learned about Netscreen boxes is that they are true routers, not those NAT gateway “routers”. By that, I mean you need to really understand TCP routing tables, policies, firewall rules, packet processing order, etc. The down side is it can seem very complicated to someone coming from the world of Linksys DSL routers. But the benefits to learning how to really leverage true router/firewall devices is well worth it.
One thing that has started to creep into Netscreen’s interface and underlying ScreenOS are shortcuts similar to what you’d find in a DSL or Cable Internet router. The problem is, if you jump right on these shortcuts, you again limit yourself, you learn nothing, and in some cases those shortcuts break everything else. Case in point, I’ve been trying to get my SSG-20 unit set up with fault tolerant bridge groups, sub-interfaces with VLANs, 3 separate zones, 2 ISPs, and make it all fail-over and back again without a hitch. It’s been a much more daunting task than I would have thought at first glance.
Ok, that’s enough drivel… I have to get back to work, so I’m cutting to the chase.
– First off, let me explain that I moved away from using VIPs, and instead used policy based NAT. It’s more flexible and you can define a ton more policies than you can VIP ports.
– I use static routing for both ISPs. This type of setup may not work well if you are using ISPs that assign IP addresses via DHCP, because ScreenOS will automatically add routes for you upon receipt of a new IP via DHCP assignment.
– I’ve heard people on forums say that if you want to leverage two ISPs you have to separate them into different zones or put them on different virtual routers, and that putting two ISPs into the same Untrust zone will cause all kinds of problems. I’ve not found that to be true at all. It’s far simpler to keep them both in the Untrust zone and set up some simple route and IP tracking rules.
– I’ve also heard a lot of people using the “backup” function, found on the GUI under Network, Interfaces, Backup. Because I’m using some complex sub-interfaces, policies, and zoning, this totally broke everything when I turned it on, so don’t use it if you want to maintain great flexibility.
– Because the Netscreen box is a powerful tool with lots of flexibility, there are probably several ways to accomplish the same task. I find my way retains the most flexibility and works flawlessly with the more advanced types of configurations out there, without introducing any additional, but useless complexity.
– Rather than dedicating a port to the second ISP, I created a bridge group and VLAN tagged a sub-interface for my second ISP. That sub-interface is part of a multi-port bridge group with full Spanning Tree support turned on at my redundant switches. This provides fault tolerance at the port and switch level.
– Set up IP tracking for each ISP interface. This will keep track of each interface by pinging one or more external IPs through the interface, and bring it down should IP tracking fail. Many people suggest setting this up only on your “primary” ISP, but do it on both. Try to weight it so you will need to have at least 2 out of 3 (or more) remote IPs fail before it will consider the interface down.
– Add your static “default” routes (0.0.0.0/0) for each ISP interface. You can decide which ISP is “primary” by setting the preference to a lower number than other ISP routes. If you set all ISP routes to the same metric and preference, they will “flip-flop”, meaning one will be the primary until it goes down, then the next route in line will take over regardless of the state of the first route (even if it comes back up), and so on. Be sure to NOT check or set the route to “permanent”, or the status of IP tracking for that interface will have no effect on the route.
That’s pretty much it. The route preference determines which ISP is the “primary”, and IP tracking will dynamically adjust routes for you based on interface connectivity. After I had set this up, I tried using the built-in “backup/failover” system and it effed up all my routes and everything started wigging out. Turned that off and let the route tables and IP tracking do their thing and it works like a charm, and fail-over and fail-back is fast because I set IP tracking to some very tight time constraints for each interface.