Foundry SecureIron: Security Switch and Firewall Load Balancer

01 /What SecureIron was

SecureIron was listed alongside ServerIron under the web switches heading on the old Foundry site, which tells you its heritage. It took the ServerIron forwarding engine and flow table and applied them to security rather than load distribution: every flow through the switch was tracked, access control was applied at line rate, and abnormal traffic patterns were dropped in hardware before they reached firewalls or servers.

Foundry positioned it for the network perimeter and the data-center edge, where an organisation already had firewalls but wanted a hardware layer in front of them to absorb floods, enforce coarse policy and spread load across a firewall cluster. The product is obscure; datasheets are scarce and model details vary between sources, so this page describes the concepts rather than exact specifications.

02 /Capabilities

03 /Firewall load balancing explained

Firewalls are stateful, so a flow that enters through firewall A and returns through firewall B is dropped by B, which has no record of it. Firewall load balancing solves this with a sandwich: a switch on the outside picks a firewall for each new flow, and a switch on the inside uses the same hash or a shared table to send the return traffic back through the same firewall. Health checks remove a failed firewall from the rotation. The same technique appeared on ServerIron; SecureIron packaged it with the other perimeter functions. The server load balancing page covers the flow table mechanics.

04 /SYN flood protection and rate limiting

A SYN flood exhausts the connection tables of servers or firewalls with half-open connections. A hardware device in front can absorb this by answering the handshake on behalf of the server and only opening a real connection once the client completes it (a SYN proxy), or by capping the rate of new connections per source and dropping the excess. Rate limiting extends the idea to bandwidth: a per-port or per-flow cap prevents one host or service from saturating an uplink. On SecureIron these functions ran in the forwarding hardware, which was the selling point compared with software firewalls of the period.

05 /Why it was short-lived

The market for a switch-based security appliance was thin. Firewall vendors added their own clustering, so firewall load balancing became a feature rather than a product. Dedicated DoS mitigation moved to purpose-built appliances and, later, to upstream services. Foundry sold few units and did not invest in a second generation, and Brocade dropped the line after the December 2008 acquisition. The load balancing hub covers where the concepts went afterwards.

06 /What the filings and archived pages say about SecureIron

The company's own record is thinner than a datasheet but firmer than memory. Foundry's annual report on Form 10-K for 2005 states that the SecureIron family was introduced in 2005, describes the units as security traffic managers with Layer 2 through 7 switching and security, and places them at the perimeter, inside the data centre and within the LAN as inline devices. The results release for the fourth quarter of 2006, filed as an 8-K exhibit in January 2007, lists two 2006 introductions: the SecureIron Perimeter Traffic Manager (PTM) and a unit written as SecureIronLS.

An October 2006 capture of the SecureIron family page on the old site splits the line the same way. The perimeter traffic managers were sold as a front end to existing firewalls: hardware access lists, denial of service protection, stateful NAT and application rate controls offloaded from the firewall, plus distribution of outbound traffic across several ISP links with failover that did not need BGP, and spam mitigation and web filtering. The perimeter page named two performance models, SecureIron 100 and SecureIron 300. The LAN switch page described per-flow stateful policy, user authentication over HTTPS against RADIUS, deep packet inspection, an optional hardware SSL acceleration module and 10 GbE connectivity options. Port counts, throughput and session limits appear only in a single archived datasheet PDF that this site has not verified line by line, so they stay out of this profile.

07 /SecureIron today

Units rarely appear second-hand. Anyone holding one should treat it as a ServerIron variant: the same CLI heritage, the same power and noise profile for the chassis form factor, and no software support since the late 2000s. It must not be used as a security device on a live network because its inspection code has received no updates for well over a decade; see the security advisories page. It is a curiosity for collectors and a teaching aid for the firewall sandwich pattern. The ServerIron it was a variant of, and the rest of the product range from the same years, are listed in the Foundry archive home.

08 /Running a SecureIron today: what to check before it stays powered

Assume the unit is unsupported and unpatched. Brocade did not carry the line forward after December 2008, no successor publishes firmware for it, and the inspection code has not been updated since the last IronWare release it shipped with. Before an inherited unit stays in a rack, check four things: whether any production traffic still passes through it inline (it should not), whether the console port is reachable so that it can be recovered without the network (see the console recovery procedure for IronWare units), whether the configuration has been copied off, and what replaces each function it performed. The table above is the replacement checklist.

The inventory session below uses only commands that appear on this site's command reference. The show server commands are shown because SecureIron shared the ServerIron software heritage; whether a given image accepts them depends on the release, and the transcript is illustrative rather than a reproduction of any manual.

si1# show version
  (record platform, image name, release and serial number)
si1# show running-config
  (copy the whole output off the box before anything else)
si1# show interfaces brief
  (any port with link up inline is still carrying traffic)
si1# show server real
si1# show server virtual
  (firewall pool members and virtual addresses, if the image has the server tree)
si1# show log
  (link flaps and authentication failures give the recent history)

Pitfalls seen with these units:

• Trusting a resale listing's throughput or session figures; the listings copy each other and none cite the datasheet.
• Treating the perimeter traffic manager and the LAN switch as one product with two names; the archived pages describe two families with different jobs.
• Leaving a unit inline on a live segment to "see what it does"; a stateful device with stale software in the path is a single point of failure with no fix available.
• Assuming its ACLs are equivalent to a current firewall policy; what a device of that era could see at Layer 4 and Layer 7 is set out in inspection depth at Layer 4 and Layer 7, and the rate control it offered is now done at the balancer, as in rate limiting today's automated clients.