Introduction
| ASUS Internet Security Router | |
|---|---|
| Summary | – 50 tunnel IPsec endpoint router with amazing IPsec tunnel throughput. Also available as 5 tunnel SL500 |
| Update | 7/15/2004 – Product is now available from U.S. web retailers |
| Pros | • 30Mbps IPsec tunnel throughput • Flexible multi-NAT support |
| Cons | • Firewall is very difficult to configure • Must use IE for web interface |
ASUS is trying hard to establish itself in as a force in the U.S. networking product market. I’ve previously looked at its WL-300g and WL330 wireless access points and found effective hardware design with a number of thoughtful features, but definite room for improvement on the software side of things.
The SL1000 seems to echo the theme – impressive hardware, not as impressive software – I saw in the wireless products. This time, though, the User Interface seems to be more of a barrier to getting the most from the product.
The SL1000 is also available as the less-expensive SL500. The only difference is that the SL500 supports only five IPsec tunnels, while the SL1000 handles twenty five.
Basic Info
The SL1000 comes in a silver plastic enclosure that has the footprint of a software programming softcover book, but isn’t quite as thick. The enclosure has wall-mounting screw slots on the bottom, and a built-in desktop stand that’s formed from two pieces of the case that snap out. I give ASUS points for innovative design on the stand, but advise care in its use. Since the stand isn’t very wide, cable weight could easily cause the case to topple over, possibly sending your SL1000 crashing to the floor if it were sitting on a high shelf.
All indicators are on the front of the box and are bright and easily viewable from a wide angle. You get Link / Activity lights for each of the single WAN and four LAN ports, plus Power and Alarm.
Four 10/100 LAN ports, one 10/100 WAN port, power jack and power switch are on the back panel along with the Reset-to-factory-defaults switch. Note that all LAN ports are auto MDI / MDI-X, though ASUS doesn’t spec or mention this. There’s also an RJ45 jack labeled Console on the rear panel. ASUS told me that it’s there for internal debugging purposes and not functional for customer use.
Internal Details
The increasingly powerful network processor chips coming onto the market make for generally simple board layouts. Figure 1 shows that the SL1000 is powered by a Philips PTD2210 Gateway-on-a-chip , which is clocked at 133MHz.
The Philips chip is a MIPS-based microcontroller with some pretty fancy on-board processing, including IPsec hardware acceleration for DES, 3DES, MD5 and SHA-1. As you’ll see later in the Performance sections, this processor packs quite a punch!
Figure 1: SL1000 (and 500) board
(click on the image for a full-sized view)
The WAN port is handled by a Realtek RTL8201BL 10/100 Ethernet “PHYceiver” and the four switch ports connect to a Realtek RTL8305SB 5-Port 10/100M Fast Ethernet Switch Controller. 4MB X 32 of RAM and flash memory round out the rest of the board.
The SL1000 is Linux based, most likely using Philips’ Linux Software Release 3.0.. Philips’ release includes the iGateway firewall from Intoto, and IPsec VPN from SSH (since sold to SafeNet).
ASUS sent me both an SL500 and SL1000 so that I could test router-to-router IPsec tunnel performance. I opened up both routers and the boards looked identical to me. The only physical differences were the labels on the flash memory and an “SL500” label on its board.
Setup and Administration
Let me preface the router feature walk-through with the following caveat: I struggled constantly while exploring its feature set for this review. Although I’m not the smartest guy in the world, I have tested more than a few SOHO routers. I definitely put the SL1000 in the “advanced” class in terms of features, but not in terms of ease of use.
I think the main reason for my struggle was that things that are normally done automatically by other routers must be done manually in the SL1000. I’ll give examples of this as I go along so that you can judge for yourself.
The SL1000 comes set to 192.168.1.1 as its factory default, its built-in DHCP server enabled and WAN connection type set to PPPoE. Once you enter the default username and password, you’ll be sent to the Setup Wizard page. The Wizard isn’t that intelligent and just steps you through the Password, System Information, Date/Time, LAN IP, DHCP Server, and WAN configuration pages. The results of the setup are summarized in the System Information screen (Figure 2).
Figure 2: System Information screen
The Windows Explorer style interface is a familiar format and is a good way to let you see where you are and where you can go. But I found the time it took to refresh and travel between screens curiously long – considering the processing horsepower available.
I also found you really need to use Internet Explorer as your browser when accessing the admin screens. Using Mozilla (1.6b and 1.7b) to access the interface resulted in missing selector boxes in some screens. Also of note is that the interface uses a fixed font size – no problem for Mozilla’s text scaling capability, but a disadvantage for the required IE.
Figure 3: Shell access via Telnet
There’s also a command line interface available via Telnet (Figure 3), which includes the ability to drill down to Linux shell access. The interface commands aren’t listed in the User Guide, but typing a ? at the prompt provides you with the available commands and experienced users will figure their way around the interface quickly.
As I mentioned above, the browser interface has a sluggish feel, although the reboots needed to save the changes made on each page are relatively quick. Multiple admin logins are allowed, with no warning given when more than one admin logs on. Once you’re logged in, there’s no idle timeout and you can use the logout button when you’re done.
Internet access (Figure 4) options are limited to dynamic IP, fixed IP and PPPoE (the default).
Figure 4: PPPoE WAN setup
PPTP connection is not supported, nor can you set a static IP in the PPPoE screen. You can’t set the MTU value either, which could present problems with some ISPs’ systems and / or certain applications. MAC address cloning is available, but only for dynamic IP connection types.
Advanced Features
The SL1000 has a pretty advanced feature set – too advanced, perhaps, for the average SOHO user. A lot of the setup complexity stems from its multi-NAT features, since the SL1000 supports five NAT (Network Address Translation) modes:
- static (One to One) NAT
- reverse static NAT
- dynamic NAT (m to n)
- NAPT (Network Address and Port Translation) / PAT (Port Address Translation)
- Reverse NAPT / Virtual Server
The NAPT / PAT mode is what you normally encounter in consumer routers and lets multiple LAN clients share one IP address assigned by your ISP. Reverse NAPT is just the technically correct term for the port mapping or virtual server feature found on SOHO routers, which lets you make LAN-based servers accessible to the Internet.
The SL1000 isn’t the first product to sport multi-NAT capabilities, but it has the most confusing interface that I’ve seen to allow access to those features. Where most other products give you a special screen to assign groups of LAN addresses to multiple WAN IP addresses, ASUS has chosen instead to incorporate the static and dynamic NAT modes into the ACL (Access Control List) Rules that are used to control traffic passing through the firewall.
ASUS’ method allows more flexible use and finer control of the multiple IP addresses that you may have, but it unnecessarily complicates life for the larger population of users who have only one IP address to deal with. You’ll see what I mean once I get into the Firewall features.
Another advanced feature – and a first for me – is the Self Access rules. Basically, ASUS takes a very secure approach to things – including access to the routing engine in the SL1000 itself! The pre-configured Self Access rules shown in Figure 5 allow LAN clients to access the admin screens (TCP 80 – Web and TCP 23 – Telnet) and even basic services such as DNS (UDP 53)!
Figure 5: Self Access rules
Note that since UDP ports 500 (ISAKMP) and 520 (RIP) are the only ones open to the SL1000 from the WAN, you’ll need to set a rule to open it to the WAN – in addition to setting an appropriate ACL rule – to administrate the SL1000 from the WAN side. Although this additional step adds an extra measure of security, it’s just one example of making things that should be easy, difficult.
Firewall Features
The SL1000’s firewall is perhaps its most powerful – and difficult to configure – part. All traffic flow through the router, both inbound and outbound, is controlled by Access Control List (ACL) rules. ACLs are used both for port / service filtering and port mapping / virtual servers. They are also used to configure the SL1000’s multi-NAT features.
This system will probably be comfortable for those accustomed to dealing with “enterprise” level firewall and NAT routers. But SOHO types may get frustrated trying to navigate the ACL setup screens, which contain option settings that aren’t needed (or useable) for their relatively simple needs. The good news is that the ACL’s give you tight control over what packets can go where. The bad news is that you must remember to configure ACLs in cases where you normally wouldn’t have to futz with the firewall settings on other products.
Studying the Inbound ACL screen (Figure 6), which is used to open ports in the firewall for virtual servers, will cover most of the firewall controls.
Figure 6: Inbound ACL rules
(click on the image for a full-sized view)
Port filtering (access control) uses the Outbound ACL screen (Figure 7), which is virtually the same as the Inbound. I had to set the rule shown to allow VPN traffic through the SL1000’s firewall (more on that later).
Figure 7: Outbound ACL rules
Compared with what you normally see for port mapping controls, the SL1000’s ACL screens present many more choices. Figure 6 shows an ACL that allows access from the Internet to an FTP server with an IP address of 192.168.2.11 sitting on the LAN side of the router.
The ACL rule controls let you specify just about everything that happens to a packet as it travels from one side of the firewall to the other. Here are the available options for each selector:
Source IP: Any, IP address, Subnet, Range, IP Pool
Destination IP: Any, IP address, Subnet, Range, IP Pool
Source Port: Any, Single, Range
Destination Port: Any, Single, Range, Service
NAT: None, IP address, NAT Pool
If I hadn’t selected Service for the Destination Port in the FTP example, you would have also seen the Protocol selector with its options of All, TCP, UDP, ICMP, AH and ESP. The Outbound ACL screen looks pretty much the same as the Inbound except that the NAT selector offers an additional Interface selection which is the one you’ll use unless you’re doing reverse static or dynamic NAT.
Firewall Features, Continued
A few of the terms need further explanation. The IP Pool is just a pointer to a group of IP addresses that you can set by Subnet, Range or even single IP address – the latter being a little silly. I’d rather have seen an option to specify a list of IP addresses, since the other options only let you specify contiguous ranges of addresses. The NAT Pool is another pointer / shorthand, this time letting you define contiguous groups of LAN and WAN IP addresses for use in multi-NAT configurations.
The Application Filters can be associated with ACL rules to filter FTP and SMTP commands, HTTP file extensions and RPC services. This means that for the FTP, SMTP and RPC filters, the SL1000 will allow or deny specific commands entered in the each filter, while the HTTP filter can be set only to block files with certain extensions.
Figure 8: HTTP Filter example
Figure 8 shows an HTTP filter that will block files with .java, .jar and .swf (Flash) extensions.
Note also that you can choose to have the triggering of an ACL logged or have an ACL apply to traffic coming or going via an IPsec tunnel.
With all those selectors to absorb, you may have missed the Time Ranges feature that lets you apply one of three programmable time periods to any ACL rule. The Time Range is just that – you get one “From” day and time to one “To” day and time per range – and some users may find this too limiting for their needs.
You’re also sure to have missed the Application Layer Gateway (ALG) feature because it has no settings in the admin interface. ALGs are built-in dynamic port mappings that trigger on specific outbound packets. These are used for applications such as games and tele / video conferencing that need to dynamically open ports in the router’s firewall. I’ll have to take ASUS’ word on this, since I didn’t try to test out any of the list of supported applications.
Firewall Features, Continued
One thing the ACL rules don’t do is content filtering, which is instead handled by the relatively crude URL Filter feature (Figure 9).
Figure 9: URL Filter
You get only ten 15 character keywords to use as filters and, once programmed, filters can be edited and deleted but not disabled. When the filter is tripped, you get an “Access Denied by ASUSTeK Internet Security Router” screen. The keywords are broad in that the filter will kick in if the keyword string is found anywhere in the URL. But I found that the filters can be easily bypassed by anyone savvy enough to look up and enter the IP address of the desired site instead of its URL.
The SL1000’s DoS Attack Filter settings expose the controls for its SPI features. The Help button brings up short, but informative descriptions of each of the controls, with most of them disabled by default as shown in Figure10.
Figure 10: DoS Attack Filter setup
The only “exploit” that I tried was a port scan of the SL1000’s WAN, which was logged in short order.
Even with this overflowing basket of features, there are still some tricks the SL1000’s firewall won’t perform. UPnP isn’t supported (no loss in my book) nor is server loopback, i.e. the ability to access port-mapped servers by their WAN IP (or assigned domain name) from LAN-side clients, supported either.
On the usability side of things, It would be nice to be able to disable the ACL rules and leave them programmed instead of having to delete them. A confirmation step before rules are deleted would be helpful, too.
Navigating your way through this maze of selections takes some getting used to. One of the things I didn’t like is that you have to specify the WAN IP of the router as the Destination IP for Inbound ACL’s. Since most ISPs assign dynamic IP addresses, inbound rules could stop working when the SL1000 renews its DHCP lease or logs into a PPPoE connection. It would be much better if you could just specify the WAN port instead of a specific IP address.
To their credit, ASUS tries to help with descriptions and examples of each feature in its printed User Guide. There’s also online help available which, in some cases, I found more helpful than some of the printed material. ASUS tells me that they’re also busy compiling application notes and a FAQ guide, which they plan to have available when the SL1000 starts shipping.
Remote Access
Before I move on to the SL1000’s VPN features, I’ll take a moment to cover one of the SL1000’s more unique features. Remote Access is a simple non-secure user / password challenge authentication system that can be used to control the LAN-side clients and services that WAN-side (Internet) users can access.
It provides an option between no security and a VPN tunnel, and, once you get the hang of configuring it, can be a useful addition to your remote access toolkit. But note that the user / password challenge and your response are not encrypted, so this method should not be used in applications where security is a top concern.
Figure 11: Users and Groups setup
Figure 11 shows how you define Groups, enter Users and set their passwords. Once set, Users or Groups can be deleted or temporarily disabled to prevent access. Once you have your Groups defined, you create Group ACLs to control access to the desired services for specific groups of users. (Group ACLs look essentially the same as Inbound and Outbound ACLs except they also have a Group parameter.)
Once you get all this set up, a Remote user must go to a special URL and log into the router. Once the user has successfully logged in they may access the services and LAN clients specified in their Group ACL rule.
Though an interesting concept, I found that the implementation had problems. An access rule that I entered to allow access to Windows file sharing didn’t require a login in order to enable it, but a Group ACL that I set to access an FTP server worked ok. I also found that once I entered the username and password in Internet Explorer to log in, I didn’t have to enter it again after I logged out as long as I didn’t quit the browser. All I had to do was hit the login URL again and the rule was enabled.
You can also use the Remote Access feature via an IPsec tunnel, but frankly after futzing with it for awhile, I didn’t have the patience to figure out how to do it.
VPN Features
One of the SL1000’s saving graces – and probably the feature that will be the most attractive to prospective buyers – is its phenomenal VPN performance. I’ll get to how phenomenal shortly, but first let’s look at the tunnel setup options.
The SL1000 can handle twenty five site-to-site or Remote user access IPsec tunnels. Figure 12 shows the setup options when using a Preshared Key, while Figure 13 shows how the screen changes if you want to use manual keying.
Figure 12: Example VPN Site-to-Site setup
(click on the image for a full-sized view)
Figure 13: Tunnel setup with Manual keying
(click on the image for a full-sized view)
Instead of giving you separate “radio buttons” to set IKE and IPsec parameters, you get drop downs of pre-made combinations. As far as I can tell, all the combinations you’d want are present, but given the abbreviations and terminology used, you might have a hard time finding the ones you need.
For pre-shared key IKE proposals, you get combinations of DES and 3DES encryption, SHA-1 and MD5 authentication and Diffie-Hellman Groups 1, 2 and 5. IPsec proposal groupings include combinations of none, DES and 3DES encryption, none, SHA-1 and MD5 authentication and AH and ESP encapsulation.
There are a few other settings such as the Chained Authentication Header and Xauth (Hidden away in the Aggressive IKE Proposal settings) options that I don’t see very often and the Perfect Forward Secrecy (PFS) that I do. One switch I don’t see is the ability to enable the chatty NetBIOS broadcasts to enable Windows network browsing (Network Neighborhood / My Network Places). So you’ll have to know the IP address of your desired shares or configure Inbound and Outbound ACLs to pass the NetBIOS ports (TCP and UDP Ports 135, 137-139, and 445). Note also that certificate-based authentication is also not supported.
While I’m on the subject of ACLs and IPsec tunnels, I’ll make you aware of an SL1000 usability issue that I’ve previously not encountered in any other SOHO VPN endpoint routers. Since it cost me so much time in getting a tunnel up and running, I thought I’d pass it along:
Once you get an IPsec tunnel successfully established, you also need to configure inbound and outbound ACLs in order to allow traffic to flow through the tunnel.
Once again, something that should be easy is made difficult.
As I mentioned above, the SL1000 can handle site-to-site (router to router) and Remote Access (single client) tunnels. But choosing the Remote Access method brings up a User Group selector and also requires configuring the VPN Virtual IP under the Remote Access menu. Quite frankly, folks, this all made my head hurt and I never was able to get a tunnel working via the Remote Access option.
This doesn’t mean that you can’t have road warriors securely connecting into your LAN via the SL1000. You’ll just have to use site-to-site mode and a VPN client application. I had an old version of SSH’s now-departed Sentinel client, which I used to get a tunnel up and running from my WinXP notebook pretty quickly.
TIP: In the past, VPN clients have had rip-off level pricing. But NETGEAR’s VPN01L (single license) or VPN05L (5 licenses) – essentially a retail version of the SafeNet IPsec client – provide a resonably-priced (about $40) option.
You can try to use WinXP / 2000’s built-in IPsec client if you’re patient – I was able to get it to work, but I’ve had a lot of practice – but only if you can deal with static IP addresses at both ends of the connection – rare with connections from folks on the go.
Finding out what’s going wrong with the mating dance between IPsec client and gateway requires good logging of the whole VPN setup process. Unfortunately, the SL1000 isn’t very helpful in this regard. You can try using its built-in log page, but I recommend a syslog daemon instead. With either of these methods, however, the log data is in pretty raw format, which makes it hard to tell what’s happening.
Finally, if you can’t, or don’t want to, use the SL1000’s IPsec endpoints, you can instead use VPN pass through with IPsec, PPTP or L2TP client applications. And if you want to substitute a different IPsec server for the SL1000’s, you can configure an Inbound ACL for it, but not for PPTP or L2TP gateways.
VPN Tests
I’ve hinted at the SL1000’s VPN tunnel performance and now it’s time to deliver the results. Figure 14 and 15 pretty much speak for themselves!
Figure 14: SL1000 / SL500 Site-to-Site tunnel performance
(click on the image for a full-sized view)
Figure 14 shows Remote-to-Local and Local-to-Remote throughput for a site-to-site tunnel between an SL1000 and SL500. Both tests were run with no other activity in either router. Integrating by eye shows an average throughput around 30Mbps, but there are regular temporary pauses in transmission in both direction that brings the calculated averages down to 22-25Mbps.
You’ll also note a curious upward drift in speed over the 30 second test period for the remote-to-local test (blue trace) that I have no explanation for.
Figure 15: SL1000 / SSH Sentinel client tunnel performance
(click on the image for a full-sized view)
Figure 15 shows Remote-to-Local and Local-to-Remote throughput but this time using my Dell Inspiron 4100 notebook running WinXP and SSH’s Sentinel (Version 1.3.2 build2). Throughput in both directions is much more consistent, though there are still occasional pauses causing dropouts on the plots.
ASUS’ literature says the SL1000’s throughput is “80Mbps for VPN, 100Mbps for Firewall, and 90Mbps for NAT”. Like any other manufacturer’s throughput specs, I suspect that these are raw data rates and maybe even internal packet processing rates. No matter. The 30Mbps rates shown in the Chariot plots above are simply the highest I’ve seen in any VPN endpoint to date and amazing when you consider they are coming from a box that you can buy for around $150 (the SL500)!
By the way, running a quick Qcheck Response time check revealed virtually no latency through the tunnel. I also tried some web browsing and email checks while running other Chariot tunnel tests and found no noticeable effects in the Chariot results or pauses in browsing.
Routing Performance
If you liked the SL1000’s VPN tunnel throughput, you’re gonna love its routing performance. Figure 17 shows a first in my years of hammering on consumer grade routers – damn near wire-speed routing! I say this because the 81-84Mbps routing throughput is pretty much the maximum that I can squeeze out of the two >1GHz WinXP test machines when they are directly connected via 100Mbps Ethernet.
The Routing Performance Test table shows that there is also no measurable latency and excellent UDP streaming performance. The missing LAN to WAN streaming results are due to a problem that Qcheck has with some SPI+NAT routers and not a fault in the SL1000 itself. I should also note that I ran the UDP streaming test at 1Mbps – Qcheck’s maximum rate – and achieved results of 1Mbps throughput with no data loss. This again is a first among routers that I’ve tested.
• All tests were run with LAN endpoint in DMZ
Figure 17: SL1000 routing performance
(click on the image for a full-sized view)
I actually started out testing it with a mix of older and newer machines and got performance closer to 30Mbps – which is still more than most anyone would need. Since both the IPsec tunnel and NAT routing speeds were so ridiculously high, I thought I’d see what happened when both were run at the same time. Figures 18 – 20 show the results with different combinations of the computers that I had on hand.
Figure 18: Mixed NAT and VPN – Combination 1
(click on the image for a full-sized view)
Figure 18 is the most evenly matched combination (given my available computers), pairing a 1GHz WinXP (running SSH Sentinel) and 266MHz WinXP notebooks for the IPsec pair and 2.4GHz Pentium4 WinXP and 733MHz Pentium III Win98SE desktops for the LAN > WAN routing pair. The IPsec pair show performance comparable to what I got back in my standalone VPN testing, but the Win98SE machine really puts a crimp in the NAT routing results.
Note also that I delayed the start of one of the pairs by ten seconds to check for effects when it kicked in. Basically, I wasn’t able to see any difference, no matter which pair started first.
Figure 19: Mixed NAT and VPN – Combination 2
(click on the image for a full-sized view)
Figure 19‘s matchup pairs the two slowest machines for IPsec and the two fastest for normal routing. Nothing holding back the NAT routing results this time! You can also see the effects from the poor little Pentium 266 having to crank 3DES encryption for the IPsec tunnel!
Figure 20: Mixed NAT and VPN – Combination 3
(click on the image for a full-sized view)
Finally, Figure 20 keeps the slowest and fastest pairings, but swaps them between IPsec and NAT duties. This time, the slower pair runs significantly faster through straight NAT routing, but doesn’t even approach the SL1000’s limit.
Bottom line, the SL1000’s routing engine is extreme overkill for pretty much any consumer broadband connection in the U.S.. My brother-in-law who lives in Tokyo has a 40Mbps DSL connection that could probably keep it happy, though!
Routing Performance Test Results
| Test Description | Transfer Rate (Mbps) | Response Time (msec) | UDP stream | |
|---|---|---|---|---|
| Throughput (kbps) | Lost data (%) | |||
| WAN – LAN | 83.3 | 1 (avg) 2 (max) |
500 | 0 |
| LAN – WAN | 86.7 | 1 (avg) 2 (max) |
||
| Firmware Version | SL1000.1.1.08.410, Nov 5 2003, 11:15:04 | |||
See details of how we test.
Wrap Up
As I was wrapping up this review, an ASUS representative called to inform me that I had been somewhat misinformed as to the SL1000’s status. Turns out ASUS also recognizes that the SL1000’s user interface is not ready for prime time and will be delaying its launch until some time in Q3 (2004).
Updated 7/15/2004 Product is now available from U.S. web retailers
ASUS will use the time to completely revamp the user interface (UI) and improve the documentation. So the product you see on store shelves sometime this summer may have a UI look and feel quite different than the one that I (painfully) experienced.
So I hope you enjoyed your tour through what turns out to be a work in progress. I also hope that when the product finally hits store shelves that the UI does justice to – and helps users fully utilize – the unprecedented price / performance that the SL1000 can deliver. I’ll be sure to give it a second look when the product is really released.