Pros:? Low TCO, zero-config, easily extends LAN security to small branches
Cons:?Proprietary VPN, minimal reporting, troubleshooting could be tough
Enforcing consistent network security throughout a large enterprise can be challenging – especially for branches with few users and no IT. Many smaller offices start with consumer broadband routers – cheap and easy, but offering only basic security and little visibility. Others deploy entry-level business firewalls to inspect traffic and enforce policies at the branch edge, resulting in greater security, visibility, control – and TCO.
In both cases, initial cost is dwarfed by on-going expenses, from remote administration to security subscriptions. This largely stems from treating each branch as a stand-alone subnet that must be configured, secured, and monitored. But adding a few hosts to an existing LAN is far easier. So what if you could treat branch hosts just like those jacked into local LAN ports?
This is the premise behind Astaro RED – a low TCO appliance that delivers secure network access to remote LANs by tunneling Ethernet through a central Astaro Security Gateway (ASG). RED behaves like a REALLY long Cat5 cable linking a 4-port Ethernet switch to an ASG port.
Out at the branch
When all goes well, installing a RED is a non-event. A 2-page Getting Started Guide clearly shows what to plug where, explaining that a sequence of LEDs will flash until four are lit, indicating that a secure tunnel exists between the RED and the ASG that serves it.
Most routers and firewalls have setup wizards, but still need some input: subnet parameters, VPN gateway IDs, credentials. But RED requires no input whatsoever. Just power up the little steel box, tether its 10/100 WAN port to a broadband modem, and off it goes – “phoning home” to Astaro’s RED Provisioning Service. So long as RED can get an IP and reach the Internet, provisioning finishes in minutes without user input.
Thereafter, every remote host or hub jacked into the RED’s four 10/100 LAN ports is secured as if it were cabled directly to an ASG. All traffic tunneled from RED to ASG can be logged and inspected for spam, malware, and Web threats. But you don’t have to buy Unified Threat Management subscriptions for RED users or configure new policies for every branch. Instead, each RED behaves like a virtual Ethernet port that bridges up to 30 Mbps onto your LAN.
Back at headquarters
Of course, some configuration is required to add each RED to an ASG. However, basic bridge setup takes less than a minute per branch, performed centrally before RED deployment.
First, decide which ASG will be your “RED hub.” We used an ASG 120 ($595), outfitted with a network security subscription ($365/year), but any ASG will do. According to specs, an ASG 120 can support up to 10 REDs with a combined throughput of 50 Mbps. An ASG 625 can support up to 150 REDs/360 Mbps. Multiple RED hubs can be deployed for added capacity or redundancy.
Turning an ASG into a RED hub requires just four parameters – organization, city, country, email address – used by the RED Provisioning Service (RPS) to issue digital certificates. RPS is an Astaro-hosted service that relays RED requests to responsible RED Hubs. To enable this, each RED Hub is configured with a list of authorized RED IDs that can register themselves with RPS.
This flow means that REDs do not need static or public-routable IP addresses. This is also why REDs don’t require initial input and can be redeployed to a new site without reconfiguration — they just contact the RPS to (re)establish a tunnel with the appropriate RED Hub.
However, ASGs aren’t so lucky. To reach each RED Hub, the RPS must be given ASG hostnames that resolve to public routable IPs listening to TCP/4300. We port-forwarded 4300 from our edge router to our ASG, but we could have deployed our ASG in a DMZ instead.
Adding a new RED to a RED Hub (ASG) is simple, but the devil is in the detail. This process improved in the midst of our test drive, when we upgraded to ASG v8.
For both v7 and v8, new REDs are added with factory-assigned RED IDs and admin-chosen Branch Names. RED IDs are used by the RPS to authenticate embedded device certificates; Branch Names just are GUI/log handles.
Whenever a RED is added, it is registered with the RPS and an unlock code is issued to prevent theft and unauthorized reconnection to a different ASG. Each new RED is bound to a virtual Ethernet port called reds (Branch Name) – for example, reds1 (csbo). This virtual port is the foundation upon which all RED policy must be built.
In v8, this virtual port is the only object generated for new REDs. An entire branch LAN can be added to an existing LAN just by checking this virtual port under Bridge Configuration (below). All policies bound to the existing LAN and associated network, like DHCP pool and packet filters, now apply to the branch, as well. This approach couldn’t be any simpler, but does not segregate branch traffic for control or visibility purposes.
Alternatively, each RED virtual port can be bound to a manually-created network interface (subnet). In this approach, several more objects must be configured: a DHCP pool, a DNS allow rule, a masquerade (NAT) rule, and any packet filters to be applied to the subnet. While this setup is more complex to create and maintain, it enables more granular control and visibility.
In v7, some of these objects could be created when adding a RED by checking “Quick Remote Network Setup.” By v8, this confusing and incomplete option had disappeared. Companies that really want to create distinct subnets per RED can still do so, but we think most will prefer simple bridging to minimize TCO. Companies that go to the trouble of creating subnets may want to group multiple REDs to form multi-branch LANs, based on region or organization or function.
Balancing security, simplicity, and availability
Like many entry level firewalls, Astaro’s RED establishes a secure tunnel to the ASG. But RED doesn’t run its own spam filter or anti-virus engine – outbound traffic is relayed through the tunnel to the ASG, which applies security services that reflect centrally-configured policies.
Conceptually, this is a self-maintaining hub-and-spoke VPN. ASG admins do not need to issue RED certificates or configure tunnel parameters; that’s all taken care of by the RPS. Under the covers, this VPN uses proprietary protocols that are based on SSL/TLS.
Each RED-ASG TCP control tunnel provides mutual X.509 authentication and key management. Each RED-ASG UDP data tunnel encapsulates layer 2 frames, protected by AES-256-CBC and SHA-1-HMAC, re-keyed every 30 minutes. Because it operates at layer 2, this tunnel can easily relay LAN broadcast and IP multicast frames that challenge some other VPNs.
RED’s fully-automated transparent tunneling plays a big role in reducing TCO. Many companies will be comfortable with the level of security achieved, preferring ease of installation and operation to compliance with a standard like IPsec. But some organizations may consider any proprietary VPN a show stopper.
Those in the former camp will appreciate the following usability tweaks added in v8:
- An option to permit failover, which routes all traffic directly out the RED’s WAN port should the ASG ever become unreachable. Since failover leaves traffic without UTM protection, this option should only be enabled for branches that truly cannot tolerate downtime.
- An option for split tunnel mode, which routes only branch traffic addressed to a specified set of subnets over the RED-ASG tunnel. This option can be contentious: some organizations consider split tunnels “leaky,” but others find them essential to optimize traffic flows.
Keeping a watchful eye
In fact, one rationale for routing all RED traffic through a central ASG is visibility. ASG policies can be configured to log LAN traffic – for example, documenting all allowed sessions or all dropped packets. ASGs also provide a healthy set of canned reports, including network usage graphs, intrusion prevention activities, blocked mail statistics, and blocked Web requests based on surf protection and anti-virus rule enforcement.
These ASG logs and reports automatically include all branch traffic relayed over RED tunnels. For example, you can easily eyeball the ASG’s firewall log to see how packets from a given IP are being treated, whether that host is local or out at a branch. However, bridging RED traffic directly onto a LAN makes it hard to report on activities at a single branch. To accomplish that reporting granularity, configure per-RED subnets instead.
In addition, each RED Hub (ASG) maintains one “RED live log” – a self-refreshing window that contains RPS provisioning events, RED tunnel events, and RED heartbeat responses. Although raw records can be searched by RED ID, this live log window would be far too busy to watch in a large deployment with dozens or hundreds of REDs.
Nor are RED live log records very detailed – we had to diagnose RED setup and communication problems by looking at packet drops and IPS events. We appreciate Astaro’s attempt to treat RED just like any other Ethernet port. But we would still like to see a new RED activity summary report, and perhaps a trouble-shooting wizard to debug RED provisioning or tunneling issues. Transparency is a huge time-saver – except for those few cases when something goes wrong.
The bottom line
With RED, Astaro has taken a unique approach to enforcing branch network security. Overall, we found RED very easy to understand and administer – especially when bridging branch traffic onto an existing LAN. Once we wrapped our head around this approach, we had no trouble applying common LAN policies to our branch – for example, enabling remote printing, blocking P2P apps, and prioritizing Ethernet traffic.
Although we only tested two REDs, we could easily see that REDs would be activated very quickly, automatically applying LAN policies uniformly across all branches, without per-site maintenance or UTM subscriptions. According to Astaro, RED can cut TCO up to 80 percent versus a typical branch office UTM deployment. One extension we think would be useful for very large RED rollouts: batch import of authorized RED IDs.
However, RED is not appropriate for branches requiring low latency or extensive intra-branch policy enforcement. With all branch traffic tunneled back to a RED Hub, there is clear potential to create bottlenecks. Although you may allow some branch traffic to bypass the Hub (using split tunneling or failover), doing so poses some risk. Our advice: look carefully at each branch and its traffic needs to determine best fit. Some branches may deserve (or grow into) their own ASG. In short, RED complements the ASG product line by providing customers with large distributed networks a more cost-effective entry-level solution for securing small branch networks.
Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies. She has long been involved in specifying, deploying, and testing a variety of network security appliances, including UTM firewalls and VPN gateways for SMBs and enterprises.
Keep up-to-date with our in-depth reviews; follow eSecurityPlanet on Twitter @eSecurityP.