At the end of last week, I decided to take a chance and upgrade my primary desktop system from Vista (which, once you disable UAC, is perfectly fine, by the way) to Windows 7. I previously had 7 installed on one of my vintage laptops, but the machine was really not up to the job.
My desktop system is a venerable old HP xw4000, which, when it was new, was a high-end engineering workstation. It has a pair of 2.8 GHz Intel Xeon processors, built-in SCSI drive interface and 3 GB of RAMBUS memory. It is, in fact, very similar to our primary workhorse Dell server. It is, however, an old system, so the upgrade to Windows 7 was not a risk-free decision. Nevertheless, it has been running Vista fine for years, so I felt that, after a full backup, an in-place upgrade was worth a shot.
I started by running Microsoft's Windows 7 compatibility checker, which I found somewhere on the web, but cannot locate now. I already had the disk, so it really wasn't necessary because the same tool is on there as well. That test passed, but once I actually started the install, it goes through a more fine-grained analysis and turned up additional hardware and software issues.
This part of the process qualifies it as a "techstration." I had to restart the installation process several times and each time it came up with additional hardware or software issues that I had to address. The first hardware thing was, I thought, a show-stopper, having to do with the on-board SCSI adapter. I could not locate a Windows 7 driver (the driver will probably show up on the web at some point in the future), but I did find a workaround for the Adaptec SCSI card that I also have in the computer. I disabled the on-board SCSI and plugged my primary drive into the Adaptec card instead. Previously that card was used just for the tape backup drive. The card can handle up to 14 devices, so having one device on each channel was not an issue at all. I don't really recall why I had even installed it to begin with. It was probably something silly like a cable issue that prevented me from using the on-board SCSI for both the disk and tape drive. Anyway, using the Adaptec card for both worked fine.
The Win7 installation also issued a warning about my on-board Realtek audio, but I just ignored that, figuring that worst case I could plug in an audio card. I also had to uninstall WindowBlinds and Microsoft's OneCare. The latter has been discontinued and replaced by Microsoft's free Security Essentials malware software. (Save that link! It's another one that is WAY too hard to find.)
The last time I restarted the installation, it told me I should uninstall Microsoft SQL Server 2008! This I could not understand, and I was fed up with restarting the installer and waiting through the test repeatedly, so I just ignored that as well. I don't really use my local copy of SQL Server for anything, so I am not sure whether it still works or not.
At long last, the actual installation started. I checked on it from time to time during the next five hours or so, but it was still not finished, so I just turned off the monitors and went to bed. The following morning, it appeared to have completed successfully and was patiently awaiting my log-in.
Over the past few days I have run into a couple of little things, but nothing bad. For example, whenever I clicked the shortcut to start Tigerpaw, the CRM software that we use, it mysteriously started the program's installer. This has happened before with this software, but I resolved it relatively painlessly by uninstalling and reinstalling TIgerpaw. The database is on the server and all my preferences were preserved, so it was no big deal.
There were a couple of other little things that were too unremarkable to remember. So, bottom line --- so far, so good.
Wednesday, October 7, 2009
Monday, October 5, 2009
Zywall SSL 10 - Browser Workaround
An increasingly annoying issue with the Zyxel Zywall SSL 10 vpn appliance is that you have to download the client software from the appliance when you connect, and the officially supported browser list does not include IE8. Actually, I don't think it includes IE7 either, but Zyxel tech support told me that IE7 does work, and subsequent testing confirmed that to be true. Once 8 is installed on an XP or Vista system, you can restore 7 by uninstalling IE8. OK, not happy about it, but that is workable -- until you go to Windows 7, where the default browser is IE8.
Once the Zywall Secu-extender virtual VPN adapter is installed, you can start the VPN using the system tray icon. Our remote programmer somehow damaged his pre-Windows7 installation of the Secu-extender, so we were now faced with re-installing it. Tried IE8 and Firefox, but neither gets past the "Loading..." graphic. On a hunch, we tried Chrome (v. 3.0.195.24) and it worked perfectly! For now, that appears to be the workaround. I see nothing on the Zyxel site that suggests that they will be updating the firmware in the Zywall SSL 10 to support the newer versions of IE or Firefox, so let's hope that Google keeps Chrome from getting too fancy.
To be specific, the fix in this case required uninstalling the broken Zywall Secu-extender from Control Panel, then launching Chrome and connecting to our https URL to trigger a fresh download and install.
Once the Zywall Secu-extender virtual VPN adapter is installed, you can start the VPN using the system tray icon. Our remote programmer somehow damaged his pre-Windows7 installation of the Secu-extender, so we were now faced with re-installing it. Tried IE8 and Firefox, but neither gets past the "Loading..." graphic. On a hunch, we tried Chrome (v. 3.0.195.24) and it worked perfectly! For now, that appears to be the workaround. I see nothing on the Zyxel site that suggests that they will be updating the firmware in the Zywall SSL 10 to support the newer versions of IE or Firefox, so let's hope that Google keeps Chrome from getting too fancy.
To be specific, the fix in this case required uninstalling the broken Zywall Secu-extender from Control Panel, then launching Chrome and connecting to our https URL to trigger a fresh download and install.
Tuesday, July 7, 2009
Zywall SSL 10: The Missing Third Option
Part of my job is creating documentation for our company's software. As a result, I am probably responsible for inflicting the same kind of techstration (tech frustration) that I am about to condemn. I am aware of the irony, but it doesn't make me any more tolerant when I am the victim of lousy documentation of high tech products.
My immediate goal is to provide a life raft to the next person who attempts to install Zyxel's Zywall SSL 10 vpn appliance. It took WAY too long for me to get this thing implemented. Decent documentation could have reduced the entire process to an hour or two. Many of the hours I spent wrestling with this installation were spent searching the web and reading dozens of web pages in search of just one that might guide me in the kind of implementation I was attempting. Let's see if I can do any better myself:
To begin, I have been using a Zywall 10-ii router/firewall/vpn for quite a while as our primary firewall and as the basis for an ipsec VPN tunnel for remote workers. There have been some still-obscure techstrations with VPN client software, but we did find one version (1.4 to be precise) of the SSH Sentinel vpn client that Zyxel used to re-sell that worked for us. It carried us through several years with minimal downtime. Suddenly, for no apparent reason, the vpn no longer worked for Joe, the person who absolutely needs it to his daily work.
I have successfully been on the client end of a Sonicwall SSL vpn connection with one of our customers for several years, so I thought that it might be time to move to something similar. I further discovered that Zywall now has a most reasonably priced model called the Zywall SSL 10, which I foolishly assumed was an updated model of my trusty Zywall 10-ii with the addition of an SSL vpn feature. The descriptive marketing material seemed to reinforce this belief, so I bought one, thinking that I could leverage my hard-won knowledge of Zyxel products to make the installation a bit easier.
Only after a couple of hours of messing around with the configuration did I realize (subsequently confirmed by Zyxel tech support) that this unit does provide the SSL vpn, it does NOT provide robust, traditional firewall functions. That is kinda strange, given that the (grossly inadequate) documentation offers an installation option that puts the unit into the roll of primary internet gateway. The alternate configuration is to use your existing gateway/firewall, plugging the Zywall SSL 10 into the other unit's DMZ port.
Our old Zywall 10-ii does not have a DMZ port, and the new one does not have adequate firewall features. Somewhere in the docs I found a mention that a separate gateway could be used even without a DMZ port, but none of the examples or graphics showed how. In addition, along the way I realized that routing the SSL port (443) to the vpn would mean that I would have to figure out how to do remote access to Outlook and our company intranet some other way than the default, which uses port 443. I resigned myself to returning the new Zywall unit to Provantage and resumed my quest for vpn client software that might work with our existing ipsec vpn hosted by the old Zywall firewall and also run on Vista and Windows 7.
A bit of snooping revealed that Zyxel now resells the GreenBow vpn software, with which I had never had any luck, in spite of perhaps the best how-to articles I encountered during this entire adventure. Perhaps the new software didn't care for the old hardware or something, but hours of trial resulted only in error. I came close, but could not get a functional tunnel established even using XP.
Some people claim that they experience epiphanies in dreams, or somehow solve problems in their sleep. I generally have to be a bit more conscious; for me they invariably occur in the shower. In this case, some part of my mind was still mulling over the Zywall SSL appliance, which I had not yet sent back to Provantage. The two things that had me stuck were the DMZ port and the "WAN" label on the incoming port of the SSL unit. My epiphany was the realization that the critical thing was just routing the incoming 443 traffic to the vpn box, and I knew how to do that! So all I had to do was to assign a static LAN address to the vpn box's "WAN" port, and configure the old router to divert the incoming 443 traffic to it. In fact, that worked.
Here is the way I set it up. For this example, assume the LAN addresses are in the 192.168.1.0/255.255.255.0 subnet, and that your existing gateway router is set to 192.168.1.1, and that it is configured as a DHCP server that distributes 32 addresses starting with 192.168.1.33. Further, let's say that you assign static addresses, when required, starting with 192.168.1.201.
See the diagram above for cabling. The key is to run a cable from your switch to the Zywall SSL's WAN port. In addition, use a laptop plugged into one of the SSL's LAN ports to do the configuration.
My immediate goal is to provide a life raft to the next person who attempts to install Zyxel's Zywall SSL 10 vpn appliance. It took WAY too long for me to get this thing implemented. Decent documentation could have reduced the entire process to an hour or two. Many of the hours I spent wrestling with this installation were spent searching the web and reading dozens of web pages in search of just one that might guide me in the kind of implementation I was attempting. Let's see if I can do any better myself:
To begin, I have been using a Zywall 10-ii router/firewall/vpn for quite a while as our primary firewall and as the basis for an ipsec VPN tunnel for remote workers. There have been some still-obscure techstrations with VPN client software, but we did find one version (1.4 to be precise) of the SSH Sentinel vpn client that Zyxel used to re-sell that worked for us. It carried us through several years with minimal downtime. Suddenly, for no apparent reason, the vpn no longer worked for Joe, the person who absolutely needs it to his daily work.
I have successfully been on the client end of a Sonicwall SSL vpn connection with one of our customers for several years, so I thought that it might be time to move to something similar. I further discovered that Zywall now has a most reasonably priced model called the Zywall SSL 10, which I foolishly assumed was an updated model of my trusty Zywall 10-ii with the addition of an SSL vpn feature. The descriptive marketing material seemed to reinforce this belief, so I bought one, thinking that I could leverage my hard-won knowledge of Zyxel products to make the installation a bit easier.
Only after a couple of hours of messing around with the configuration did I realize (subsequently confirmed by Zyxel tech support) that this unit does provide the SSL vpn, it does NOT provide robust, traditional firewall functions. That is kinda strange, given that the (grossly inadequate) documentation offers an installation option that puts the unit into the roll of primary internet gateway. The alternate configuration is to use your existing gateway/firewall, plugging the Zywall SSL 10 into the other unit's DMZ port.
Our old Zywall 10-ii does not have a DMZ port, and the new one does not have adequate firewall features. Somewhere in the docs I found a mention that a separate gateway could be used even without a DMZ port, but none of the examples or graphics showed how. In addition, along the way I realized that routing the SSL port (443) to the vpn would mean that I would have to figure out how to do remote access to Outlook and our company intranet some other way than the default, which uses port 443. I resigned myself to returning the new Zywall unit to Provantage and resumed my quest for vpn client software that might work with our existing ipsec vpn hosted by the old Zywall firewall and also run on Vista and Windows 7.
A bit of snooping revealed that Zyxel now resells the GreenBow vpn software, with which I had never had any luck, in spite of perhaps the best how-to articles I encountered during this entire adventure. Perhaps the new software didn't care for the old hardware or something, but hours of trial resulted only in error. I came close, but could not get a functional tunnel established even using XP.
Some people claim that they experience epiphanies in dreams, or somehow solve problems in their sleep. I generally have to be a bit more conscious; for me they invariably occur in the shower. In this case, some part of my mind was still mulling over the Zywall SSL appliance, which I had not yet sent back to Provantage. The two things that had me stuck were the DMZ port and the "WAN" label on the incoming port of the SSL unit. My epiphany was the realization that the critical thing was just routing the incoming 443 traffic to the vpn box, and I knew how to do that! So all I had to do was to assign a static LAN address to the vpn box's "WAN" port, and configure the old router to divert the incoming 443 traffic to it. In fact, that worked.
Here is the way I set it up. For this example, assume the LAN addresses are in the 192.168.1.0/255.255.255.0 subnet, and that your existing gateway router is set to 192.168.1.1, and that it is configured as a DHCP server that distributes 32 addresses starting with 192.168.1.33. Further, let's say that you assign static addresses, when required, starting with 192.168.1.201.
See the diagram above for cabling. The key is to run a cable from your switch to the Zywall SSL's WAN port. In addition, use a laptop plugged into one of the SSL's LAN ports to do the configuration.
- Connect to the Zywall SSL 10, using the default address and login, or whatever you previously set.
- Once in the configuration application, expand the SYSTEM branch and select WAN.
- Under WAN IP Address Assignment, set the IP Address Assignment type to "Static".
- Set My WAN IP Address to an available address within your LAN subnet. In this example, we can use 192.168.1.210.
- Set My WAN IP Subnet Mask to 255.255.255.0.
- Set the Gateway IP Address to the address of your gateway/firewall/router: 192.168.1.1 in this case.
- Set the first and second DNS server addresses to your ISP's suggested DNS addresses, or your gateway address, or a DNS server within your LAN.
- I left the MTU at the default of 1500.
- We are not using the vpn unit as a gateway, so leave the Enable NAT option UNchecked.
- Leave the WAN MAC Address setting as the default and save with OK.
- After saving the WAN settings, go to the LAN page.
- Set the IP address to an address outside your LAN addresses, such as 192.168.41.1, with a subnet mask of 255.255.255.0. This is the address you will use to get into these configuration screens in the future, but to do so, you will have to plug a computer directly into one of the SSL's LAN ports.
- Check the DHCP Server option and set an address range in the 192.168.41.0 subnet. Although you will probably never use more than one address, it won't hurt to set a wide address range, say 192.168.41.101 to 192.168.41.200.
- Save the LAN settings with OK. The change of address means that you will lose your connection to the configuration interface. A message will appear to that effect. You will have to go into Network Connections (assuming you are running Windows), right-click the interface you are using to connect to the SSL, and select REPAIR. In most cases that will cause the network card to reset and get a fresh IP address, which now will be 192.168.41.101, the first address in the just-modified DHCP address pool. In rare cases you might have to reboot your computer.
- You should now be able to reconnect to the SSL box using its new address 192.168.41.1.
The rest of the configuration is covered in the manual adequately, I guess, because I was able to get everything else configured without too much trouble. Note that under Object you configure "VPN Network". Here you will use your LAN address settings. In our example, this would be 192.168.1.0 with a subnet of 255.255.255.0. Essentially, you are thereby allowing the remote users to be part of your LAN once the tunnel is created. They will be able to ping your LAN addresses and map network resources (using ip addresses, if not machine names). In the same section is a page called "Remote User IP" where you will set the specific address range to be assigned to vpn users. This should be an address range within your LAN but not overlapping any of your existing static address or your DHCP address pool.
The saga does not end there, for acquiring and installing an SSL certificate was yet another techstration. I will leave that for the next installment.
Subscribe to:
Posts (Atom)