Implement a Secondary Internet Connection

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

Small businesses are forced for many reasons, often economic, to assume a variety of risks. Being one of the major cost centers, IT is a department commonly required to bear a considerable portion of the peril. Looking back to 1995, small companies, if they used e-mail much at all, weren’t terribly worried if their systems intermittently malfunctioned. In 2004 the situation is perceived inversely: The network is business-critical. Things have changed, and the SMB community is beginning to adapt.


Commonly, small-business technology infrastructure is not well architected. For instance, topologically speaking, serial chains of single points of failure (SPFs) compound risks by causing “downstream” system-wide failures at the onset of trouble with any single link. In many cases, lack of adequate documentation extends outage times as technicians are forced to reverse-engineer systems before actual triage can begin. Further, the absence of outage policies such as poorly understood escalation paths could lead to confusion, even outright mistakes in decision-making processes.


Mitigating outage risk takes many forms. Better planning and architecture is one place to start. In concrete terms, implementing architectures that provide “escape” capability is becoming a more frequently recommended best practice.


Why the Dual-Gateway Objective?
This discussion narrows the topic of outage mitigation to examining the Internet gateway in a Small Business Server (SBS) environment. Tactically speaking, it’s not that the server proxy to the Internet is more vulnerable to problems or any less stable. Taking this tack is more of a strategic direction, when you assume that the ISP’s infrastructure is more robust. Therefore, working down this chain of SPFs leads directly to the LAN or Internet gateway. Adding an inexpensive hardware firewall to the network is cost-effective, mitigating the impact of and soft costs associated with unplanned SBS down- time. The total cost of assets can start from as little as $200, given certain other requirements.


A dual Internet gateway implementation provides a form of redundancy. Should an organization lose access to its SBS and thereby its Internet connectivity via ISA, access to the hardware Internet gateway remains unimpaired. In triage conditions, this can be critical in order to quickly provide an administrator with the tactical ability to download patches or software needed to repair the SBS and at the same time provide reasonable protection for the LAN from external threats.


Operational Continuity Effects
The selective criteria driving decisions on how to go about reducing outage risks should focus on providing operational workaround or even general continuity. Taking this position provides the higher potential for an appreciable ROI for the business owner. That said, we have worked on environments where the mitigations were taken solely to provide systems engineers with an infrastructure to work from in case of trouble. Security concerns are among the reasons this approach may be valid in certain circumstances. From our operational perspective, we use as our planning point of embarkation a scenario where the server will be down for an extended period. Under these circumstances, the objective will be for the firewall to supply basic network services in the interim. Depending on the hardware, these network services can include DNS, DHCP, VPN, NAT and terminal services.


The on-board network services enabled at the firewall permit rerouting the external (WAN) address to internal resources on the LAN (a Web server for instance). Also enabled is “secured” access out to collocated or hosted applications, ASP sites and backup e-mail services. Even hardware VPN services site to site (out to associated SOHOs) are possible.


Most often, triage-oriented domain name routing changes are accomplished by temporarily amending records or Web-forwards at the domain host. If an integrated approach is taken, domain host and name server maintenance capabilities should be considered. With the correct tools, an administrator can redirect Internet traffic in a matter of minutes.


The basic requirements for the dual gateway are that the customer is subscribed to a static block of public IP addresses and that at least one usable address is free. The only physical changes needed are the addition of an inexpensive switch, then a hardware firewall and recabling the public-facing NICs to the switch.


Project Thumbnail
The objective is to enable a functional “bareback” network in the absence of a functional Internet connection via SBS. But first, you must endeavor to do no harm. At the very least you should understand the operational schedule and arrange appropriate service windows. You will score points by recognizing and paying attention to change control protocol. If there are none, impose “lite” processes of your own.


Taking time to document the physical topology and network logical parameters is time well spent. In any case, you will need this information to configure the new gear. Completely review the DHCP configuration on the SBS—find the static reserve pool. This is the address space for things like printers, plotters and attendance clocks—ensure there are plenty of spare static addresses. The pool needs to be in the same subnet as the SBS; otherwise SBS services will break for client computers. If the pool requires amendment, review all of the network particulars in detail before developing change orders. Most, if not all, of these considerations can be dealt with either remotely or as precursors to actually making the site visit to install the equipment.


Preconfigure the new firewall independently on your bench. Do not connect the firewall to the LAN straight out of the box—it will likely cause DHCP services to stop on the SBS. While the firewall is on the bench, be sure to disable any other conflicting services. Set the firewall DNS entries to reflect those hosted at the ISP.
During a service window, after the SBS is backed up and the network is quiet, install and test the firewall on the LAN, confirming the DNS and basic functionality with its own onboard utilities. This usually entails disconnecting the WAN interface on the server from the WAN modem, installing a 4- or 8-port switch and the firewall and reconnecting the server. Realize that the firewall consumes an internal static IP from the SBS reserve list and a static IP address in the public space—ensure there are no conflicts. Burn the new firewall in for a few days before relying on the unit in a production sense.


Next, configure and test a workstation manually. From the network control panel, administer the network configuration and choose an address from LAN static pool. Be sure to reflect the firewall as the gateway and name server address (if supported by the firewall). You should be able to browse the Internet and run FTP, etc., without much trouble.


We sometimes have left an administrator’s machine on the LAN permanently configured with the firewall as the Internet gateway. This way, if there is a problem of some undetermined nature within the network and you’re unable to reach the server, starting triage from this box can yield a lot of information very quickly.


If this is a choice you make, be aware that the first DNS entry in the local network configuration for this machine should reflect the SBS address. This is important in case a host file exists, or other internal specialty DNS configurations are present in the local network. The second and third entries can be the firewall address and then the ISP name server, respectively. In a perfect world, when the higher-order servers are unable to respond to a lookup, the lower-order servers will still work.


You should perfor

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|


2 thoughts on “Implement a Secondary Internet Connection”

Comments are closed.