VTI Tunnel Interface with strongSwan

I successfully managed to get Linux VTI (Virtual Tunnel Interface) working with strongSwan. By using VTI it is no longer needed to use routing policy database, making understanding and maintaining routes easier. Also with VTI you can see the clear traffic on the interface itself. It was confusing to see actual tunnel traffic before using tcpdump using the standard policy database setup.

With policy database strongSwan installs its learned policy routes to a separate routing table having preference over the main routing table. strongSwan does not support With VTI setup so a (left|right)updown script is needed to setup the tunnel.

/usr/local/sbin/ipsec-notify.sh looks like this:

case "${PLUTO_VERB}" in
    up-client)
        ip tunnel add vti0 local ${PLUTO_ME} remote ${PLUTO_PEER} mode vti okey 2 ikey 2
        ip link set vti0 up
        ip addr add ${PLUTO_MY_SOURCEIP} dev vti0
        ip ro add 44.128.0.0/16 dev vti0
        ;;
    down-client)
        ip tunnel del vti0
        ;;
esac

and /etc/ipsec.conf looks like this:

config setup
        nat_traversal=yes
        charonstart=yes
        plutostart=no

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2

conn hubud2
        leftupdown=/usr/local/sbin/ipsec-notify.sh
        left=%defaultroute
        leftsourceip=%config4,%config6
        leftauth=eap-mschapv2
        leftcert=x.pem
        eap_identity=e.vpn.teszt
        right=88.151.102.245
        rightsubnet=0.0.0.0/0,::/0
        rightid=@i245-102.shosting.atw.hu
        dpdaction=restart
        auto=route
        mobike=no
        keyingtries=1
        keyexchange=ikev2
        compress=no
        ike=aes256-sha1-modp1024!
        esp=aes256-sha1!
        mark=2

In /etc/strongswan.d/charon.conf uncomment these setting and change value to no:

# Install routes into a separate routing table for established IPsec
# tunnels.
install_routes = no

# Install virtual IP addresses.
install_virtual_ip = no

Password entropies

Egy adott jelszó erőssége a megfejtéséhez szükséges, az adott karakterkészlet nagyságára és a karakterek számának lehetséges permutációiból származtatható. Az adott karakterkészlettel előállítható összes lehetséges jelszó darabszámát nevezzük kulcstérnek. Egy egyszerű, 6 karakterből álló, csak angol ábécé kisbetűit (a-z) és semmi más egyéb karaktert tartalmazó jelszó nyers erővel, azaz csupán a lehetséges variációinak kipörgetésével a követkeő sorozatot kell végigpróbálnunk:

próba szám jelszó
1 aaaaaa
2 aaaaab
3 aaaaac
... (és mégtöbb próba) ...
308915774 zzzzzx
308915775 zzzzzy
308915776 zzzzzz

Látható, hogy ennek az egyszerű jelszónak a megfejtése a legrosszabb esetben 308915776 próbálkozás után sikerül. Nagy átlagban persze a jelszó a próbálkozások kb. felénékl lesz megfejthető, mivel nem életszerű az, hogy a jelszó pont "zzzzzz" legyen, mint ahogy az sem, hogy a keresést az "aaaaaa" után sorfolytonosan folytassuk.

Az általánosan elfogadott, 8 karakterből álló kisbetű+nagybetű+szám kombinációkat tartalmazó jelszavak kulcstere 221 919 451 578 090 darab. A kriptográfia rendelkezik egy entrópia nevű fogalommal, mely a jelszavak erőssége esetén az adott jelszó kulcsterének kettes alapú logaritmusában fejezhető ki. A most tárgyalt erősségű jelszó kulcsterének (62 lehetséges karakter 8 alkalommal, azaz 628) entrópiája tehát log2628 = 47.6 bit. Ezt egy átlagos háztartásbeli számítógépnek 44 másodpercébe telik megfejtenie. Összehasonlításul, az előzőekben tárgyalt egyszerű jelszó entrópiája (log2308915776) csupán 28 bit, melyet egy átlagos számítógépnek 0.000062 másodpercig tartana megfejtenie.

A Google App Password által alkalmazott 16 darab a-z tartományban használt jelszó (log22616 ) 75.2 bites entrópiája tehát jóval magasabb, mint a felhasználó által preferált jelszó entrópiája. Ennek kipörgetéséhez az említett gépnek 277 évre volna szüksége.

Ubiquiti UniFi és EdgeRouter LITE tapasztalatok

Vettem a napokban par Ubiquiti Unifi WiFi Accesspointot, meg egy Ubiquiti EdgeRouter Lite routert. Akkor a tapasztalatok a cuccokkal, igy 2-3 nap utan:

UAP: erzodik, hogy 'kiforrott' a technologia. Par dolog meg igy hianyzik nekem. Megha multitenancy nem is, de mindenkeppen fura, hogy nem lehet a tobb kulonbozo telephelyen levo ap-kat viszonylag fuggetlenul managelni, csak overrideolni lehet AP-nkent az egyes beallitasokat. Roppant macera lehet ez, tobb telephelyet egy kontrollerrel managelve. Fura az is, hogy nem lehet tobb admin jogu usert felvenni, hanem csak egyet. Es az deplane fura, hogy ez az admin user lesz az ap-kon helyben is a 'root' felhasznalo helyett, azaz az admin nevevel kell rajuk sshzni :)

EdgeRouter Lite: bejott a legenda. Valoban Vyatta cuccrol van szo, ahogy igy utana neztem, atigazolt az Ubuquitihez par vyattas developer, aztan gondolom licencelik az os-t, meg hazon belul faragjak ubiquitisre. Nagy prozitivum, hogy az OS nem akar tul okos lenni, azaz enged lemenni root bash szinte, kezzel hegeszteni a dolgot, ha ugy hozza a szukseg. Tul okos OS-re jo pelda az, amit a MikroTik muvel. Azzal sajnos vannak behatobb tapasztalataim, es ha az kvazi alapfunkcionalitason tul akar az ember valamit nem is annyira kulonleges felallast osszerittyenteni, akkor mar aranytalanul sok kompromisszumot kell kotni.

Ubiquiti allo fasszal hirdeti mindenfele, hogy hardware acceleration van a packet forwardingra es az IPSec titkositasra. Hat ez tobbe-kevesbe igaz. Igaz akkor, ha ket nativ interface kozott kell forwardolni a packetet. De ha VLAN taget kell tenni barmelyik forgalomra, akkor mar CPU-bol tolja a forgalmat. De ugyanez igaz a PPPoE-s kapcsolatokra is. Sajnos az IPSec gyorsitasi kepesseget nem sikerult prezentalnia a cuccnak, 10Mbps AES256/SHA1 traffic mellett 18% softirq loadot latni. Ugyanez VLAN taggelt forgalom eseten IPSec nelkul 12.5%. A ketto egyutt csak 24%, erdekes modon. Az en elkepzelesem szerint egy access router lenne (lett volna) az eszkoz, ahol egy telephelyet (lakasomat) site-to-site vpn-nel osszekotnem egy masikkal, a helyi switch fele VLAN taggelt forgalmazassal. Ez - ugy tunik - a leheto legrosszabb scenario, mert mindent procibol fog megoldani. Es ha 24% a 10 Mbps eseten, akkor az eles vegpont 40-80 Mbps varhato forgalmatol siman beverezne. Es ott meg hozzajon a PPPoE overhead is, ami a mostani tesztekben (UPC-s DHCP) nem is volt jelen. Szoval nem tudom, hogy mi legyen az eszkozzel. L3 'switchnek' tul keves porttal bir, es buta ip routingra meg boven jo amit az eleve meglevo L3 switchem tud. Lehet, hogy megiscsak maradok az intel d2500cc lapnal openbsd-vel, mint ahogy most van. Gondolokodom rajta, hogy mire lehet igy hasznalni a kis ERlite-ot. Kisszines, hogy az OpenBSD projekt is gondolkodik rajta, hogy folytassa azt a portjat, ami erre az octeon procira epul :)) Van itthon egy Ubiquiti Routerstation Pro-m is, lehet kiprobalom, hogy az ERLite-hoz kepest hogy 'huz' a 680 MHz-es procijaval :) Sot, arra mar regi vagyam FreeBSD-t telepiteni, lehet itt az ideje.

Most ennyit tudtam igy hirtelen, emlekezetbol leirni a tapasztalatokrol.

Zorp GPL Policy Generátor

Készítettem a Zorp GPL verziójához egy ZMS-szerű konfiguráció-generátor alkalmazást, amely egy egyszerű, könnyen megérhető és szerkeszthető leíró fileból dolgozik. Nagyvonalakban a következőket tudja:

  • Több site és azon belül tűzfal clusterek és zóló tűzfal gépek támogatása;
  • "linkek" használata: bárhol meghivatkozható változók, cluster nodeonként eltérő értékekkel;
  • policy.py generálás:
    • Zónaszerkezetben az InetZone-on inbound és outbound service-felsorolásait kitölti a szabályrendszernek megfelelően;
    • Teljesértékű instance, serivce, router és chainer támogatás;
  • instances.conf generálás;
  • Hálózatikonfiguráció-menedzsment, azaz az interfaces(5) filet is kezelni tudja
  • Fullos High-Availability támogatás;
site
Több site és azon belül tűzfal clusterek és zóló tűzfal gépek támogatása;
linkek
"linkek" használata: bárhol meghivatkozható változók, cluster nodeonként eltérő értékekkel;
policy.py
Zónaszerkezetben az InetZone-on inbound és outbound service-felsorolásait kitölti a szabályrendszernek megfelelően; Teljesértékű instance, serivce, router és chainer támogatás;
instances.conf
instances.conf generálás;
HA
Fullos High-Availability támogatás, keepalived(8) VRRP protokoll használatával, így akár nem-Zorp tűzfalakkal, routerekkel is házasítható, mint fallback megoldás.
Netwroking
Hálózatikonfiguráció-menedzsment, azaz az interfaces(5) filet is kezelni tudja

--

2012-05-16 update: nem fejeztem be, mint ahogy ezt a blogpostot sem. A cucc kis simitasok utan most is generalja a policy-t, de droppoltam mar a Zorpot is, helyette van haproxy meg egyeb kisebb ganyolas.

Wifi - Ethernet bonding

The problem

When I'm at home, I dislike undocking my laptop to move around the house because of the Ethernet-to-WiFi switchover takes long seconds and all my TCP sessions like SSH get lost. It's because my laptop is assigned a different IP Address on wifi and on the wired network even if they belong to the same Layer2 segment (here: VLAN). Weel, it looks like this not the case any more.

The idea

Today I was thinking of bonding, a stuff used to do failover/loadbalancing on wired ethernet NICes, commonly in the enterprises. It can do all sort of standardized stuff like 802.3ad/LACP, broadcasting, 4 different kind of loadbalancing---in this scenario I need only the so called "Active-backup policy". That is, only one interface is active at a time, where the wired Ethernet is the preferred. There is no special config need on the network rig, but it's effective iff the wired connection and the wireless ESSID belong to the same layer 2 network segment.

My theory works like a charm

In this video I demonstrate the setup in use---where a bond0 interface is active on the primary wired eth0 that fails over to wlan0 upon disconnection of the wired ethernet cable. The failover (and failback) happens amazlingly fast, virtually no interrupt can be observed.


Wifi-Ethernet bonding convergence in action

Integration into the everydays

I use wicd to manage my wireless connections. A sad thing is that it doesn't support this much weird setup at all. There was a thread (called Wireless and Wired) on the official forum, one of the developers told 'I would expect it to be very distant in the future, if ever'. I don't know if there's any other network/connection manager to support this. Even worse, wicd is apparently abandoned: they closed down their forums due to spam bots, and there's no reaction from developers on the official freenode IRC #wicd either. Altough wicd source looks easy to modify I guess I will stick to my handmade 'init' scripts to do bonding and wpa_supplicant configuration.

What would be needed in wicd:

A GUI/TUI item needed to configure bonding interface, thus a '-b bond0' paramtere could be used for wpa_supplicant and DHCP client daemons need to bind on bond0 instead of the physical slave devices.

Extending it to the mobile broadband?

It's not possible using standard Linux bonding, instead IPSec+MOBIKE could be used for seamless inter-network roaming. I'm on further rambling on this.