Wednesday, November 7, 2012

OpenVPN over IP Tunnel

In order to let our office to access the private network of our servers in IDC, I set up an OpenVPN server on 1.1.1.1, which is a server in IDC, and set up an OpenVPN client on 2.2.2.2, which is a server configured in DMZ of our office network, like this:
IDC private network--OpenVPN server(1.1.1.1)--OpenVPN client(2.2.2.2)--Office private network
But the OpenVPN connection auto-restarted very often:
Tue Nov 6 10:47:49 2012 Preserving previous TUN/TAP instance: tun1
Tue Nov 6 10:47:49 2012 Initialization Sequence Completed
Tue Nov 6 10:50:27 2012 [server] Inactivity timeout (--ping-restart), restarting
Tue Nov 6 10:50:27 2012 TCP/UDP: Closing socket
Tue Nov 6 10:50:27 2012 SIGUSR1[soft,ping-restart] received, process restarting
Tue Nov 6 10:50:27 2012 Restart pause, 2 second(s)
The connection speed never exceeded  5 Mbps (our office's bandwidth is 100 Mbps).

The connection always stalled during the first MB of a file transfer.

I googled for a long time, tried every possible fix of this problem: changed MTU size, upgraded OpenVPN software, modified the configuration of the core switch.  No use at all.  I doubted that it is the internet connection of our office that causes the problem.

OpenVPN: ldap_parse_sasl_bind_result: Assertion failed.

My OpenVPN server crashes occasionally, with the following messages in log file:
openvpn: ../../../libraries/libldap/sasl.c:262: ldap_parse_sasl_bind_result: Assertion `res != ((void *)0)' failed.
This occurs if openvpn uses auth-ldap but can not bind to the LDAP server.  It's a bug of openvpn-auth-ldap.

To fix it, open auth-ldap-2.0.3/src/LFLDAPConnection.m, change `== -1' to `<= 0' at line 462:
if (ldap_result(ldapConn, msgid, 1, &timeout, &res) <= 0) {
and recompile the package.

See the following link for more information:

http://code.google.com/p/openvpn-auth-ldap/issues/detail?id=11

Zimbra Incremental Migration: an experience

Some days ago, I managed to migrate our company's Zimbra mail system to a new server.  Since there were so many messages to move, the migration was a hard work, and caused a lot of troubles.

A brief description of the task:
  • The old server: CentOS 5.5 x86_64, ZCS 7.2.0
  • The new server: CentOS 6.3 x86_64, ZCS 8.0.0
  • Mail accounts: 1500, messages: 4 millions, storage: 600 GB
  • Bandwidth between two servers: 100 Mbps
I followed the method described in ZxBackup: Incremental migration with ZeXtras Backup.  The process comprised the following steps:
  1. Backup of all messages on the old server: about 4 million items, backup time: 3 days.
  2. Synchronization of backup data to the new server: data size: 320GB, files: 6.4 million, transfer time: 1 day.
  3. Restore of old messages on the new server: restore time: 5 days.
  4. Incremental backup and restore recent messages since last backup
  5. Switch of the mail flow to the new server
  6. Incremental backup and restore recent messages since last backup

Tuesday, November 6, 2012

Android ICS L2TP/IPSec `malformed payload in packet' error

When you try to connect to an OpenSWAN L2TP/IPSec PSK using an android device of version 4.0.x (Ice Cream Sandwich), you may get the following repeated errors:
Nov 7 15:13:42 vpnserver pluto[20906]: packet from 200.143.118.22:500: next payload type of ISAKMP Message has an unknown value: 133
Nov 7 15:13:42 vpnserver pluto[20906]: | payload malformed after IV
Nov 7 15:13:42 vpnserver pluto[20906]: |
Nov 7 15:13:42 vpnserver pluto[20906]: packet from 200.143.118.22:500: sending notification PAYLOAD_MALFORMED to 200.143.118.22:500
and will get a connection timeout.  That is because of a bug in ICS.  Android ICS seems to mess up the payload which causes this error: byte 7 of ISAKMP NAT-OA Payload must be zero, but is not (see rfc 3947).

There has been a bug report about this.  It should have been fixed in Android 4.1.x.   For 4.0.x (ICS) device, fortunately, there is an OpenSWAN workaround available at:
http://people.redhat.com/pwouters/osw/openswan-2.6.38-android-ics-natoa.patch
To resolve your issue, download this patch and recompile your openswan.  If you compile openswan from SRPMS, make sure to change openswan.spec, add `-DSUPPORT_BROKEN_ANDROID_ICS' to make option `USERCOMPILE' in your openswan.spec, like this:
%{__make} \
USERCOMPILE="-g %{optflags} -fPIE -pie -DSUPPORT_BROKEN_ANDROID_ICS" \
......