симметричность канала VPN

Ну, очевидно, либо пров врёт, либо какое-либо (например, банальная загруженность канала) ограничение на входящий трафф с другой стороны туннеля.

Пров не врет spreed test показывает канал 70 в обе стороны (сервер в Химках)

Скорость обмена с сервром по данным iperf 67/64Мбит.

Так что проблема в туннеле

speedtest же сначала меряет входящую, потом исходящую скорость
И как меряете при помощи iperf?

Simultaneous bi-directional bandwidth measurement: (-d argument)
To measure the bi-directional bandwidths simultaneousely, use the -d argument. If you want to test the bandwidths sequentially, use the -r argument.
By default (ie: without the -r or -d arguments), only the bandwidth from the client to the server is measured. 

Да, спидтест меряет последовательно. А что это меняет? на сервере

iperf -s -p $port -B $listen_interface_ip

 на клиенте

iperf   -c $server_ip -p $port  -r  -t $time

Вечером могу выхлоп показать.

iperf   -c $server_ip -p $port  -r  -t $time

заменить на

iperf   -c $server_ip -p $port  -d  -t $time

А как это поможет увеличить скорость аплинка?

Если при одностороннем обмене скорость вверх ниже чем вниз, то при одновременном двустороннем обмене ситуация явно не улучшится.

Цитирую

Пров не врет spreed test показывает канал 70 в обе стороны (сервер в Химках)

Судя по результатам теста iperf в последовательном варианте, то есть когда downstream и upstream тестируются по очереди, у вас

67/64Мбит

Это, я так понимаю, не через vpn.
А через vpn тогда сколько выдает, пусть даже и в последовательном варианте?
В любом случае, есть несколько хитростей, позволяющих ускорить vpn-канал:
1) В данном случае следует попробовать выключить сжатие, так как канал широкий
2) Вместо сертификатов использовать статические ключи
3) Перейти на менее ресурсоемкое шифрование
После каждого изменения прогонять iperf, как я описал выше (перезапустив сервер и клиент, само собой).

в последовательном варианте выдает 85Мбит вниз и 25 мбит вверх.

А вот по шифрованию возможно. Сервер поддерживает аппаратное шифрование AES, а клиент - нет.

Какой алгоритм шифрования менее ресурсоемок?

Значит тюнингуйте конфиг сервера, если это возможно.
Легко нагуглить другие варианты, как увеличить скорость vpn-канала
http://serverfault.com/questions/388674/optimize-openvpn-connection
http://www.anonyproz.com/supportsuite/index.php?_m=knowledgebase&_a=viewa...
и т.д.
Во время теста iperf посмотрите нагрузку на сервере.

DES, но он давным давно взломан.
В любом случае, см. ман. Blowfish обещает сильный прирост в скорости, не теряя при этом в безопасноти.

 --cipher alg
              Encrypt packets with cipher algorithm alg.  The default is BF-CBC, an abbreviation for Blowfish in Cipher Block Chaining mode.  Blowfish has the advantages
              of being fast, very secure, and allowing key sizes of up to 448 bits.  Blowfish is designed to be used in situations where keys are changed infrequently.

              For more information on blowfish, see http://www.counterpane.com/blowfish.html

              To see other ciphers that are available with OpenVPN, use the --show-ciphers option.

              OpenVPN supports the CBC, CFB, and OFB cipher modes, however CBC is recommended and CFB and OFB should be considered advanced modes.

              Set alg=none to disable encryption.

Проверил - действительно проблема в шифровании.

При cipher none скорость в туннеле около 82 мбит. cipher BF-CBC восходящий трафик в 65 мбит.

А вот установка DES-CBC просадила канал в обоих направлениях до 25 мбит

Спасибо за помощь.