You are here: Central > Broadband Home Labs > About Our Broadband Condo > PC and Internet: Progress To Date

Updated 7/29/2007

Our Broadband Condo: PC and Internet: Progress To Date

When we purchased our condo in early 2005, we made ambitious plans to equip it both for our use when we're there, and for renters who use it most of the time. This page discusses the process required to plan and implement the PC and Internet infrastructure. The next section describes the Media and Communications infrastructure.

We took possession of the condo in April 2005 and spent the first week of May at our condo setting up the broadband infrastructure (and much more). Before we went to Florida, we created detailed plans, purchased equipment and tested it at home. In Florida, we installed and tested the equipment and got much of it working. We thought we'd have everything working by our next visit, but it took a lot more time, largely because we're only at our condo a few weeks each year and have lots of other things to do—including vacation!—when we are there

{July 2007)The PC and Internet infrastructure is finally working as planned more than two years ago. DDNS and VPN proved to be the toughest problems.

What We Planned to Do

To meet the needs of our guests and ourselves, we thought we'd need to provide the following:

A PC for guests who don't bring their own.
To use the PC when we're there, we'll need to equip it with Windows XP Professional so we can log into our home domain.
A broadband internet connection. We thought we'd first try a wireless bridge to the Wi-Fi network provided by the condo complex; if that didn't work reliably, we'd install a cable modem.
Virus protection and Web filtering software.
A printer for our guests and us, and a convenient way for guests to connect to the printer.
Media readers for several formats of memory cards used in digital cameras, such as Compact Flash (CF) and Secure Digital (SD).
A reliable Wi-Fi link supporting both 802.11g and 802.11b for guest PCs with Wi-Fi. (The complex Wi-Fi network doesn't provide a strong enough signal inside condo units.)
Ethernet ports and telephone jacks for guest PCs without Wi-Fi or who prefer to connect directly. We thought about providing wireless cards for guests who needed them, but we didn't want to talk each guest through installation and wouldn't be surprised if some guests forget to leave the card behind when they leave. So we wanted to provide several easily-accessible Ethernet ports and cables to connect several PCs to the ports. We also wanted to provide telephone jacks so guests can dial-up if necessary.
A secure firewall to provide security against unwanted intrusion. We wanted the firewall to support "VPN passthrough" so our guests can access corporate networks; we'd also like it to provide "VPN tunneling" so we can access our home network and our ISP's server from the PC in the condo.
A new desk to hold the PC, its monitor, keyboard and mouse. We also wanted it to have space for the printer, the firewall/VPN router/print server and perhaps for a guest PC.
Comfortable and ergonomic task chair(s) and good lighting.

VPN Equipment Selection and Initial Testing (April/May 2005)

Before we left for Florida, we selected some equipment and started testing it at home. We moved some of the equipment to our condo for testing on site.

Equipment Selection (April 2005)

After looking at a number of alternatives, Netgear VPN equipment and software appeared to provide the best fit for our requirements in terms of functionality and price. Here's what we bought:

A Netgear FVS318v3 ProSafe VPN Firewall -- This will act as the gateway for our home network, sitting between our cable modem and our elaborate internal network. It has a secure firewall, a VPN router with support for eight tunnels, and eight Ethernet ports.
A Netgear FWG114Pv2 ProSafe 54 Mbps Wireless Firewall with USB Print Server -- This will act as the gateway for the condo, sitting between the wireless bridge and the condo network. It has a secure firewall, a VPN router with support for two simultaneous tunnels, four Ethernet ports, an 802.11g access point and a USB print server.
Two copies of Netgear VPN01L ProSafe Client Software -- We'll install copies of this software on the two notebook PCs we use on the road.

Testing VPN At Home (April 2005)

We read enough VPN documentation to see that setting up VPN networks is far from straight-forward. VPN gateways and clients are paranoid--if they aren't configured exactly right, they don't work at all.

Our first project was to get the FVS318 VPN Firewall working in our home's production network, replacing the SIP firewall we've been using for the past two years.

To make life easier, we installed a second cable modem in our house. We now have two independent networks--our home "production" network, and a test network to simulate the condo or another remote location.
We signed up for a dynamic DNS service, and configured one of our domain names to assign FQDNs to the home and condo gateways (see Key Technologies for more on DDNS and FQDNs).
We hooked up the second cable modem, did a little CAT5 rewiring so we could easily configure the different network configurations in our server room, and got the new cable modem working first with a PC and then with a cable/DSL router.
We then connected the FVS318 VPN Firewall to the second cable modem and configured it for simple Internet access. Once we were sure the FVS318 wasn't going to cause any problems with our normal operations, we moved our "production" network from its previous firewall to the FVS318 on the second cable modem.

We were now ready to set up our first VPN tunnel. We thought it would be easiest to first set up a tunnel for remote access from a PC to the gateway--in retrospect, this was probably a mistake.

We set up a test network on the first cable modem, using a Linksys cable/DSL router and one of our notebook PCs.
We looked at the manuals that came with the Netgear VPN client software and the FVS318, collected what we thought was the necessary information, and used the VPN Wizard in the FVS318 to configure a tunnel for remote access.
We then installed the Netgear VPN client software on the notebook PC on the test network and followed the procedure in the manual to configure the client software to connect to the FVS318. It didn't work.
After nearly a day of concerted effort, we finally got the remote access tunnel working. Our major challenge was that all of Netgear's documentation showing how to configure the VPN client software with the FVS318 was based on earlier versions of the 318 firmware. The version 3 firmware that came with the FVS318v3 is undoubtedly superior to the earlier firmware, but it uses a different user interface. The manuals that came with the client software and the FVS318, and the documentation on Netgear's website, describe all the key parameters for configuring VPN tunnels; unfortunately, these parameters all appear with different names in different places on different screens than those described in detail in the manuals. By the time we got a tunnel working, we had learned much more about how IPSec VPN works than we thought we'd need to know.
The tunnel is "working" in the sense that we can communicate between the two networks. We can "ping" any PC in our home network from the remote PC, and vice versa. And we can log onto the VPN gateway from the remote PC.
But we can't as yet log into our Windows NT domain to exchange files, and we can't open web pages on our internal web servers. This is most likely a Windows NT problem, not a VPN problem. We put it aside to get the other gateway working.

Next, we set up the FWG114P firewall for "gateway-to-gateway" VPN.

We connected the FWG114P to the test network, and used the wizard to establish an Internet connection.
We then set up a VPN tunnel connection between the two gateways. Since both gateways are running essentially the identical VPN software, with the same user interfaces, it was very easy to configure both with appropriate complementary parameters for "gateway-to-gateway" VPN. It seemed very easy -- perhaps because we'd learned a great deal about VPN parameters by the time we got the "client to gateway" connection working.

We set up Dynamic DNS on both gateways, since both forms of VPN depend on FQDN identification of the other party to the VPN connection.

No Wireless Bridge For Now

Shortly before we left for Florida, we realized that we would have a problem using the wireless bridge and VPN together. VPN depends on Dynamic DNS to provide FQDN identification. A gateway with a DDNS client is usually connected directly to a broadband modem, and takes on the identify of the IP address assigned dynamically to the modem.

If we used a wireless bridge in the condo, our gateway would not be connected directly to the broadband modem. Rather, the VPN gateway would be connected through the wireless network to another router which connects to the broadband modem, and would receive a subnet IP address which would not be accessible from the outside.

Since it appeared difficult--maybe impossible--to use DDNS through a wireless bridge, we made a quick decision to put off using the wireless bridge for now, and ordered a cable modem for the condo. We'll come back to the wireless bridge later.

In Florida (May 2005)

While we were in Florida, we installed a PC and a cable modem, and got it working with the VPN firewall. But we didn't get the VPN connection working between the condo and our home.

We installed a Sony VAIO PC equipped with the latest version of Microsoft Media Center Edition. We planned to install a large-screen plasma TV later that year, and expected to stream video from the new PC to the TV.
We installed a flat-screen display and a color printer, and put all the equipment on a proper computer desk with a task chair.
We installed a cable modem, and got it working with the FWG114P firewall.
We got the wired and wireless connections working inside the condo, through the firewall.

But we could not get the firewall to connect through VPN with our gateway at home. The VPN setup that had worked at home didn't work at the condo. It looked like the dynamic IP address had changed at home and the DDNS client had not updated the DDNS server properly. It was impossible to debug this from Florida -- New Jersey was far away and we couldn't be in two places at the same time! We left the VPN firewall set up on the condo so we could get VPN working later.

Current Status (July 2007)

We finally got VPN working properly in July 2007, more than two years after we started. We had been very close, and probably could have gotten it working a year earlier if we had put our minds to it.

(June 2005) By the time we left Florida, we had met all of the user needs for our guests. But we had not met some of our additional needs.

We had five remaining problems to solve:

A reliable DDNS update.
A reliable VPN connection between the condo and home.
Establishing a connection to our Windows NT domain through the VPN.
Maintaining the condo PC from home
Using the wireless bridge instead of the cable modem.

When we got home, we made progress on the first two problems. We bought a second FWG114P firewall and connected it to the second cable modem, so Dave could simulate the condo network from home.

With this setup—and a lot of digging and experimenting—we got dynamic DNS working on the Netgear routers. We found the successful approach on the Netgear support forum. The posting says Netgear routers don't support Custom DNS (where you use your own domain name), but only regular Dyndns.org subdomains (where you use one one of the Dyndns domains). The trick is to register for a free subdomain at Dyndns, then make a cname record under "Advanced" to point to it (e.g., home.mydomain.com --> homemydomain.dyndns.org).

Although DDNS seemed to be working fine, the FWG114P VPN gateway on our production network kept disconnecting from the Internet. It seemed to have a problem renewing its IP address, and we hoped Netgear would issue a firmware download to fix the problem. Meanwhile, we went back to our old gateway, planning to work on VPN when we again had some time.

For the remaining problems, we still needed to do more research.

(February 2006) After finishing the remodeling project in January (see the next page), we had a little time to go back to the VPN connection. We were encouraged to find that Netgear had issued firmware upgrades for both VPN routers, and hoped this would resolve the DDNS instability problem we had encountered earlier.

We downloaded the new firmware on the FVS318 firewall, and reinstalled it as the Internet gateway in our home production network. If it stays connected properly, we should be able to get VPN working reliably and work through the other issues on our list.

But we didn't expect to have time to work on VPN in the near future. So we discontinued service for the second cable modem and disconnected the second FWG114P firewall until we could find time to work on it again.

Success At Last! (July 2007)

We scheduled a vacation at our condo in early July 2007. The FVS318 firewall had been working flawlessly in our production network for more than a year, so we decided the time had come to get VPN working. A month before we left for Florida, we re-established our test network at home, simulating the condo network. We reactived service for the second cable modem, reconnected the second FWG114P firewall, and upgraded its firmware.

We were glad to find that DDNS was now working reliably on both firewalls, updating the remote DDNS server whenever either dynamic IP address changed. That meant that the two firewalls could connect with each other by FQDN name, even if one or both IP addresses changed. We then configured the VPN parameters on the two firewalls at home, and VPN seemed to work fine.

When we got to our condo a few days later, we updated the firmware on the VPN firewall there, tested DDNS, and set up the VPN parameters. The firewall reported a successful VPN connection to our home network.

We then started testing the VPN link, and it finally worked the way we planned it two years ago. We had been testing a Buffalo TeraStation Live as a home media server, and we were able to access the TeraStation from the condo—we looked at pictures in our image archive, and played a stored video on the condo PC.

When we used our laptop PCs to access the home network through the VPN gateway, we were delighted to find that we could access our Windows NT domain. We could read and write files on our home desktop PCs and Windows servers, and could access the web server at home to browse our home intranet.

Maintaining the Condo PC with Remote Desktop

We finally had the condo-to-home mechanisms working properly, and we turned our attention to the home-to-condo mechanisms. Our condo is occupied by rental guests most of the time, and they sometimes report problems with the PC at the condo (Norton Internet Security has been a particular source of reported problems). Most of our guests are tech-savvy enough so Dave can talk them through diagnosing and repairing a problem over the phone, but it takes time away from their vacation.

What we really wanted was a mechanism for Dave to take control of the condo PC from home, and had long planned to use the "Remote Desktop" feature of Windows XP to do this. We had first encountered Remote Desktop when we played with the late-lamented Smart Displays four years ago; while it's a little clumsy, it does seem to do the job.

While we were at the condo, we enabled Remote Desktop and tested it from Dave's notebook PC. It worked just fine--although Dave found it a little spooky to see the Windows desktop of the condo PC on his notebook screen, with the condo PC's web browser pointed to our corporate intranet at home!

Back at home, we found that we could use VPN to access the condo's VPN firewall as if it were part of our local network. That allows to configure the remote firewall and make sure it's working properly.

Next we plan to test Remote Desktop through the VPN to make sure it works as planned.

Media and Communications

The remodeling project we started in August 2005 gave us a great opportunity to think about the wiring and equipment for present and future media and communications. See the next page for the start of phase 2.

Next: Phase 2: Media and Communications Needs