After several months now of ad hoc testing I have come to a startling conclusion. At least it's startling to this particular naive soul! Linksys devices are generally a pale shadow of the reliability of those of their parent company, Cisco. I am constantly annoyed by the litany of missing, broken, idiosyncratic and generally poorly conceived and even more poorly implemented features on Linksys' "Business Series" routers. I have had direct, negative, experience with the WRV200 and WRVS4400N...both devices which, on paper, have the most amazing features. The WRV200, for example, has multiple SSIDs, VLAN capability, WDS, IPSec VPNs (both site-to-site and remote access) and a very low price point. It was introduced in February of last year and only now...after several code revisions....it is almost ready for show time.

I ordered a Cisco ASA 5505 security appliance today. I should have it within the next two to three weeks. I will post my impressions of the unit as I integrate it into my network.

Two of the features that I plan to do a fair amount of experimentation with include WebVPN as well as the SSL VPN client.

Here's a link to an interactive presentation of the the ASA 5505 on the Cisco Website. Click Here.

/Eric

Let me explain something that I've done on my home network to make the remote access VPN thing even slicker!

I have setup a Linux box in the DMZ network on my Linksys RV042 firewall as a DNS server (among other things). The Linux box is setup on the RV042 as its 1st (of two) DNS servers. Thus, when I QuickVPN to my home network, my DNS requests resolve to the the RV042's 1st DNS server...my Linux box since QuickVPN uses the RV042 (QuickVPN gateway) as its own 1st DNS server.

[Sidebar: Use the Breezy! site's search function to search for BIND9, or you can start by going to this link here. There are several postings on this subject.]

My syslog was filling up at an alarming rate so I decided to turn off one of the "running taps". The PIX no longer dumps all debug messages out to the syslog server.

I also configured SNORT so that it would send realtime alerts to syslog. Very useful since logchecker will scan the syslog hourly and send me an email with "Security Alerts" as required, making my IDS as realtime as I need it to be.

Just take a look at the /etc/snort/snort.conf configuration file for SNORT and it's pretty obvious which line you need to uncomment in order to do this.

To recap, SNORT now logs to:
/etc/snort/alert <-- used by SnortSnarf for html

I am able to get a reliable, solid QuickVPN connection to my RV042 at home. For those unfamiliar with the thread, navigate over to LinksysInfo.org (link in menu bar at the top of the Breezy! site) and also this link on the Breezy! site before reading futher... Don't forget to use the search function. use QuickVPN as a keyword.

I should point out that I am behind 2 NAT’ng devices as well. The RV042 might be behind a PIX, but it’s working fine as long as I forward ISAKMP, ESP and (optionally) NAT-T traffic to it. I’m using QuickVPN 1.0.47 and the latest beta code for the RV042. Forwarding these protocols isn’t a bandaid or a patch. I realize in looking closely/closer at how QuickVPN works that I had made incorrect assumptions of how QuickVPN works but now have my mind around it. That is why my solution is working now, since I am forwarding all the traffic that the VPN connection might need to the RV042. The “Negotiating IP Security Policies” message I was getting before I fixed my configuration was because I wasn’t allowing IKE messages through to the RV042. All negotiation of keys, ciphers and hashing algorithms happens during IKE Phase I and I was unintentionally blocking it by not allowing it through. Furthermore, I had to forward all the ESP (IKE Phase II) traffic to the RV042. Makes sense, though with the PIX’s VPN passthrough feature on (see “fixup protocol esp-ike” in the configuration notes) this is probably unnecessary.

What annoys me is that they can start with a nice Open Source OS, wrap a nice GUI around it then screw it up. It's not like Free S/WAN, Pluto, OpenVPN and PPTP haven't been around for a while. They're free for the taking. Somehow I think the hardware is the culprit.

Example. I built an Ubuntu 6.10 server on a Pentium III, 1 GHz machine with 384 MB RAM. It's got the following server stuff on it:

• Apache-Perl
• Apache-SSL
• OpenSSL Certificate Authority
• Courier-MTA IMAP/S, POP3/S, SMTP/S
• NoMachine X thin client/server
• SSH Server
• OpenVPN server
• Drupal CMS

Firestarter is a non-starter! At least on a server. I pulled a Homer Simpson and was fooling around with Firestarter. It is a GUI front-end to an iptables (native Linux) firewall. While playing with it, I somewhow inadvertently "started" the firewall. I'm pretty sure I didn't (boy, do *I* sound like a user!) but guess what happened? You guessed it...my server wasn't a server anymore as it stopped accepting any inbound connections whatsoever. Ooops. No email, web server, X Server, Radius server....nuthin' !!

Since I access Breezy! by remoting in using SSH or an X client, I had to physically attach a keyboard and a monitor to the computer and uninstall the package which cleared all the firewall rules.

This is by no means an attempt to go into deep technical detail of QoS mechanisms, strategies, algorithms and terminology. If you are already a sophisticated QoS expert, some of the analogies and points will probably offend you with their simplicity. That said, the points that are made in this short primer are intended to give a good overview of some of the important terminology and technology involved in an end-to-end QoS solution to the beginner (but technical) reader. The perspective is deliberately skewed towards the SOHO user, though it dabbles in some service provider concepts as well. It finishes with a simple case study of a SOHO VoIP solution and deliberately leaves the reader hanging on the edge. The provider edge that is! The end of the story…which is really the middle of an end-to-end QoS solution….will wait for another day.