Linux-IPSec avagy RACOON helyett mit?

Linux-haladó

Udv,

A linuxos ipsec-tools aka. RACOON ugye mar unmaintained lett, nem fejlesztik evek ota, es mar a patchelese is abbamaradt. Kb annyit irnak mindenhol, hogy hasznaljak mast helyette.

De mit? :)   Mi szamit manapsag standard ipsec implementacionak linuxon?

Vannak a SWAN forkok, libreswan, openswan, strongswan, freeswan meg mittomenmilyenswanok. Eleg zavaros mi a kulonbseg koztuk, a licenszelesen kivul. Melyiket mennyire fejlesztik, supportaljak meg?

A'rpi

ps: nem, openvpn nem jo. meg mas vpn megoldas sem erdekel, mert mas cegek enterprise tuzfalaival kell ipsec-et beszelni, ebbe nincs beleszolasom.

  • 821 megtekintés

( ibenny v | 2020. 08. 04., k – 18:53 )

Szerkesztve: 2020. 08. 04., k – 18:54

Mondjuk StrongSwan-t. Tamogatott, fejlesztett, stabil, tobbet nem is nagyon akarhatnek. :)

( godot v | 2020. 08. 04., k – 18:58 )

Szerkesztve: 2020. 08. 04., k – 19:06

Ha jót akarsz magadnak Strongswan. Openswan-t nem fejlesztik már. A Libreswan-t  fejlesztik (sőt RHEL ben ez az alapértelmezett tippre a FIPS minősítés? miatt), de a kódbázisa nem egy leányálom (20 + év sitthalom, ez ugye a *swan ok egyenesági pluto démonjának továbbvitele). Nekem többször crashelt olyan ike csomag  parser hibákkal, hogy ihaj. Mondjuk mióta Libreswan néven fut pucolják a kódot azért rendesen.. (fő fejlesztő RH alkalmazott). Ikev2 támogatása nem annyira kiforrott mint a Strongswané.

 A Strongswan 5.x-nek a nevén kívül semmi köze a *swan-okhoz. Teljesen 0-ról újraírt implementáció (charon démon). Atom stabil. Több 100 s2s tunneles környezetekben használom, tucatnyi különböző ipsec vendorral a másik oldalon.

Hm, ez sok mindent megmagyaraz. RHEL5-ben racoon volt, ment is stabilan. RHEL6-ban volt libreswan de folyton stabilitasi gondjaink voltak... Itt ugy "workaroundoltuk", hogy az ipsec terminalasra befogtunk egy pfsense instanceot (lovesem sincs, hogy abban mi van, de osszekattingatva mukodik azota is stabilan).

( mauzi v | 2020. 08. 04., k – 19:14 )

Nehéz ügy. Én vagy két évtizedig Racoon felhasználó voltam (már csak azért is, mert ugye *BSD preferenciám volt), de pár éve Linuxon át kellett állnom strongSwan-ra. Működget, de nem mondom, hogy jó pajtások vagyunk. A Racoon-nál hozzászoktam, hogy "setup and forget", míg a strongSwan-nál egy sima IKEv1 transport módú site-to-site konfiggal is heteket szoptam (dead peer detection, reconnection, rekeying, auto connect, stb.) mire 100% üzembiztos lett kezdve azzal, hogy az összes példa konfig a gyakorlatban szar.

Jelenleg ezzel működik tűrhetően stabilan:

- az egyik oldalon (nevezzük szervernek, bár egyenrangú)

auto=add
dpdaction=clear

- a másik oldalon (nevezzük kliensnek, bár egyenrangú)

auto=route
dpdaction=clear

s2s tunneleket érdemes mindkét oldalon auto=route-ra tenni. Ekkor a Strongswan installálja a kernelbe a trap  policy-t és bármely csomag ami illeszkedik a policy-ra felszól az XFRM socketen keresztül a strongswan-nek, hogy indítson SA-t ha még nincsen. A dpdaction=hold vagy dpdaction=restart is ajánlott. A dpdaction=hold ugyanúgy installálja a kernel policy-t. A dpdaction=restart meg ha DPD miatt megáll az ipsec újratriggerel egy SA kérést. De sajnos ez sem segít néha :). Ekkor még érdemes a closeaction=restart-ot is beállítani. Ez akkor is új SA-t kér ha a másik oldal "normál okok miatt (tehét nem dead peer) törli az SA-t (pl egy delete SA üzenettel, de nem jön rekey meg semmi utána). És akkor még a keyingtries=%forever beállítást is említhetném.... :)

Sajnos az Ipsec nem triviális. És nem feltétlenül a Strongswan miatt. Inkompatibilis implementáció hegyek vannak. Érdemes ikev2-t használni mindenhol ahol csak lehet. Jelentősen stabilabb. Megoldottak egy csomó "out of state" problémát amire az ikev1-nél még nem gondoltak.

Egyébként megkeresem majd,de azt hiszem már van valami draft az ikev1 deprecated-é tételére (kb mint a TLS 1.0-nál).

A Strongswan doksija nem éppen acélos,de a test suite-ban lévő scenáriókat éredemes nézegetni. Mindenre IS van ott megoldás.

Ajánlott olvasmányok:

https://wiki.strongswan.org/projects/strongswan/wiki/Interoperability

Nagyon ajánlott, főleg ha nem szeretnénk clear text packet leaket ha nem épül fel az ipsec:

https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations

test suite:

https://www.strongswan.org/testresults.html

Még egy megjegyzés és abbahagyom a szófosást... :)

Érdemes tudni, hogy néhány ikev1 implementáció , leghíresebb pl a Cisco ASA egyszerűen nem rakta bele az ikev1 démonba az újabb algoritmusokat. Pl SHA256 MODP2048 stb...

Ezért aztán ASA-n ha normális crypto-t akarsz "kénytelen" vagy ikev2-t használni. Ikev1-el egyzserűen már csak "nem ajánlott" SHA1+MOD1536-ot tudsz beállítani. Az RFC8247-ben a modp1024 és modp1536 SHOULD NOT status-ban van.

:)

Vannak olyan IPSEC implementációk ahol nem mindegy a security proposal-ok sorrendje. Hajam hullott ki, amíg rájöttem egyszer, hogy hiába küldöm be a túloldalnak a megfelelő proposalt "is" (több másikkal egyetemben), csak akkor fog működni az IPSEC ha az ike proposalban a sorrendben az első proposalra van match. Ekkor jön a játék az ike=,esp= sorokkal a Strongswan-ban. Amúgy is érdemes leszűrni mert alapból elég sok algoritmus fel van sorolva a defaultban (ha nem adsz meg ike és esp sort).

Elképesztő egyébként ez a kupleráj az ike környékén. Képzeld el ugyanezt ilyen szinten mondjuk Tlsv1.2 implementációkkal. Tele lenne kürtölve az internet vele....

Vagy "secure by default" OpenBSD-ben lévő isakmpd ikev1 démon, ami bármilyen!! traffic selector-t elfogad a túloldaltól by default , a doksi erről nem tesz említést....

2017 óta nem javították leaglább doksi szintjén..... Igaz azt mondják használd az iked ikev2 démont inkább... :)

https://marc.info/?l=openbsd-misc&m=151175827013403&w=2

strongswan-ban meg lehet valahogy ertelmesen nezni, hogy a tuloldal mit kuld, mit szeretne? sok esetben nem azt allitjak be a tuloldalon amit megbeszelunk (vagy nem azt csinalja az eszkoz amit beallitanak neki, volt hogy pl. a beallitott lifetimeokat felulbiralta valami beepitett limit, vagy a beallitott cryptot nem tamogatta es csendben valami mast csinalt helyette), ilyenkor a racoon logbol debug modban ki lehetett azert nyomozni hogy megis mi a jo setting.

nagyon ugy erzem, hogy ez a racoon-rol atallas azert tobb lesz, mint par config filet atirni mas szintaxisra :)  van egy par tucat s2s tunnel nalunk is.

Persze lehet. Subsystemenként (ike,net,mgr,enc) lehet állítani a logolást több szinten restart nélkül.

Olvasmányos legtöbbször. Mondjuk néha nem és meg kell nézni az ike RFC-t hogy mit akart a költő.... a kriptikus hibaüzenetek miatt... :)

kb hasonlókat lehet látni...

https://serverfault.com/questions/895354/strongswan-received-no-proposal-chosen-error-notify-while-connecting-to-cisco

Egyébként migráltam kb mindenről IS strongswanra meg le strongswan-ról, és meglepően könnyen ment. Nyilván nem árt némi ipsec sittes rutin hozzá....

s2s tunneleket érdemes mindkét oldalon auto=route-ra tenni.

Csak engem szopat azzal a strongSwan, hogy két s2s peer között néha egynél több SA jön fel? Többféle szkenárióban sikerült már belefutni, pl. dpd, vagy akár egy sima rekeying.

szerintem az tok normalis, legalabbis racoonnal mindig van atfedes, elobb huzza fel az ujat es csak utana torli a regit kis kesessel, hogy ami csomag a regi kulccsal jon azt is tudja meg dekodolni.

meg nekem van olyan s2s linkem is ahol 3 kulonbozo subnet megy ugyanabban a kapcsolatban, tehat 1 phase1 es 3 phase2 van. eleg mokas volt racoon-al osszehozni (asszem juniper a masik vege) :)

Nem az átfedésre gondolok, az normális. Arra gondolok, ami nem normális. :)

Pl. ha nem a "dpdaction=clear" beállítást használtam, hanem a minta konfigokban is előforduló többi variánst (pl. dpdaction=restart) - akkor, szakadás esetén a dpd is nyitott egy SA-t, meg az auto=route is, legalábbis, az volt a tünet, hogy szépen elkezdtek szaporodni az SA-k, egyes esetekben már akár 7-8 SA is volt egyidejűleg. Mivel utoljára kb. egy éve foglalkoztam ezzel, már nem nagyon emlékszem a részletekre...

De ez problémát is okozott vagy csak zavaró volt?

Egyébként a megoldás erre is az ikev2. Ott normális state management van sequence numberekkel meg ackolással....

Az ikev1  by design ilyen szar.

Reliability and State management: IKEv2 uses sequence numbers and acknowledgments to provide reliability and mandates some error processing loistics and shared state management. IKEv1 could end up in a dead state due to the lack of such reliability measures, where both parties were expecting the other to initiate an action - which never eventuated . Work arounds (such as Dead-Peer-Detection) were developed but not standardized. This meant that different implementations of work-arounds were not always compatible.

Azt érdemes tudni hogy a Strongswan 5.x-ben a újraírták az ikev1 démont 0-ról. Előtte a Strongswan is a pluto-t használta. Az 5.x óta a charon démon viszi az ikev1 és ikev2-t is.

Az ikev1 az 5.0-5.2 környékén okozott furcsaságokat nekem is. Én kb 5-6 éve migráltam minden régi *swan (openswan,libreswan)-ról. Nem tapasztalok ilyen furcsaságokat. Illetve ha igen, ott legtöbbször a másik oldali implementáció szivat....

( arpi_esp v | 2021. 06. 13., v – 22:34 )

Szerkesztve: 2021. 06. 13., v – 22:36

idkozben lecsereltem a racoont, stringswan 5.9.2-re.
a site2site tunnelekkel nincs is gond. viszont az L2TP-nel ugy tunik, miutan a kliens lecsatlakozott (vagy leszakadt), a szerver meg probalja ujra felepiteni az ipsec kapcsolatot, es soha nem adja fel.

ez pl. mar tegnap ota connecting-be van, es a logba latszik, hogy folyton probal kuldeni arra az ip-re, de nem jon valasz:

     L2TP-TK[11]: CONNECTING, 193.224.177.7[%any]...80.98.39.10[%any]
     L2TP-TK[11]: IKEv1 SPIs: cee0ed42eacdaf38_i* 0000000000000000_r
     L2TP-TK[11]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD
     L2TP-TK{17}:  INSTALLED, TRANSPORT, reqid 3, ESP in UDP SPIs: c1e26526_i 9523ffe8_o
     L2TP-TK{17}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying active
     L2TP-TK{17}:   193.224.177.7/32[udp/l2f] === 80.98.39.10/32[udp/l2f]

ipsec.conf:

conn L2TP-TK
    type=transport
    auto=add
    dpdaction=clear

mi kene meg neki, hogy ne erolkodjon foloslegesen?

nem hinnem, hogy lenne... foleg 1-2 nap utan?  amugy szaporodnak, mar 5 van beakadva:

Security Associations (7 up, 5 connecting):

te milyen idoket adsz meg ikelifetime/keylife eseten L2TP-hez?

szerk: lehet ez okozza...?   most lattam egy peldat ahol 1-re allitottak:

    keyingtries=%forever

Nálam ez a konfig releváns része:

conn l2tp-defaults
        type=transport
        keyexchange=ikev1
        ike=aes256-sha512-modp3072,aes256-sha1-modp2048,aes256-sha1-modp1024!
        esp=aes256-sha512,aes256-sha1!
        authby=secret

conn l2tp-over-ipsec
        also=l2tp-defaults
        left=www.xxx.yyy.zzz
        leftprotoport=udp/1701
        right=%any
        rightprotoport=udp/%any
        auto=add
        dpdaction=clear

Ezres nagyságrendű (főként Windows 10-es) kliens nyúzza, a szimultán kapcsolatok száma 100-on belül szokott lenni. Alapjaiban véve, gondozásmentes.

keyingtries beállítás nálam csak site2site esetében van.

thx. kivettem a keyingtries-t, most jonak tunik :)

ha mar ennyi win kliensed van, nalatok nem jott elo az a problema, ha ugyanaz a public ip (NAT cim) mogul csatlakozik 2 win kliens? mondjuk 1 haztartasban vagy pl. 1 hotelben van 2 user, igy kifele ugyanazon ip-n es porton latszik...

es amugy xl2tpd-t hasznalsz vagy mast az l2tp-hez?

Van  megoldás  a több user ugyanaz a publikus IP aka same nat problémára....,de nem 100%-os

https://wiki.strongswan.org/projects/strongswan/wiki/Connmark

Mi az oka amúgy, hogy l2tp van még használatban, nem egyszerűbb Ikev2-re átállni, Windows 7 óta támogatott.

igen a connmark-osat megtalaltam en is, de az a githubos patch... az nagyon gaz :)

ikev2: hmm, koszi a tippet, megneztem, kiprobaltam win/mac alol, szerintem ez jo lesz. anno azert lett l2tp, mert azzal lehetett AD-bol user+pass hitelesiteni radiussal, es racoon-nal ugye ikev2 nem is volt opcio, az ikev1+xauth meg nem tul szabvanyos es elterjedt. legalabbis kb 10 eve, amikor ez be lett nalunk vezetve...

( zeller | 2021. 06. 14., h – 22:19 )

Ezt végig kell frissebb fejjel olvasnom...