Router Throughput Issues

We have a small office network and recently became aware of some substantial Internet<->network slowdowns. I spent some time trying to isolate the issue and found the culprit to be our Cisco VPN Router (RVL200). When the 'firewall' option was enabled, external traffic was slowed by a factor of 10. Granted the RVL200 is a low-end business-class router, but a slowdown of 10x is beyond the pale.

Our Internet connection speeds are rated at 20/1.7 MB/s by our ISP. Here's my findings:

ISP: Cox, cable broadband rated at 20/1.7 (download/upload).
Broadband Cable Modem: Motorola Surfboard SB5100, firmware version 2.3.6.0
Primary router: Cisco/Linksys RVL200 VPN Router, firmware 1.1.10.1
Router: Linksys Wireless G Broadband Router WRT45GS v7, firmware 7.50.8
Router: Netgear Wireless-G Router WGR614 v10, firmware 1.0.2.4_39.0.39NA

Speed test: http://www.speakeasy.net/speedtest
My location: Las Vegas
Test location: Los Angeles
Methodology: Asus netbook computer, Windows XP SP3, physical wired connection to devices, nothing else connected. Tests run a couple of times to confirm consistency.

Test 1: Surfboard: 14.13/4.85
Test 2: RVL200 (firewalled): 2.46/2.79
Test 3: RVL200 (not firewalled): 20.04/5.32
Test 4: RVL200 (firewalled, other settings disabled): 2.35/2.88
Test 5: WRT54GS (firewalled): 20.39/4.92
Test 6: WGR614 (firewalled): 20.8/5.41

Conclusion: the RVL200 doesn't have a firewall, it has a *brick* wall. We've since moved to a Sonicwall appliance for our VPN, so the RVL200 is looking for a new home...

Unable to Connect to SQL Server While VPN Active

I've had the following problem for quite some time now, and finally resolved. At first blush, it seems like a simple enough issue to resolve, but in my particular case, it wasn't.

Basically what happened is that I have an instance of SQL (Express) installed on my primary development machine that is used as part of design, development, and building of the various applications I'm working on. I also have need to connect to a particular customer network via VPN (Aventail/SonicWALL). Everything was working fine until a few months ago when the customer updated the VPN client (from 9? to 10), at which point I was no longer able to access my SQL instance through trusted connection.

For example, if connected to the VPN and attempting a command line query, I'd see the following:

C:\>osql -S localhost\sqlexpress -q -E
Login failed for user ''. The user is not associated with a trusted SQL Server
connection.

In checking the event log, I'd see the following error:

SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: nnn.nnn.nnn.nnn]

If I disconnected the VPN, the above works as expected (no error).

?

My first conclusion was that the new VPN client was tunnelling ALL traffic through the appliance, and local requests back to my machine, and therefore SQL was considering the request as 'remote' and denying it. I tweaked the necessary SQL properties to allow remote connections -- nada.

After spending a lot of time trying to diagnose, I temporarily gave up and just resolved that I'd either be able to do VPN work or SQL work, but not both simultaneously.

Not satisfied with that 'solution', I resolved to spend more time on it. I'll leave out the countless things that I did try and didn't work and mention what I did find that actually solved the problem for me -- hopefully it will help someone else:

I started looking at the SQL configuration a little more closely (Start Menu\Programs\Microsoft SQL Server 2005\Configuration Tools\SQL Server Configuration Manager) and noticed some differences from some of the other typical SQL installations I have floating around. Specifically:

Under SQL Server 2005 Network Configuration: all protocols were enabled.
Under Aliases, there were several aliases using the tcp protocol.

I reset the above to coincide with what appears to be the default configuration:

SQL Server 2005 Network Configuration
  Shared Memory - Enabled
  Named Pipes - Disabled
  TCP/IP - Disabled
  VIA - Disabled

Deleted all SQL Native Client Configuration Aliases.

After that, my VPN/SQL issues were resolved! I'm not exactly sure what was the cause (protocol or alias), but a little more post-fix experimentation leads me to believe tha that the aliases were the problem. How that relates to the updated VPN client, or if it was purely coincidental, I don't know, but it is fixed and I'm satisfied!