You are on page 1of 7

LinkProof Quick Start Guide

Table of Contents
1 INTRODUCTION ..................................................................................................................................3
2 SIMPLE SCENARIO – SINGLE LINKPROOF WITH EXTERNAL SOA ............................................3
3 MODIFYING DNS ON THE EXTERNAL SOA ....................................................................................4
3.1 REFERRING THE A RECORD RESOLUTION TO LINKPROOF ...................................................................... 4
3.2 ADDING A REDUNDANT (BACKUP) LINKPROOF DEVICE ........................................................................... 5
4 COMPLETE SETUP – REDUNDANT LINKPROOF DEVICES WITH MULTIPLE INTERNAL
SOAS ...........................................................................................................................................................6
1 Introduction
To provide inbound load balancing and redundancy, LinkProof uses DNS resolution to control the flow of
incoming traffic. This document describes how to configure LinkProof with DNS. It assumes that:
• You are familiar with configuring LinkProof ’s interface addresses and Next Hop Routers. For more
information on setting up LinkProof, refer to the LinkProof User Guide.
• You have a working knowledge of DNS. For more information on DNS, refer to DNS and Bind,
published by O’Reilly & Associates.
• You have familiarity with setting up redundancy.
Although LinkProof has a built-in DNS agent, it is not a full DNS server. It cannot answer queries for NS
records, CNAMES, or MX records. Only record requests that match URLs listed in the LinkProof DNS >
Name to Local IP table receive a response.

2 Simple Scenario – Single LinkProof with External SOA

This section describes a typical (simple) scenario for configuring LinkProof with an external SOA (see
Figure 1).

COMPANY.COM has one internet link, ISP1. This ISP currently answers all requests for
www.company.com. With the installation of a new internet link, COMPANY adds a LinkProof device.

Note: The examples in this document use non-routable addresses. An actual installation would require
public, routable addresses.

Figure 1 Single LinkProof with External SOA

Page 3
To set up a single LinkProof device with external SOA

1. Set up static NAT addresses for the Web server using the following LinkProof panes:

• LinkProof > Global Configuration > Enable Smart Nat


• LinkProof > SmartNAT > Static NAT > Insert rows

Because LinkProof handles the public addresses in this example, use the following static NAT
settings:

STATIC NAT ROUTER LOCAL SERVER


192.168.1.100 ISP1 172.16.1.100
10.1.1.100 ISP2 172.16.1.100

2. Configure DNS to Local IP using LinkProof > DNS > Name to Local IP.

URL LOCAL IP ADDRESS


www.company.com 172.16.1.100

Note: Use the internal address of the server, not the static NAT addresses.

This enables LinkProof to answer queries for www.company.com, and lookups directed to the
LinkProof device interfaces return static NAT addresses (such as 192.168.1.10 and 10.1.1.10).
Because most of the world will be querying ISP1’s DNS server, you have to modify the zone file so
that the requests go to the LinkProof device.

3 Modifying DNS on the External SOA


The original zone file for COMPANY.COM on ISP1’s DNS server might look like the following example:

COMPANY.COM
@ IN SOA ns.company.com
IN MX mail
WWW IN A 192.168.1.100
MAIL IN A 192.168.1.101

3.1 Referring the A Record Resolution to LinkProof

Make the following changes to the zone file:

COMPANY.COM
@ IN SOA ns.company.com
IN MX mail
WWW IN NS linkproof1
WWW IN NS linkproof2
MAIL IN NS linkproof1
MAIL IN NS linkproof2
LINKPROOF1 IN A 192.168.1.10
LINKPROOF2 IN A 10.1.1.10

Page 4
This delegates the final answer to LinkProof. Initially, the client queried the DNS server and received the
IP address. Now, the client queries the DNS server, which tells the client to query the LinkProof device
at one of the ISP interface addresses. The client then queries the LinkProof interface IP address, and is
given the static NAT address for www.company.com, choosing the best route to establish the connection
based on load balancing or proximity.

Two NS records are used and returned to the client because the external DNS server is not aware if
either of the links is down. Providing both ISP interfaces for LinkProof as A records is necessary to
properly delegate the query. The SOA can be made to round robin the NS records it provides so that
DNS queries are actively sent to each ISP.

Note: In Windows 2000, adding an NS record is called “New Delegation.”

The following is a summary of the query flows in this configuration:

Client (to ISP): Where is www.company.com?

ISP DNS: Does not know, ask LinkProof 1.company.com or LinkProof 2.company.com.
(This is the delegation)

Client (to ISP): Where is LinkProof 1.company.com?

ISP DNS: 192.168.1.10

Client (to LP1): Where is www.company.com?

LinkProof 1: 192.168.1.100

The same zone file would apply to multiple DNS servers, so that COMPANY.COM can register ISP1’s
DNS server as well as ISP2’s DNS server as the SOA (thus eliminating an additional point of failure).

3.2 Adding a Redundant (Backup) LinkProof Device

Adding a backup LinkProof is straightforward and does not require many changes to the configuration as
described in Section 3.1 Referring the A Record Resolution to LinkProof. The changes entail duplicating
on the backup device
• the static NAT addresses that exist on the primary device (setting them to backup mode)
• the DNS to Local IP table.

To add a redundant (backup) LinkProof device

1. Create a DNS virtual IP address. This is an additional, unique IP address for each ISP subnet. On
the primary device, you create the following entries using LinkProof > DNS > DNS Virtual IP:
COMPANY.COM
@ IN SOA ns.company.com
IN MX mail
WWW IN NS linkproof1
WWW IN NS linkproof2
MAIL IN NS linkproof1
MAIL IN NS linkproof2
LINKPROOF1 IN A 192.168.1.11
LINKPROOF2 IN A 10.1.1.11
Page 5
2. On the backup device, the same entries are created, but the mode is set to backup. The zone file
shows that the LINKPROOF 1 and LINKPROOF 2 IP addresses are now n.n.n.11 instead of
n.n.n.10.

4 Complete Setup – Redundant LinkProof Devices with Multiple Internal


SOAs
If COMPANY.COM requires adding a second firewall and bringing the SOA in-house, the firewalls
themselves run DNS services, and DNS requests should be load-balanced between them.

Note: This also applies if the DNS servers are behind a DMZ.

Figure 2 illustrates the configuration for such a network. This configuration assume the firewalls answer
DNS on a unique IP address, rather than their interface addresses, and NAT traffic from the internal LAN
to a unique IP address. In this way, LinkProof can differentiate outbound LAN traffic from inbound DNS
or Web requests. While it is possible that all traffic (in and out) can be translated to the firewall’s
interface address, such a setup is covered separately in this document.
Figure 2 Redundant LinkProof Devices with Multiple Internal SOAs

The following are the interface, DNS, and NAT settings for this configuration:

Name Interface Address DNS Address NAT address


FIREWALL-A 172.168.1.30 172.168.1.40 172.168.1.50
FIREWALL-B 172.168.1.31 172.168.1.41 172.168.1.51

To configure a redundant LinkProof device with multiple internal SOAs

1. Create a Virtual IP rather than the static NATs configured in Section 3.1 Referring to A Record
Resolution to LinkProof. From the LinkProof > Virtual IP pane, define a single, private IP address
(172.168.1.100) which is mapped to the DNS addresses on each firewall (172.168.1.40 and
172.168.1.41).
2. Create a Static NAT address for each ISP subnet, and use the Virtual IP as the local server using
the LinkProof > Smart NAT > Static NAT pane. These two static NAT entries are registered as the
SOA name servers with Network Solutions.

Note: If you are using internal DNS servers, you need to modify the LinkProof proximity parameters.
Because an internal DNS server queries LinkProof for the A record, you configure LinkProof to
ignore proximity calculations to these servers (otherwise, LinkProof calculates proximity for the
internal subnet).

When DNS requests from the Internet arrive at the static NAT addresses, they are load balanced
between the two firewalls (using the same algorithm that is used for NHR load balancing). Each firewall
is configured with a zone file similar to the Section 3.1 Referring to A Record Resolution to LinkProof, so
that the handling of the A record (the final, destination IP address) is referred to LinkProof’s interface (or
virtual DNS address).

Page 6
Page 7

You might also like