Novell Home

Configuring NIMS in a Private WAN Environment

Novell Cool Solutions: Trench
By Kevin Pidd

Digg This - Slashdot This

Posted: 26 Jun 2002
 

Parramatta Catholic Education Office services a K-12 educational system for Catholic primary and high schools throughout western Sydney and the Blue Mountains. These schools represent 40,000 students across approximately 75 campuses. Already using Groupwise for staff and teachers, they wanted to make e-mail available to students.

With only a limited number of centrally based IT staff they wanted an e-mail system that could be managed by school based IT staff. Skills available at the remote school campuses varied from only rudimentary IT skills to qualified CNE/MSCEs.

E-mail services were required for students to be able to communicate within the school and to and from the Internet. It was required that the students be able to access their e-mail from home but only if the school permitted it.

Currently the Parramatta CEO network is a star configuration with access from each campus back to Parramatta via a 64k ISDN link and through a firewall and a frame relay link to the Internet.

WAN structure

The firewall located at Parramatta provides Network Address Translation to private IP addresses. A BorderManager cache hierarchy is in place and each school has a BorderManager server located on their campus. The firewall DMZ houses a single NetWare web server and a Linux DNS server. All BorderManager servers are configured as DNS proxies.

All students and staff are contained in a single DNS tree and each campus is partitioned to hold its own objects. A read/write replica of each partition is maintained at Parramatta.

Filtering is in place to limit management traffic to the minimum required for NDS and time synchronization but during school hours the ISDN links are saturated with HTTP traffic. After school hours the ISDN links are hardly used.

NIMS was chosen as the student e-mail system as it was the simplest to manage by school staff and gave most administrative control to the school.

Choosing a NIMS architecture

The multiple standalone server model was chosen so that a NIMS server could be located at each school. A single messaging server could probably have the served the whole network but this would mean that students at a remote school campus would need to authenticate across the WAN to access their e-mail. This would have been difficult during school hours due to high utilization of the links. If the NIMS server was located at the school, authentication would occur on the local LAN. Students accessing e-mail from home would now authenticate across the WAN but this would mostly occur in the evenings and on weekends when the ISDN links were free of heavy traffic.

The multiple server model also causes SMTP traffic, between schools and the Internet, to traverse the ISDN links but SMTP is particularly well suited to slow links so this is not a problem.

Configuring for Internet e-mail

To be able to send Internet e-mail to and from each school, it was decided to create a child DNS domain for each school as they require student e-mail. The Parramatta CEO domain is

parra.catholic.edu.au

We added

schoolA.parra.catholic.edu.au
schoolB.parra.catholic.edu.au
schoolC.parra.catholic.edu.au

etc, as subdomains to named.conf and created the appropriate named files on the linux DNS server.

These DNS configurations pointed to servers on the internal network with 10.x.x.x addresses. These are private addresses that cannot be accessed by Internet hosts. To enable Internet e-mail to reach these servers, Sendmail was installed on the Linux DNS server. The MX records for each DNS domain were configured to point to the single public IP address of the DNS/Sendmail server. The mailertable file was then configured to forward mail for each domain to its appropriate NIMS server. The DNS/Sendmail server could do this because it had a static IP route through the firewall and was also the only host allowed to pass SMTP traffic through that firewall. Any SMTP traffic not destined for a configured DNS domain is simply discarded.

parra.catholic.edu.au smtp:[203.xx.xx.x21]
corp.parra.catholic.edu.au smtp:[10.xx.xx.x22]
schoolA.parra.catholic.edu.au smtp:[10.xx.xx.x23]
schoolB.parra.catholic.edu.au smtp:[10.xx.xx.x24]
schoolC.parra.catholic.edu.au smtp:[10.xx.xx.x25]

Sampler mailertable file

This configuration allows e-mail to be sent within the NIMS server and to and from other NIMS servers and to and from the Internet. It provides access to e-mail via Mod Web or POP or IMAP from behind the CEO firewall but not from the Internet.

Configuring for Internet access

The Modular Web Agent is the preferred method of accessing e-mail. This is particularly suitable for students that only have access to e-mail from a computing lab or a community laptop. No e-mail is downloaded from the server but accessed at the server via a browser. Some schools exclusively use Macintosh for the desktops and laptops so this overcomes any limitations introduced by Windows based clients.

Setting up a Reverse Proxy

The NIMS servers have internal 10.x.x.x. IP addresses and so cannot be accessed from the Internet. The solution to this problem was to assign a public IP address and install a BorderManager reverse proxy server in DMZ. This reverse proxy server maps a public IP address to the NIMS private IP address.

Adding a split DNS

Having a public IP address and a private IP address creates a new problem in that we only have a single DNS record for each server. The answer to this problem is to use a split DNS system that advertises different DNS information to the Internet than it advertises internally. BIND 9 can present different views for each DNS zone based on criteria scripted in named.conf. We needed to upgrade our Linux to support BIND 9. We then configured named.conf to return DNS resolutions containing the private IP address if the query originated from the 10.0.0.0 network else it would return the public IP address. This means two sets of DNS zone files are maintained.

schoolA.parra.catholic.edu.au
and
schoolA.parra.catholic.edu.au.internal

for example, but the external file only contains information required for Internet access. IP addresses of hosts that are only used internally are confined to the internal file.

At this point it was decided to create a secondary DNS server on the internal network to remove unnecessary load from the firewall. A NetWare DNS server was installed as a secondary DNS server and it derives its DNS database from the Linux DNS server. Internal DNS queries are usually resolved by this internal server.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell