As we mentioned in our previous publication about running SMTP over an IPSEC tunnel, running your own SMTP server to collect and relay mail for your domain has some nice advantages over using a third party or ISP mail server.

However, reliable mail delivery via SMTP requires a machine connected 24 hours per day to a high quality internet connection with guaranteed uptime, as well as a publicly accessible static IP address which is not listed on any widely used blacklists. For this, and other reasons, running your own SMTP server on a typical residential broadband connection is usually not a good idea. Since virtual servers are now available at low cost, running your own SMTP server in a VM makes a lot of sense, as the prerequisites we've just mentioned are much easier to obtain.

Setting up an SMTP server in a VM is not particularly difficult, although first time users might encounter a few difficulties along the way. Outbound mail doesn't really pose a problem, as you can easily connect to your own remote SMTP server from any IP to submit mail for relaying.

The whole process of bringing up and maintaining the tunnel should be opaque to the SMTP server, which simply delivers to the assigned IP address regardless of the fact that it is actually a private IP address rather than a publicly accessible one. If mail delivery is attempted whilst the tunnel is down, the VM just sees a network error, and mail is held for the next delivery attempt.

In this guide, we'll be setting up a tunnel using the wireguard protocol. This will be between two machines both running OpenBSD 7.0, a local machine, and a VM hosted at OpenBSD Amsterdam. The principles should be easily applied to other hosting services and even other operating systems, but the specific examples given here are primarily aimed at users of OpenBSD.

Everything we need is included in a full installation of the OpenBSD base packages. That's to say, nothing whatsoever from the ports tree is necessary to set up SMTP delivery over a wireguard tunnel.

Of course, SMTP isn't the only useful protocol that we can tunnel from the remote VM using wireguard, and many of the principles that we're explaining here are equally applicable to other protocols.

The diagram above shows the desired arrangement of our three machines, two physical machines locally and a remote VM. The hostnames corresponding to the assigned IP addresses are also given. Note that only the five entries listed at the top right need to be included in the public DNS. All of the other hostnames can simply be included in the local hosts file, as they are only used locally.

With the preamble out of the way, we can now concentrate on configuring the new setup.

Since the IPs for the VPN endpoints are going to be bound to virtual wg devices rather than physical network adaptors, the first step is to create these new wg devices. Eventually we will do this automatically on each boot by creating a configuration file /etc/hostname.wg0, but for the initial setup we'll use ifconfig interactively because when we generate and set each private key, we'll need to obtain the corresponding public key in order to configure the other peer.

Note that we only set the wgendpoint option on the local peer. We can't set it on the remote VM because the connecting machine has a dynamic IP. This means that the remote VM cannot establish an inbound SMTP connection to the local peer until the local peer has first brought up the tunnel and informed the remote VM of it's current dynamic address.

Finally, we just need to set the local peer IP address for each wg interface. This is again done using ifconfig in the same way as an address is set for a physical interface.

At this point, the wireguard interfaces on both peers are configured. Now we can move on to testing the connection, and making the configuration more permanent so that it will survive over re-boots.

Note: In testing, we have occasionally observed an ifconfig process become stuck in the wf_ifq state when a wireguard virtual interface is destroyed, which has required a forced re-boot to terminate it.

We can bring the tunnel up and do an initial test of connectivity via it simply by pinging the remote VM from the local peer:

Of course, we can also ping the local peer from the remote VM:

With this option set, we can observe keepalive packets being sent on the physical interface:

Note that since the keepalive packets are a kind of out-of-band communication, they don't generate any traffic on the wg interface itself.

Now that our wireguard tunnel is, (hopefully), working correctly, we can move on to configuring smtpd.

Since our smtp connections will be encrypted by the wireguard protocol, we could simply run the plain text smtp protocol over the VPN and still avoid third parties from intercepting the data. An smtp over TLS configuration is more complicated, so if you want to start by configuring plain text smtp over the tunnel just to see it all working, fair enough.

However, there are several reasons to prefer not leaving this as a production setup, and to set up a propper smtp over TLS configuration instead. Firstly, if the opportunity to obtain a publicly accessible static IP for the local machine becomes available in the future and therefore using a wireguard tunnel becomes un-necessary, it's convenient to have a TLS-based setup already fully tested and working so that the switch can be made immediately. Secondly, future mis-configurations or even as yet undiscovered bugs in the wireguard kernel code could theoretically result in smtp traffic being sent over the internet in such a way that the plaintext is recoverable. If our SMTP session uses TLS within the tunnel, the chances of this happening are greatly reduced.

We specify our IPv6 address multiple times in ips_out, because otherwise smtpd will frequently fall back to using IPv4 when talking to a dual-stacked host. Since there is no obvious way to force a preference for IPv6 in these cases, specifying the IPv6 address multiple times manually at least helps to increase the frequency with which IPv6 is used.

Warning messages generated as per the configuration of bounce warn-interval will also intentionally fail with a similar error.

In this case, we will probably also want to check that bounce warn-interval is set to a reasonable value based on the expected level of connectivity between the two peers, to avoid sending excessive warning messages just because the VPN link is down at certain times of the day.

The credentials file on the remote VM, namorar.example.com, simply consists of a username and an encrypted password:

The encrypted password string used above can be generated using smtpctl:

The same file on the local mail relay, carinho.lan, contains the username and unencrypted password, prefixed by an arbitrary label, which in this case is the same as the username:

The remote VM has four identities that we need to create keys and certificates for, smtp.example.com, mx1.example.com, mx2.example.com, and vpn1.example.com.

The generated key will be written with permissions 0644, so we change this to 0640. Note that since it is created in a directory that is neither world nor group readable, we don't need to concern ourselves with the key file itself being momentarily world-readable between it's creation and the change of permissions.

Next, we generate a certificate signing request:

With the certificate signing request, we can now generate the actual self-signed certificate:

To check the specifications of the certificate that we just created, we can display it in text format:

If we intend to use this self-signed certificate as-is, which is perfectly reasonable for vpn1.example.com, we'll need to add the certificate to /etc/ssl/cert.pem on every machine that we want to accept it as valid:

It would be good practice, although not actually necessary, to add the textual form of the self-signed certificate to /etc/ssl/cert.pem too, following the style of the existing entries in that file.

The configuration of the local mailserver is slightly simpler:

The relevant keys and certificates can be created using the process described above for the remote VM. We only need to use self-signed certificates on the local server, as it is only speaking SMTP to our other machines and not to other hosts on the internet at large.

The hosts file on the local server should contain an entry for smtp.example.com with the IP address for vpn1.example.com:

This is simply to avoid details of the VPN appearing in the Received: headers of outbound email.

The configuration of smtpd on the local workstation is very straightforward:

By default, smtpd waits an increasing amount of time between successive delivery attempts. This is reasonable behaviour when delivering to most SMTP servers, as publicly accessible SMTP servers on the internet are generally expected to have good network connectivity and good uptime. If you intend to keep your wireguard tunnel open 24 hours a day, and your connectivity is reliable enough to do this, you might not need to change smtpd's scheduling behaviour at all.

To increase the frequency of delivery attempts, we can edit the file /usr/src/usr.sbin/smtpd/scheduler_ramqueue.c, then re-compile and restart smtpd:

The changes you will probably want to make are to the define for BACKOFF_TRANSFER, which defaults to 400 seconds, and the function scheduler_backoff, removing one of the multiplications by step from the returned value, so that re-delivery attempts are made at constant rather than increasing intervals.

We tested the previous incarnation of this setup, (using an IPSEC tunnel), between a local server and a VM at OpenBSD Amsterdam to allow mail delivery over inbound SMTP connections for over a year, and at least for us it has proven reliable handling hundreds of emails per day. Initial tests using wireguard suggest that it should be at least as reliable as the IPSEC tunnel method, but as of the time of writing this updated article, our tests are still on-going.

One of the advantages of this particular setup, is that the workstation, mimando.lan in our example, does not need direct internet access in order to send and receive internet email, as it only submits to and receives from carinho.lan.