A Network tunnel lets someone physically on another network be on our network also, with IP addresses of ours. The IP address and/or subnet we assign are static, so tunnel users can run Internet servers on their own computers.
Originally tunnels were a way for our users moving to broadband providers to continue having static IPs from us. They have become a service we can sell to new and distant users.  One of our tunnel users is in New Zealand, a continent and an ocean away.
Tunnel performance is a common question. Our New Zealand user is kind enough to let us use his tunnel and server for a demonstration:
We support many types of tunnels for various client systems.
- Website demo of a tunnel between NetHeaven (upstate NY) and New Zealand.
Users of some tunnel types in unusual configurations can experience problems when accessing certain sites with broken path MTU discovery. This is rarely a problem, but it is something users of the affected tunnel configurations should be aware of.
A tunnel is just a special type of connection across a network. It is very much like the connections your browser makes to web servers, except tunnel connections are long term and are done in a way to make the tunnel resemble a direct wire connecting two computers.
Tunnel technologies were originally developed for building virtual private networks (VPNs), and occasionally that's what we do with them. However, we mostly use them for other purposes, such as providing static IP service to users on other physical networks.
A computer connected to our network with a tunnel has two IP addresses. One is on the network of the ISP being used for access, usually a broadband ISP (cable modem, DSL, or wireless). This IP address is used by the packets forming the tunnel and is the carrier IP address. The second IP address is one on our network and is the tunnel payload IP address, often called the virtual address.
In normal operation the carrier address is used for nothing except carrying the tunnel. Otherwise the computer operates as if it had only the one address on our network. Other modes of operation are possible but require some understanding of IP routing and network operation. For such users we provide a small subnet, not just a single IP address.
However, for most users running a tunnel is no more complicated than establishing a dialup connection. In fact, the on-screen action for the most common type of tunnel is almost identical to dialing in. No modem or phone line are involved though.
Fred Smith, a mythical NetHeaven user, has a business making handcrafted potbarrels. He has domain potbarrel.com and runs his own mail server mail.potbarrel.com. For some time his mail server has been dialing in once an hour to get his mail, but Fred would really like his mail server to be on the Internet all the time. He would also like a faster connection than dialup, but he is located where we can't provide him with broadband.
Fred gets a cable modem connection for its faster access, but his cable modem IP address isn't always the same. That would make it harder for remote mail servers to locate his mail server to deliver his mail, so Fred uses his cable modem connection to establish a tunnel from his mail server to our tunnel server. Our tunnel server gives his mail server a static IP address.
Fred leaves his tunnel up all the time. He is welcome to do that because an idle tunnel doesn't use up a phone line or any other limited resource.
Now Fred has achieved his goal; his mail server is always on the Internet, and his mail arrives instantly.
In addition, any time his cable connection is down his incoming mail automatically switches to our mail server, which holds it until Fred's cable connection and tunnel are back up, just as our mail server has always held Fred's mail waiting for his server to dial in.
Fred also has long had a virtual server business website here, but he would like his site to have services we don't offer. In particular, he would like to handle SSL secure-server credit card transactions. With his tunnel, Fred can run his own web server, buy an SSL certificate, and do his own transactions.
Fred's cable connection doesn't have a lot of outgoing bandwidth, and Initially he is a little worried about how this will perform across his tunnel. However, he has viewed our demonstration of a tunnel between New York State and New Zealand.
The demo also illustrates having a website from a slow server inlude images from a fast server. On examining the data on his website, Fred realizes that 98% of it is pictures of his potbarrels. These rarely change and are already on his site on our server. He can leave them there and move only the order processing and items that change a lot to his own server.
Fred can split his site up in other ways. For example, he can run a bulletin board tied to his web site, and he can have forms on his own web server send mail via his own mail server. He can create all the flexibility for himself that he wants.
(Fred knows that running his own server does not mean he can send spam. Our intolerance of spam applies to our entire network, including tunnels, not just to our server. Fred wouldn't send spam anyway though.)
On the side, Fred has a small additional business designing websites. These often involve exchanging data files with clients, and for this purpose Fred has an FTP site on our FTP server. He can continue to do this, or he can run his own FTP server using his tunnel. He also can split his FTP site similar to the way he split his website, keeping things that seldom change on our server for performance while using his own FTP server as a convenience for things that change frequently or are one-time transfers.
Fred's domain also is hosted here, meaning we provide DNS. For performance he will want our nameservers to continue to be nameservers for his domain, but he may want to control his own DNS. Fred could run his own nameserver wwith our servers acting as slave servers gettin their information on Fred's domain by transfering it from Fred's server.  To the Internet, our servers would be the authoritative servers, but to our servers Fred's own server would be the start of authority. For robustness we provide offsite nameservers as well.
For everything discussed above, Fred's NetHeaven charge is $30/mo. That includes his tunnel, his assigned static tunnel IP, his virtual server business website, his domain's email handling, his domain's DNS, and his FTP site. It includes an 8-address subnet as well, if he wants one.
It also includes dialup access, which we always include regardless of the main purpose of an account here. There's simply no reason not to include it.  Fred may never use it, but it will be there if he ever needs it, and he may find our toll-free access handy when he travels.
All NetHeaven accounts include one tunnel. In fact, we don't make any distinction between a tunnel account that includes dialup and a dialup account that includes a tunnel or, for that matter, a web hosting account that includes both dialup and a tunnel. Whatever the reason for buying a NetHeaven account, it includes all the features.
Average tunnel performance is considerably improved over what it was not long ago. The most common tunnel type, MPPE/PPTP (Microsoft VPN technology), improved with the introductions of Windows 2000 and Windows XP. (Performance of MPPE/PPTP can be pretty marginal with Windows 98 and Windows 95 clients.)
Tunnels to UNIX clients have always had good performance, but the use of two relatively new tunnel types have made them even better. CIPE and OpenVPN tunnels using UDP as the transport protocol are not only fast, they are more robust in the face of packet loss. CIPE tunnel speeds are virtually indistinguishable from the underlying wirespeed, and OpenVPN tunnels sometimes are actually faster when compression is used.
CIPE and OpenVPN tunnels, when used to connect a local network rather than just a single computer, can result in problems accessing remote servers with broken path MTU discovery. This is the same problem faced by many users with PPPoE-based DSL access, but it is less common for tunnel users because tunnels are used for different putposes. When it does occur, the same workaround used by PPPoE DSL users can deal with it. However, in our opinion, users should not have to work around server problems.
We support quite a range of tunnel types. They are described on our tunnel types page.
The only way to really know how a tunnel will work for you is to try one, which you can do for for a month for free. If you'd like to try a tunnel, call our toll-free number 1-800-910-6671 to sign up for a free trial, or send email to firstname.lastname@example.org.