Loss of Service Issues

Incompatible VPN Traffic

I was able to put the LinkSys completely out of service by trying to connect using multiple combinations of (apparently) incompatible VPN settings. Since it appears that these would enable an easy Denial of Service (DoS) attack, I'll not say any more about this.

If you are going to experiment with different VPN setups, expect this to happen and be sure to have the right resources present so you can "hard" reboot the LinkSys to which you're trying to connect.

Fatal Logging Setup

I'd tried out the "Wall Watcher" monitoring software (PC-based and runs via Virtual PC) and so had the "Log:" enabled and had set the "Send Log to:" address as ...20 (instead of the default broadcast address of ...255. Apparently using address ...255 really means "turn this feature off so I don't crash." After deciding that the web-page logs were just fine for me, I removed the PC (OK, I shut down Virtual PC). This meant there was no longer a machine at the ...20 address on the network. The router became totally unstable, constantly rebooting itself after receiving a small amount of traffic and/or going deaf to the browser interface (requiring a "hard" reboot). Because of various factors, I didn't associate the two conditions. I actually returned the LinkSys unit, thinking I had a hardware failure (I did ... there was a nut loose in front of the LinkSys [me]). When the exchange unit did the same thing, I did some troubleshooting and found the problem.

I'd expected to be able to leave the "Send Log to:" address set to ...20 so I could turn the logging "machine" on/off as desired. Don't do this. If you have the unit set to "Send Log to:" and an address other than ...255, don't turn off the PC (or have it crash, or take too long to reboot, or ... good luck!).

I don't remember which version of firmware I experienced this problem with and it was reported to LinkSys, so I don't know whether it still exists. Can anyone confirm?

I simply entered an IP address range set as "Deny"/"Incoming" for protocol "All" and the LinkSys became totally unstable and began rebooting every tens of seconds of operation. I removed the filter entry and stability returned. This was with firmware version 1.44.7. The other thing I discovered in earlier filtering entries is that you don't seem to be able to have a filter name containing a space character.

From the log reporting and the LinkSys and DSL modem lights, it was unclear whether NetBIOS packets were being routed, so I defined two filters to block both outgoing and incoming NetBIOS packets (see graphics below). The log is still unclear about whether or not they are being blocked (WAN-to-LAN), but the lights give me confidence (that and the fact that I finally followed up with a network sniffer setup).

I use/recommend the following "Filters" settings, to increase security:

• enable "Block WAN Request" to make your site less responsive to probes
  
  
• disable "Multicast Pass Through", "IPSec Pass Through", "PPTP Pass Through" and "PPPoE Pass Through" unless you need one or more of these (note that you don't need "IPSec Pass Through" when using the host-to-network and network-to-network setups I've described elsewhere ... I only had this turned on to support another routing experiment)
  
  
• disable "Remote Management" unless you really, really need it (unfortunately, the web-based interface cannot be accessed via a VPN connection ... a flawed strategy, as far as I can tell)
  
  
• disable "Remote Upgrade" unless you really, really need it

Loss of Feature Issues

Web-based Firmware Updates

I was unable to get the web-based firmware updates to work. My attempts were with some firmware version(s) of 1.43.x and/or 1.44.x (don't remember exactly) and OS X 10.2.x with Safari. After a couple of failures, I no longer attempted to use it and now just use Virtual PC running the TFTP-based PC update software. I realize that there could be multiple reasons why it might not work; might require Windows-proprietary features (if so, then don't "pretend" by making it browser based), might require something I had turned off (e.g., cookies), etc. Regardless, since the "Upgrade Firmware" page doesn't identify any specific requirements, one should expect it to work.

DynDNS Support

I was unable to get the DynDNS support to work. My latest attempt was with firmware version 1.44.7. I wrote a shell script to help satisfy our requirements, but I'd still like to have this capability working. Let me know if you've been able to get it to work.

Keyword Filtering

Using the "Firewall" page, I was unable to get keyword filtering to work reliably. I defined some basic keywords such as "/ad/", "banner", "hitbox", and "spinbox". It will catch/block the same URL some times but not other times and it's "catch" rate is quite low. Even the log reports the inconsistency. Reporting this issue to LinkSys support was actually the item that caused me to give up on them.

After taking the time to produce a very detailed, step-by-step problem report (complete with 8x10 color photos, as the saying goes), I was first met with a series of standard responses (reboot, upgrade firmware, etc.) ... even 'though I'd clearly indicated that all these had been done. After multiple emails, I finally communicated with "an expert."

Eventually, they sent me the 1.44.7 firmware pre-release ... and asked me to test it and tell them whether it worked. They didn't appear to have tested the potential fix. This infuriated me. I'd provided enough information that they could easily test the problem I was having. One would expect LinkSys to actually have multiple test setups available. Since the new version didn't work any better, I gave up on LinkSys support.

I use/recommend the following "Firewall" settings:

• enable "Advanced Firewall Protection" ... this turns on Stateful Packet Inspection (SPI) and, although it's not certified, should add some significant protection over a simple Network Address Translation (NAT) firewall
  
  
• disable "Proxy" unless you need it

I have never tried the time-based filtering capabilities.