TCP – Experimental Engineering

For years now I’ve used Virtualmin for my hosting requirements, and have made use of Procmail to filter my mail into folders (it’s the default, and rather tightly integrated). The only issue with this system is having to login to two different things for mail: I use Rainloop Webmail for general mail viewing, but the Procmail filters are only editable through the Usermin section of Virtualmin. This is awkward to say the least, so being able to use Sieve which is already supported by Rainloop is a better option. (Sieve is also supported via plugin in Roundcube).

Since we’re going to still need Procmail for the Virtualmin-managed Spam & Virus scanning functions, we will add Sieve at the end of Procmail. There are some

First thing, get Sieve installed via Dovecot, with the following:

yum install dovecot-pigeonhole

Some configuration changes are required to Dovecot to get the Sieve server running, /etc/dovecot/conf.d/15-lda.conf should have this section:

protocol lda {
 # Space separated list of plugins to load (default is global mail_plugins).
 mail_plugins = sieve
}

Finally, in /etc/dovecot/conf.d/20-managesieve.conf, uncomment this section to enable the managesieve server:

service managesieve-login {
 inet_listener sieve {
 port = 4190
 }
}

After these changes are made, restart Dovecot to get the configs reloaded. It’s easy to check if the Sieve server is listening by running the following command:

lsof -i:4190
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dovecot 58667 root 15u IPv4 34795427 0t0 TCP *:sieve (LISTEN)
dovecot 58667 root 16u IPv6 34795428 0t0 TCP *:sieve (LISTEN)

Now for some minor changes to /etc/procmailrc to direct mail to Dovecot for delivery:

LOGFILE=/var/log/procmail.log
TRAP=/etc/webmin/virtual-server/procmail-logger.pl
:0wi
VIRTUALMIN=|/etc/webmin/virtual-server/lookup-domain.pl --exitcode 73 $LOGNAME
EXITCODE=$?
:0
* ?/bin/test "$EXITCODE" = "73"
/dev/null
EXITCODE=0
:0
* ?/bin/test "$VIRTUALMIN" != ""
{
INCLUDERC=/etc/webmin/virtual-server/procmail/$VIRTUALMIN
}
DEFAULT=$HOME/Maildir/
ORGMAIL=$HOME/Maildir/
DROPPRIVS=yes
:0 w
|/usr/libexec/dovecot/deliver
$DEFAULT

I personally got an error when I made all these changes, which in my case was a permissions issue on the Dovecot log:

Can't open log file /var/log/dovecot: Permission denied
procmail: Program failure (75) of "/usr/libexec/dovecot/deliver"

This was solved by opening the permissions for /var/log/dovecot, this then vanished, and the logs confirmed Sieve was working properly.

I’ve been running my own VPN so I can access my home-based servers from anywhere with an internet connection (not to mention, in this day & age of Government snooping – personal privacy & increased security).

I’m on a pretty quick connection from Virgin Media here in the UK, currently the fastest they offer:

To do these tests, I used the closest test server to my VPN host machine, in this case Paris. This keeps the variables to a minimum. Testing without the VPN connection gave me this:

I did expect a lower general speed to a server further away, this will have much to do with my ISP’s traffic management, network congestion, etc. So I now have a baseline to test my VPN throughput against.
The problem I’ve noticed with OpenVPN stock configs are that the connections are painfully slow – running over UDP on the usual port of 1194 the throughput was pretty pathetic:

I did some reading on the subject, the first possible solution being to change the send/receive buffers so they’re set to a specific value, rather than letting the system handle them. I also added options to get the server to push these values to the clients, this saving me the trouble of having to reissue all the client configurations.

sndbuf 393216
rcvbuf 393216

push "sndbuf 393216"
push "rcvbuf 393216"

Unfortunately just this option didn’t work as well as I’d like, downstream speeds jumped to 25Mb/s. In the stock config, the tunnel MTU & MSSFIX settings aren’t bothered with, some adjustment to set the tunnel MTU to lower than the host link MTU (in my case the standard 1500) prevents packet fragmentation, MSSFIX let’s the client TCP sessions know to limit the packet sizes it sends so that after OpenVPN has done the encryption & encapsulation, the packets do not exceed the set size. This also helps prevent packet fragmentation.

tun-mtu 1400 
mssfix 1360

After adjusting these settings, the download throughput over the VPN link has shot up to 136Mb/s. Upload throughput hasn’t changed as this is limited by my connection to Virgin Media. Some more tweaking is no doubt possible to increase speeds even further, but this is fine for me at the moment.

Tag: TCP

Virtualmin Mail – Enabling Sieve Support

OpenVPN Server Speed Tweaks