Yesterday I made the decision (read: mistake) to update my Netgear DG834G router (hardware v4, firmware v5.01.09) to firmware v5.01.14 – and, as is the way with these things, it brought trouble.  After the upgrade I couldn’t reach www.nikrivers.com from the LAN side of the router.

The problem is caused by the way the router handles traffic coming from an internal IP address and destined for the WAN (i.e. external) IP address.  In this situation it requires that the router first transfers the traffic from the internal network to the external network, and then immediately passes it back whilst applying any firewall or routing rules that are relevant to incoming external traffic.

This behaviour is called ‘NAT loopback’, and it seems the vast majority of routers built for the home market have this ability turned off, or do not have the ability at all.  It can be a big problem if you host a website and wish to access that same website using its domain name.  The domain name will resolve to the WAN IP address of your router, and any traffic headed there (such as an HTTP GET request on port 80) from the internal network will be ignored by the router.

There are a few ways to solve this, but none of them are ideal.

1. Use the server name instead of the domain name to access your website
2. Modify the list of known network hosts on each client to point your domain name straight to the server in question.
3. Run your own DNS server, using a view to return the server’s local IP address to requests for your domain name originating from your network.

Of course, the situation gets more complex if you’re also using your router to send TCP traffic on port 80 to your webserver and UDP traffic on port 8668 to a game server.

The solution is to get NAT loopback working on your router.  With some routers, such as the Touchspeed 535 as provided by Be Broadband, this feature can be enabled using a simple CLI command.  For other routers, such as the Netgear DG834G, it’s not quite so easy.

For the purposes of this post I’ll assume the internal network is on the 192.168.0.x range, the router is 192.168.0.254, and the web server is 192.168.0.1.  You will need to modify these IP addresses according to your own network setup.

The first thing to do is to enable debug mode on the router.  Simply go to http://192.168.0.254/setup.cgi?todo=debug and you’ll be rewarded with an appropriate message, “Debug Enable!”.  Nice.

Now connect to the router with ‘telnet 192.168.0.254′ to gain access to the router’s cut-down installation of Linux.  All that is required is to add one additional entry to the router’s iptables (which is a standard Linux feature; Google it or more info).  Type the following, amending any IP addresses according to the network setup:

iptables -t nat -A POSTROUTING -d 192.168.0.1 -s 192.168.0.0/24 -p tcp –dport 80 -j SNAT –to 192.168.0.254

This adds a rule to the POSTROUTING chain on the nat table which applies to all TCP traffic on port 80 (HTTP) coming from the private network and headed to the router.  The rule redirects the traffic to the server, and then processing jumps to the SNAT chain.

If the server is more than just a simple web server, such as an NTP server or mail server as well, the above step needs to be performed (changing the -p and –dport parameters accordingly) for each port and protocol combination you require.  Alternatively, those parameters could be omitted altogether, which will allow all traffic types on all ports through:

iptables -t nat -A POSTROUTING -d 192.168.0.1 -s 192.168.0.0/24 -j SNAT –to 192.168.0.254

If you do this, I recommend you run a firewall on your server, with only the appropriate ports opened.

There is more information in section 10 of Rusty Russell’s Linux 2.4 NAT Howto.

Unfortunately, the iptables change isn’t retained when the router restarts, so it is necessary to go through the process every time – which is a pain in the backside.  Fortunately, however, the Netgear support website has a download link for previous firmware versions, so I downgraded my router back to firmware v5.01.09 and everything worked fine again–including NAT loopback–with no iptables hack required.

A robust solution with DNS

Simply put, proper DNS is the best way to get around a router’s lack of/poorly implemented NAT loopback.

If you have the resources to host a website then you most likely also have the resources to host a DNS server for your internal network.  Simply create an ACL list describing all the clients on your internal network (probably as simple as specifying the CIDR block for your network, maybe something like 192.168.1.0/24).  Then create a view whose clients match that ACL, and define that view as a master DNS server for your website domain.  You then need to create a zone file for that domain – but instead of using an external IP for your webserver, use its internal IP.

All requests for other domains will be routed to the DNS forwarders, but requests for your webserver’s domain will be handled locally, and internal IP addresses will be returned.

The benefit is that you avoid traversing your gateway router to simply come back inside your network.  It doesn’t make sense that you rely on your gateway router to access a website within your own network.  In addition, the firewall on your router can be hardened to a much greater degree: for example, you needn’t leave FTP ports open on your router if you’re only connecting locally.  Or, to put it another way, you’re likely going to want to give yourself more access to your server than you want to give to the outside world; configuring a router’s firewall rules for this kind of conditional logic is simply asking for trouble.

Much like being able to tell (but not necessarily care) when I’m boring someone with a particular conversation, I use website analytics to see where website visitors come from, what they look at, and how frequently they return. Yes, some people come back. In fact, most people do. And the most popular pages are actually the NSLU2 guides which describe how to configure a very small, low-power Linux server based on a Linksys NAS device.

I have no delusions about the overall importance of nikrivers.com; nobody knows about it, it doesn’t appear very high up in any Google results unless you search for my name, and even my mum keeps forgetting how to find it (though she also has to keep asking me how to find the Internet, because “it’s gone from my desktop”).

That said, 101 different people have visited my NSLU2 guides in the last 20 days alone, about a third of which are visitors who have never been to my website before. Even after Linksys has discontinued the NSLU2, it still remains popular as a web and mail server.

Many thanks go to Raymond Mentjens (www.mentjens.nl) for his help in fixing a few (actually, quite a few) errors, and for all his feedback while he followed this article.  He has also created his own guides in Dutch – so if you read Dutch better than English, you may want to take a look at his site.

Versions

This how-to guide was updated in May 2009 for compatibility with the following package versions:

• Postfix 2.3.6-3
• Dovecot v1.2.0.beta1-2

This how-to may also work with previous versions, but may require slight changes with respect to paths – for example, previous versions of Dovecot installed dovecot.conf to /opt/etc/dovecot.conf, but the latest version installs it to /opt/etc/dovecot/dovecot.conf.

Install Postfix

Issue the command:

ipkg install postfix

The Postfix installation automatically creates a new group called maildrop; check maildrop is created:

more /etc/group

If the group is not there, you will have to create it yourself. Also note that it might suddenly disappear, requiring you to add it manually. For both eventualities, see the notes below.

Now we’ll need to start editing the configuration files to customise Postfix to our needs.

vi /opt/etc/postfix/master.cf

Add -v to the end of the line that specifies the smtp daemon so it reads smtpd -v (the line you need to modify is the first in the table, just beneath several lines of comments). This enables verbose output to the log file, which you should monitor in a separate PuTTY window using the following command:

tail -f /var/log/messages

This will help give you an idea of when and why problems occur. Note that tail sometimes hangs, and if you don’t see log output when you think you should then it may be time to abort tail (with CTRL+C) and restart it.

Let’s edit the main Postfix configuration file:

vi /opt/etc/postfix/main.cf

And provide our own values for the following parameters:

myhostname = <your slug’s host name – eg. mail.yourdomain.com>
inet_interfaces = all
proxy_interfaces = <your external ip address>
mynetworks_style = subnet

Before Postfix can be started, it needs to know where to deliver mail that is addressed to users such as root, postmaster, and other pseudo-accounts. The file that contains this mapping is /opt/etc/postfix/aliases. Edit the file:

vi /opt/etc/postfix/aliases

Uncomment the root alias, and provide the address where mail to root should be delivered (using your own address is a wise choice):

# Person who should get root’s mail. Don’t receive mail as root!
root: <your email address>

Now the file should be copied to /opt/etc/aliases, and turned into a hash file that postfix can read, using the newaliases tool. The output file is /opt/etc/aliases.db:

cp /opt/etc/postfix/aliases /opt/etc/aliases
newaliases

Now start Postfix, keeping an eye on your second PuTTY window for any messages Postfix might emit.

/opt/etc/init.d/S69postfix

At various points you’ll need to change Postfix configuration, and Postfix will need to reload those changes. You can do this with:

/opt/etc/init.d/S69postfix restart

Or, if you don’t like to keep stopping and starting it, you can simply issue:

postfix reload

Testing Postfix

Use telnet to connect to your slug’s smtp port:

telnet <slug’s host name or IP address> smtp

Make sure you can send mail, by having the following conversation with Postfix:

220 mail.yourdomain.com ESMTP Postfix
mail from:some_user
250 2.1.0 Ok
rcpt to:<an external email address you can check>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject:Test Mail 1
This is a test message.
.
250 2.0.0 Ok: queued as EF7E4208003

When you check the email address to which you sent your test mail, you’ll see it comes from some_user@mail.localdomain (or something similar, according to what you put in your postfix configuration file), and is generally badly formed. Don’t worry, a proper email client will provide the necessary data, whereas we only provided the bare minimum. Note that some mail servers may reject this test mail because the sender’s address is malformed (i.e. the domain doesn’t exist). In this case, you will need to use a valid-looking email address (such as some_user@test.com) or even your own address.

If you don’t receive the test email, you can check the postfix queue to see whether an error occured:

postqueue -p

And also delete any failed/stuck messages:

postsuper -d <queue_id>

On a side note, it’s a good demonstration of how easy it is to send untraceable spam. The IP address in the email header is the only indication of where the email originated; but this can be faked quite easily.

Finalise Postfix Configuration

There’s already a convenient user and group (both called mail) configured by the system which Postfix can use to manage the mail store, so all we need to do it find out the uid and gid.

grep mail /etc/passwd

The 3rd and 4th elements of the output are the uid and gid respectively. Write them down; we’ll need them in a minute.

We need a disk location for storing users’ mail; I chose /var/spool/vmail, which seems as good as any. The following script creates the initial directory structure, along with the additional directories for user@yourdomain.com mail storage. The /var/spool directory didn’t exists on my system, so rather than checking to see if there was a more logical/suitable storage location elsewhere, I simply created it with brute force.

mkdir /var/spool
cd /var/spool
mkdir vmail
cd vmail
mkdir yourdomain.com
cd yourdomain.com
mkdir user
cd user
mkdir new cur tmp

Now the new directories need the right owners and permissions: root owns /var/spool (and gives full permission to everyone), whereas the vmail directory (and everything within it) is owned by mail, and only mail (and members of the mail group) have permissions.

chmod ugo=rwx /var/spool
chown -R mail:mail /var/spool/vmail
chmod -R ug=rwx,o= /var/spool/vmail

You can double-check this afterwards:

ls -l -R /var/spool/vmail | more

In order to use Dovecot’s SMTP AUTH mechanism, Postfix needs to know where Dovecot’s daemon socket is located. Currently it isn’t located anywhere, so that needs to be fixed:

cp /opt/var/spool/postfix/private/anvil /opt/var/spool/postfix/private/auth
chmod go=rw /opt/var/spool/postfix/private/auth
chown mail:mail /opt/var/spool/postfix/private/auth

Time to edit the postfix config again.

vi /opt/etc/postfix/main.cf

The config file isn’t set up with default values for virtual hosts, so these need to be added. We also tell Postfix that we’re using Dovecot for SMTP AUTH, and point it to the socket location we just created (relative to the queue directory). Note that as soon as we tell Postfix about the socket, it will grumble and complain (and fail to run) because Dovecot hasn’t created the socket yet. We’ll do that shortly.

# LOCAL CONFIG
local_recipient_maps = $virtual_mailbox_maps
# SMTP AUTH
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
# VIRTUAL HOSTS
# Config for virtual domains that are hosted by this server.
virtual_mailbox_domains = /opt/etc/postfix/virtual-hosts
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/opt/etc/postfix/virtual-maps
virtual_uid_maps = static:<mail uid>
virtual_gid_maps = static:<mail gid>
virtual_minimum_uid = <mail uid>

Replace <mail uid> and <mail gid> with the uid and gid you noted earlier on.

Now we are left with two files to create. The file /opt/etc/postfix/virtual-hosts should contain a list of all the domains you are hosting, one on each line. The file /opt/etc/postfix/virtual-maps defines the storage location for your mail users.

virtual-hosts:

yourdomain.com

virtual-maps:

you@yourdomain.com yourdomain.com/you/
me@yourdomain.com yourdomain.com/me/

The second column is the storage path, relative to $virtual_mailbox_base. So mail for you@yourdomain.com will be stored in /var/spool/vmail/yourdomain.com/you. The trailing slash in the file is important, and specifies that the Maildir format of mail storage is to be used, as opposed than mbox. Maildir stores each mail as a separate file, which makes more sense to me than mbox, which stores all mail in one file.

We now turn /opt/etc/postfix/virtual-maps into a hash file, and give Postfix read permission:

postmap /opt/etc/postfix/virtual-maps
chmod o+r /opt/etc/postfix/virtual-maps.db

You can now restart the server so your changes take effect, but bear in mind that the smptd process will crash if you try to connect to it – because the Dovecot socket doesn’t exist yet.

/opt/etc/init.d/S69postfix restart

Install Dovecot

ipkg install dovecot

First, a warning: Dovecot caused more trouble than anything I’ve done with the Slug so far. It’s easier to configure than Postfix, but easier to mess up, too!

For starters, you will definitely want to edit the Dovecot config to turn logging on:

vi /opt/etc/dovecot/dovecot.conf

At the start of the file insert the following parameters (we’ll be removing them again later):

log_path = /var/log/dovecot
info_log_path = /var/log/dovecot
auth_debug = yes
auth_verbose = yes

Let’s tell Dovecot where mail can be found. Edit the mail_location parameter as follows. This tells Dovecot that mail for you@yourdomain.com can be found at /var/spool/vmail/yourdomain.com/you. Note that in older versions of Dovecot this setting was default_mail_env.

mail_location = maildir:/var/spool/vmail/%d/%n

Now we want to tell Dovecot about the STMP AUTH socket it needs to create. Find the auth default configuration block (about 80% of the way through the file) and add/edit the following configuration block inside the auth default block.

socket listen {
client {
path = /opt/var/spool/postfix/private/auth
mode = 0660
user = mail
group = mail
}
}

This tells Dovecot what we’ve already told Postfix – now Dovecot knows to create the auth socket, and put it in the right location. We now need to tell Dovecot which users are allowed to use our SMTP server and where it can find their passwords. The relevant sections, passdb and userdb, already exist in the auth default block, and should be edited as follows.

passdb passwd-file {
args = /etc/passwd-mail
}

userdb static {
args = uid=<mail uid> gid=<mail gid>
}

The passdb section tells Dovecot to use a passwd-like file located at /etc/passwd-mail to check users’ passwords. The userdb section is usually used in a similar way to look up valid email users – but since we don’t need another look up, we can use the ‘static’ mechanism, in which case Dovecot will rely on the passdb section for both valid users AND passwords.

Don’t forget to replace <mail uid> and <mail gid> with the uid and gid of your mail user and group. If your uid is less than 500 (which, if you used the built-in mail account, it is) you will need to change the first_valid_uid value in the config file to something less than or equal to the uid you are using.

The last thing involving the configuration file is to tell Dovecot which protocol we want clients to be able to use. By default, Dovecot supports only IMAP – but I prefer POP3.

#protocols = imap imaps
protocols = pop3

IMAP has some significant advantages over POP3, providing an Exchange-like environment for email, but it also has its disadvantages. If you’re happy to store all your email locally, you’re only going to connect from a single client, and prefer ISP-like email, the more common POP3 should be just fine.

Now we need to create the passwd-like lookup file.

vi /etc/passwd-mail

It’s content will be of the format <username>:{encryption_scheme}password, for example:

you@yourdomain.com:{plain}yourpassword

The {plain} directive denotes that the password is in plain text; this overrides whatever encryption Dovecot might be expecting – DES in this case (the same as you’d find in /etc/passwd). If you DES-encrypt your password before putting it in /etc/passwd-mail you do not need an {encryption_scheme} directive.

By default, the dovecot-auth process runs as user admin, which is a member of the group administrators. You can change this by editing dovecot.conf, but it is not necessary. The admin user needs read privileges on the mail password file, so give this permission to the group to which user admin belongs:

chown root:administrators /etc/passwd-mail
chmod g=r /etc/passwd-mail

Now you’re ready to start Dovecot. You may like to open a separate session on your Slug and run tail -f /var/log/dovecot to monitor what’s going on:

/opt/etc/init.d/S90dovecot start

If this produces errors, double-check the edits you made to /opt/etc/dovecot/dovecot.conf – a common problem is the mismatching of curly braces { and }.

Testing Dovecot

Now use telnet to connect to Dovecot on your slug:

telnet <slug’s host name or IP address> pop3

You can have the following conversation with it:

+OK Dovecot ready.
user you@yourdomain.com
+OK
pass wrongpassword
-ERR Authentication failed.
user you@yourdomain.com
+OK
pass yourpassword
+OK Logged in.

Great. You now have a working email server which offers SMTP without being an open relay, and provides POP3 to the user(s) you specified.

If Dovecot crashes when you authenticate, and logs “Panic: POP3(you@yourdomain.com): Trying to allocate 0 bytes“, you have found a kown bug with the Dovecot 1.2 beta 1 release (the latest release that is available through ipkg). Although this doesn’t prevent you from using Dovecot, most email clients will complain that the connection to the POP3 server was prematurely terminated. A patch is available at http://hg.dovecot.org/dovecot-1.2/rev/22d70947597c, but I have not had a chance to try it.

Finally

Don’t forget to turn off verbose logging for Postfix and Dovecot. For Postfix, remove the ‘-v’ smtpd parameter from /opt/etc/postfix/master.cf, and for Dovecot remove the first four lines of /opt/etc/dovecot/dovecot.conf (log_path, info_path, auth_debug and auth_verbose).

Limitations

The one big limitation with this set up is that the administration of mail users involves a lot of work. Every time you add a user you must create the relevant entry in virtual-maps, create the user’s mail delivery directory structure, and set permissions. The mitigation against this drawback is that you (probably) won’t be using your Slug as a mail server for more than a handful of email addresses – any heavier use would probably require a more significant investment, and hence more powerful tools.

Notes

Group ‘maildrop’ disappears
It seems that, at some point, the maildrop group ‘disappears’ from /etc/group. It may be something to do with the fact that /etc/group is a symbolic link to /share/flash/conf/group, and thus may be more closely-managed by the Slug than it appears. Regardless, it causes SMTP clients to be unable to connect (because Postfix fails to start), and Postfix emits an appropriate message to /var/log/message.

This can be resolved by manually recreating the appropriate entry in /etc/group for maildrop:

maildrop:x:69:

Fortunately, it seems that this is only required once.

Using your ISP’s SMTP server
Some ISPs may require that any email you send is relayed through their SMTP server; in this case you will likely need to add the relayhost parameter to your main.cf as well (although this wasn’t necessary in my case). Documentation for this parameter can be found on the Postfix website at http://www.postfix.org/postconf.5.html#relayhost. Explicit authentication with your ISP’s SMTP server is usually not required as long as you are connected to the Internet via that ISP’s connection (either dial-up or always-on).

Encryption of stored passwords
When installing and configuring Dovecot, I store email users’ passwords in plain text. If you want to store passwords in an encrypted format, see http://wiki.dovecot.org/Authentication/PasswordSchemes for an explanation.

Next Steps

Firewall
If you have a firewall or NAT between your Slug and the outside world (which is highly recommended) and you want to access your email from anywhere, you will need to configure your firewall or NAT to forward ports 25 (smtp) and 110 (pop3) to your Slug.

Of course, if you open up your email server to the rest of the world, you may want to make sure it can’t be abused. Go to http://www.abuse.net/relay.html, provide your external IP address, and let it test your email server for being an open relay.

Date/Time
It’s a good idea to keep your Slug’s time accurate so that the mail server can timestamp email correctly. This can be done by running an NTP client, which will synchronise the Slug’s time with reliable time servers around the world, or by running an NTP server, which will synchronise the Slug’s time AND allow you to synchronise your network computers’ time with the Slug.

Due to a glitch in the Slug, this isn’t as straight-forward as it could be – but it’s not beyond anyone with enough patience to work with vi.

Detailed instructions are here.

SSL/TLS
These instructions give you a working email server, but all authentication is performed using plain text. That means that anyone using a network sniffer in the right place at the right time could steal your usernames and passwords as you transmit them to the server.

Rather than configure authentication mechanisms that prevent this (and which, to be honest, look difficult to configure), we can encrypt the whole of the communication between client and server using SSL and TLS.

Detailed instructions are here.

Useful Links

http://www.postfix.org/
http://www.dovecot.org/
http://www.nslu2-linux.org/
http://www.howtoforge.com/linux_postfix_virtual_hosting
http://www.howtoforge.com/linux_postfix_virtual_hosting_2

If this information was useful, please leave a comment to let me know!