Fórumok
Sziasztok,
Tudja valaki, hogy tűzfal oldalon milyen paraméterezést kell használni az S21 beépített VPN-klienséhez, hogy feléledjen az IKEv2-PSK?
Nem épül ki a phase1 sem, tehát azt gyanítom, hogy az általam próbált titkosítási/hashing párosok egyike sem célravezető. L2TP simán megy, de hát arra meg az Android már azt írja, hogy "insecure".
A vége certificate lesz, de hát ha PSK-val sem megy, addig nem erőltetem.
Hozzászólások
Több mint 1 éve próbálkozok én is egy ilyen semmiszabadidő hobbi projectben (android 11 és windows kliens), és kb. semmire nem jutottam IPSEC + IKEv2 + PSK témában.
Írják még sokan a STRONGSWAN IPSEC kliens appot gugli sztórban. Mert az állítólag sokkal okosabb mint az android beépített bugyuta VPN kliense, amiről ráadásul semmi technikai dokumentáció nincs (csak primitiv max. fél oldalas nextnextfinish enduser "okosító"). A strongswan viszont ahogy én látom, már a PSK-t nem is támogatja, csak cert kombinációk vannak.
IPSEC van már legalább 20 éve a piacon. IKEv2 2005-ben jelent meg először, de ténylegesen 2010-ben lett véglegesítve. Viszont még ma 2022-ben se támogatja minden elterjedt platform megfelelően. Továbbá még ma 2022-ben is lehetetlen hozzá jó doksikat találni (főleg ha konkrét gyártó pl.google android 12+ implementációjáról akarod kideríteni h. mivel lesz kompatibilis) , hát ahhoz igencsak nagy eltökéltség kell.
A neten sokan írják nagy arccal, hogy az ipsec milyen egyszerű! Igen, ha 2 cisco rúter között akarsz kihúzni egy primitív site2site tunnelt, akkor valóban. De ha már 2-3 random dokumentálatlan trágyadomb szoftver (pl. android, windows, opnsense) között akarsz interop-ot, belezöldülsz mire összeáll.
Hülye voltam (vagyok?) ipsec-hez, ezért megnéztem 1 csomó yt videót amiben sokan pofáztak sokfélét. De csak 1 nagy katyvasz lett az egész. A tananyagok nagy része kalapszart nem ér (sok hülye indiaia felhígította a szakmai színvonalat), de nagy nehezen lehetett találni azért 1-2 használhatót. Csak az a baj, hogy a konkrét gyártómnak kéne megmondania, ők mit hogyan várnak és támogatnak ahhoz, hogy aminek elméletileg működnie kéne a 2 végpont között, az a valóságban is működjön.
Könyveket is kerestem ipsec témában. Mind ilyen özönvíz előtti 2003-4-5 környékiek. A többségnél ott is vannak az 1 csillagos review-ok, hogy haszontalan 500 oldal, az író fogta kiprintelte az RFC-t magyarázat, szemléltetés és ÉRTELMES valószerű példák nélkül.
Nem véletlen, hogy terjed a wireguard és minden más vpn, bármi csak ipsec-hez köze ne legyen!
Kíváncsi vagyok te is zsákutcába futsz mint én, vagy meg tudod oldani.
Annyi látszik valószínűnek, hogy a Samsung IKEv2 implementációja eltér a sima Google-étől, mivel állítólag a Pixel-eken megy. Azt nem tudom, hogy a common criteria megfelelőség miatt van ez, sztem a Google telefonjai is tanúsítottak, de ez csak feltételezés.
Még túrom a netet, hátha találok valamit.
oszd meg ha találsz vmit pls. Ugyan nem S21, de nekem is szamszungom van (A sorozat) szóval REMÉLHETŐLEG amit az S21-ben elkövettek, az működik házon belül az alacsonyabb színvonalú vackaikon is.
Vagy nem....
Megvan a válasz, bár nem oldja meg a probémánkat.
A Samsung DH24-et használ hashing algoritmusként, ami sajnos nem elég biztonságos a 128/256 bites AES titkosításhoz, és nem is implementálta egyik tűzfalgyártó sem, én mondjuk Zyxel USGFlex-szel próbálom, de tudtommal egyik nagy gyártónál sincs ez meg.
Szóval az IKE2-höz kell a StrongSwan kliens, és a tanúsítvány... Nincs alternatíva.
Erről van valami pecsétes hivatalos írásod / linked? Csak hogy lehessen mutogatni ha más is szopik épp vele?
A Zyxel support válasza a community.zyxel.com-on. Más nincs.
Megtaláltam. De semmi forrást nem írnak, honnan jött ez az insecure DH24 dologra történő rádöbbenés.
Benne van az RFC-ben 2.4-es fejezet DH24 "SHOULD NOT"
https://www.rfc-editor.org/rfc/rfc8247.html
A Samsung-nak jár a tockos amiért ezt használja. Főleg mert eleve nem igazán implementálta ezt senki eddig sem.
kérdés Android 12/13/14-ben is ez van-e még, vagy azóta észhez tértek?
Hogy valami "papír" is legyen róla.
https://www.cisco.com/c/en/us/td/docs/security/asa/asa915/release/notes/asarn915.html#id_25471
Ha esetleg nem elérhető simán, akkor itt a fontosabb részlet a Release Notes-ból:
A Release Notes frissítésének dátuma: September 18, 2020
Szóval majdnem 2 éve nem támogatott, előtte az volt.
...úgyis jönnek...
Ok, de ez nem bizonyít semmit hogy a Samsung meg pont DH24-et támogat, és csak azt.
A "bizonyíték" megszerzése csak empirikus módon volt lehetséges.
Szereplők: S22 Samsung (Android 12), Cisco ASAv 9.14
Ha nem volt olyan proposal, amiben a dh group 24 szerepelt, akkor az alábbi hibaüzenet jött:
Ha volt, akkor működött az elérés.
Egyébként a Samsung a stock Andoid beépített VPN klienst használja erre a célra.
A Google hivatkozik rá, hogy ha olyan feature kell, amit a stock VPN kliens nem tud, akkor valószínűleg külön szoftvert kell rá használnod.
https://support.google.com/work/android/answer/9213914?hl=en
...úgyis jönnek...
Nem tudom próbálkozott-e valaki azóta, de a legutóbbi Samsung OneUI frissítés óta megint működnek a meglévő L2TP kapcsolatok, de újat nem lehet létrehozni.
Az L2TP áthidalására javaslom a Stronswan klienst és az IKEv2 használatát tanusítvánnyal. működik rendesen.
a samsung oneui az a stock android-ra épülő samsung-customization vagy csak egy -ahogy a neve sugalmazná- userinterface, azaz mint egy launcher?
Valami rendszert érintő dolog van benne, mert elindult az L2TP. De ilyen részleteket nem tudok, sztem nem csak UI-t módosít, csak a neve ez.
Komplett customization, nem csak egy Launcher.
3 hónapja én is szívtam, h. kivezette a G az l2tp-t majd maradt helyette az IKEv2, kollégák lefrissítették az új android főverzióra a telefonjukat, majd jött a meglepetés, h. nem működik a vpn. Ezután olvasgatás G emlegetése, majd mikrotik alapon certificate használatával + Strongswan kliens a mobileszközre és megoldódott, csak pár apróságot állítani kellett hogy ne legyen csomag fragmentáció, mert elsőre nem tűnt fel, nem működött minden szolgáltatás, majd ezt belőve, azóta is szépen muzsikál.
visszatérve az eredeti felvetésre, sztem egyszerűbb cert alapon megoldani, mint a psk, mert ha ki is kerül a cert a mobileszközről, mivel titkosított és kell hozzá egy passkey, hogy importálni/használni lehessen jobb mint egy psk kulcs, fene tudja az hogy tárolódik.
Nincs a világon se jó, se rossz. A gondolkodás teszi azzá... (W. Shakespeare)
Már csak azt kellene valahogy felfognom/kiderítenem, hogy pl. ha a strongswan csinálja a szerver oldali részét a vpn-nek (opnsense disztrib a rúter), akkor amellett h. PSK-s Site-2-Site tunnelek vannak más Opnsense rúterekkel, a remote-user-access-re (roadwarrior a marketing neve ennek a felhasználasi módnak) ezzel párhuzamosan fel lehet venni cert-es konfigot is, úgy h. a közben ott levő s-2-s profilokat nem fogja "elrontani"? Azaz a strongswan szerver része teljesen elkülönítve képes 1 darab public IP-n egy darab TCP/UDP porton egy darab service-n belül szétválasztani certificate-s és PSK-s kapcsolatokat?
Opensense-t nem ismerem, "csak" mikrotikot használunk, azt már nagyjából ismerem (amire nekem szükségem van. Routingba BGP, meg OSFPbe még nem mélyedtem bele ).
Mikrotiknál a site 2 site vpn és a "roadwarrior" külön-külön működik profil alapon, tehát véleményem szerint működhet Opensense alatt is, de majd jön valaki okosabb aki megcáfol/megerősíti az infót.
Nincs a világon se jó, se rossz. A gondolkodás teszi azzá... (W. Shakespeare)
Elvileg nem fogja elrontani.
Best match van, de a policy order is számít bizonyos esetekben! Több paramétert vesz figyelembe a policy matchelésénél, hogy ezek mik és hogyan na az nem nagyon van jól dokumentálva... :). De ha az s2s tunnelek remote peer IP címe fixen meg van adva pl right=1.2.3.4, right=4.5.6.8 akkor az szűkebb illeszkedés mint a road warrioroknál a right=%any. Ha több policy-ra is illeszkedik egy bejövő kapcsolat akkor számít a policy-k sorrendje. Akkor az első illeszkedő nyer.
Azt hiszem a default loglevelen nem írja ki az illeszkedéseket feljebb kell venni, de már régen volt...
gondolom left=x.x.x.x meg right=y.y.y.y szintaxist akartál írni.
A s2s tunnelek dynamic IPs DDNS fqdn-ekre mutatnak, nyilván IP-váltáskor kis kiesés szokott lenni de elviselem. Remote warrior-nak meg effektíve ANY-t kellene megadnom, h. barhonnan beengedje őket. Az h. S2S tunnelnél DDNS-es fqdn-t adok meg ANY vagy IP cím helyett, az specifikáltabbnak számít mint egy ANY? Mármint nyilván csak egy DNS lookup után tudja eldönteni a VPN szerver h. a bejövő IP vajon matchel-é valamelyik DDNS fqdn-hez éppen aktuálisan tartozó public IP-re, vagy nem. Kérdés ezt a DNS lookup-ot vajon elvégzi-e az opnsense? Mivel eddig csak S2S tunnelek voltak, és azok műkődtek eddig, lehet h. ezzel az új roadwarrior üzemmóddal derül ki a szokásos IT-s fuckup: hogy valami csak azért működőtt mert nem volt mellette más szabály amire matchelhetne ezért kizárásos alapon arra az 1re kellett ugrania mert amúgy több szabály esetén már félrement volna VAGY tényleg egyértelmű lesz további szabályok hozzáadásával is a matchelés minden esetben.
Ki kell próbálni egy VM-ben.
Az ANY-s policyt amúgy is célszerű a legvégére rakni.
Nálam android (oneplus 8t, oneplus nord és samsung s21) és windows (10 és 11) működik IKEv2/IPSEC VPN-nel, certificate-el és mikrotik routerrel. Pöcc-röff.
Ezen leírás alapján raktam össze, non plus ultra, hogy van benne egy hiba :)
https://doc.mess.hu/books/ipsecike2-vpn-mikrotik-routeros-alapokon
ezt a mikrotik-es leírást végigpörgetem, hátha olvasok benne hasznosat