The Good:   supports L2TP, PPTP and Cisco IPSec VPN

The Bad:   doesn’t support open standards like Openvpn

The Ugly:  doesn’t support

• Pure IPSec
• IPSec Machine Certificates
• PPP User Certificates or SmartCard (EAP-TLS)
• L2TP/IPSec Kerberos Authentication Token
• RSA-SecureID (EAP-RSA) Authentication Token

In the mean time I was able to setup a pptp server on my Ubuntu box. It works and my Ipod Touch can connect to it (but for some reason the pptpd daemon randomly dies after some usage…).

However I’ve been struggling with routing the ppp0 interface (the connection of my Ipod through the VPN) to my eth0 interface (where my Internet traffic comes and goes). I’ve asked some random irc geniouses, all with their own iptable configuration ideas, but in the end, none of that worked and I was left with a messed up iptable configuration.

So it’s a good thing to keep in mind:  If your iptables are screwed up, enter:

sudo iptables -flush

this will restore your routes to default.

Anyway I’m planning to move away from pptp since I found some articles saying that it isn’t really as secure.

So now I’m installing Openswan, an IPSec implementation. The configurations isn’t really as easy as I hoped, but I’ll be very happy if I even can connect to it with my Ipod.

***UPDATE***

I let go of Openswan because people suggested me that IPSec was too much overkill for just my Ipod.

So I finally figured out what my problem was with PPTP. My Ipod was able to connect to the internet after all.

A quick   ping 64.233.187.99   did the trick, but  ping google.com   didn’t work at all.

This means that my Ipod had no way to contact the DNS server.

After taking another look at the configuration files of ppp, I soon noticed the unmarked ms-dns settings.

Uncommented that and added the ip address of my router and VOILA! My Ipod could now successfully connect to the internet through my VPN!

Moral of the story:  Always check the options in your configurations files.

Avui he suat i he “perdut” un temps increible en la configuració d’un client vpn mobil, roadwarrior, contra un gateway vpn Ipsec Linux Fedora Core 6, amb Openswan 2.4.

Necessitava fer una configuració ràpida i pràctica: PSK compartida. He tutlitzat un clent vpn de Zyxell, que està basat en el client VPN Greenbow. És comptaible amb totes les versions Windows, inclós Vista. La veritat és que la configuració ha estat ràpida, i de seguida he establert la primera i segona fase. Però tenia problemes d’enrutament. Un cop la connexió estava establerta, des del roadwarrior, feia ping al gateway, el paquet apareixia a l’intèrficie d’ipsec, però ja no apareixia amb el tcpdump en la intèrficie de la lan. A on desapareixia el packet?

Per suposat, regles de forward, iptables, l’opció d’ip_forward estava tot habilitat. Però tenia clar que tenia un problma d’enrutament.

Després de Googlejar, documentar-me, testejar, etc… fent prova i error, he trobat la solució, aquesta línea en la connexió openswan referent al roadwarrior:

rightsubnet=vhost:%no,%priv

Aquesta línea és indispensable, si utlitzes roadwarriors darrera un router amb NAT. Un 0 a la documentació Openswan que no ho tenia cobert.

L’entorn gràfic d client Greenbow, és més usable que el que utilitzava fins ara, el Safenet.

Well, the time has come to say goodbye to Ubuntu.  It’s been a fun relationship, but alas it’s time for it to end.  That’s not to say that the problem I have is with Ubuntu – it’s actually with a variety of circumstances that have caused me a MAJOR headache.

The problem lay within Debian and the OpenSSL project.  It seems that the package maintainers for Debian fixed a bug in OpenSSL without passing the fix upstream to the OpenSSL maintainers to check.  This fix has resulted in a major insecurity in a vast number of packages that depend on OpenSSL for any distribution that sits downstream of Debian.

http://www.technologyreview.com/Infotech/20801/

While there is now an official resolution for this problem, it’s shaken my confidence in the way the Debian package maintainers apply bugfixes in their haste to get new releases out the door.

For those interested, the official resolution page on the Debian site is here.

Bear in mind that I run 5 Ubuntu machines (desktops and servers, work and home) each running some of the affected programs…..it’s a phenomenal headache for me.  Now picture those with hundreds (even thousands) of servers and workstations.   I can’t begin to imagine the trauma they are going through….

It’s because of this break of confidence that I have decided to cease using Ubuntu.  If the Debian package maintainers have disregarded policy in order to add value to their distribution in this case, where else have they fixed issues that may or may not have significant consequences…

I’ve played with Fedora previously – quite liked it as a distro, but preferred the user friendliness of Ubuntu – easy to use, but with all the benefits associated with most other Linux distributions.  I could do a Ubuntu install in 15 minutes that would be suitable for most people, with full hardware support – but for more intensive server applications, all the boxes were ticked too.

So, I’m now in the process of my Fedora migration….starting with this laptop.

До настройки OpenSwan я думал, что имею представление о Linux-шаманстве. Но это чудо, усыпанное независимыми ручками настройки, тумблерочками и кнопочками, бьет все рекорды. И, что характерно для подобных продуктов, уже отлаженный, рабочий конфиг выглядит настолько очевидным и логичным, что поневоле удивляешься: с чем там можно было бороться столько дней подряд?

Но все закончилось хорошо. IPSec с сертификатами и L2TP-туннель заработали, офисная сеть открылась избранным (roadwarriors).

P.S. Почему у l2tpns нельзя указать локальный IP и как это хозяйство роутить — осталось загадкой. Пришлось ставить обратно l2tpd.

UPD: Судя по рейтингам поста, людей интересует сам конфиг. Исправляю упущение.

Задача: открыть доступ к ресурсам корпоративной сети для сотрудников, которые находятся дома или в командировке.

Подзадача: создать безопасный канал связи между роутером корпоративной сети (внешний адрес, для определенности, 80.80.80.219/29) и компьютером сотрудника.

Листинг /etc/ipsec.conf:

version 2.0

config setup
        nat_traversal=yes                    # для тех, кто за NAT-ом
        interfaces=%defaultroute
        virtual_private=%v4:80.80.80.216/29  # подсеть, в которую входит наш секурный хост

conn %default
        keyingtries=1
        compress=yes
        disablearrivalcheck=no
        authby=rsasig
        leftrsasigkey=%cert
        rightrsasigkey=%cert

conn roadwarrior-l2tp                   # имя соединения произвольное, т.к. соединение
                                        # выбирается опенсваном по параметрам
        left=80.80.80.219               # должен быть в virtual_private
        leftnexthop=80.80.80.217        # инет-роутер подсети
        leftcert=mydomain.ru.pem        # сертификат должен лежать в /etc/ipsec.d/certs
        leftprotoport=17/1701
        right=%any                      # принимаем соединения с любого адреса
        rightsubnet=vhost:%no,%priv
        rightprotoport=17/1701
        pfs=no
        auto=add
        type=transport

include /etc/ipsec.d/examples/no_oe.conf

conn block
        auto=ignore

conn private-or-clear
        auto=ignore

conn clear-or-private
        auto=ignore

conn clear
        auto=ignore

conn packetdefault
        auto=ignore

P. P. S. OpenSwan ничего не знает ни о настройках L2TP, ни о топологии внутренней подсети, к которой предполагается открыть доступ через VPN. Подобные тонкости не фигурируют в ipsec.conf. Применительно к L2TP, задача IPSec только в создании безопасного транспорта между двумя хостами.