WireGuard o IPsec: què posem a cada lloc

Cada vegada que algú obre aquesta discussió acaba en religió: una banda diu que IPsec és un fòssil i l'altra que WireGuard és una joguina. Nosaltres operem xarxa pròpia i muntem tots dos. I la conclusió honesta, després d'anys de túnels que cal aixecar a les tres de la matinada, és avorrida: WireGuard guanya en el codi i en el dia a dia; IPsec guanya en tot allò que envolta el túnel. L'interessant és que el 2026 s'ha ficat a la conversa un tercer factor que el 2020 no hi era, i porta data.

Les 4.000 línies que van guanyar la discussió

L'argument fort de WireGuard mai no va ser el rendiment: va ser la mida. Unes 4.000 línies de codi davant de les més de 100.000 d'OpenVPN, i una pila IPsec que a la pràctica són dues coses diferents (un dimoni de negociació en espai d'usuari i el motor de xifratge dins del kernel) mantingudes per gent diferent. Va entrar al kernel de Linux a la versió 5.6, març del 2020, i la frase que Linus Torvalds va escriure a la llista del kernel l'agost del 2018, demanant que l'integressin d'una vegada, se cita tant perquè resumeix el sentiment de tothom qui ha depurat una fase 2: «potser el codi no és perfecte, però l'he fullejat, i comparat amb els horrors que són OpenVPN i IPsec, és una obra d'art».

Toca el matís, perquè la xifra es fa servir amb massa alegria: comparar 4.000 línies d'un mòdul de kernel amb la suma d'una pila IPsec sencera no és comparar el mateix. IPsec fa coses que WireGuard directament no intenta fer, i algunes les necessites. Dit això, l'ordre de magnitud és real i té una conseqüència pràctica que no és estètica: superfície per auditar, i probabilitat que la fallada de la setmana et toqui a tu.

El rendiment no és l'argument (i ho diu WireGuard)

Aquí cal ser justos amb el projecte, perquè és més honest que la majoria dels seus fans. A la seva pròpia pàgina de rendiment, els números que tothom continua citant —mesurats sobre un Linux 4.6.1— venen amb aquest advertiment escrit per ells mateixos: «aquests benchmarks són vells, atrotinats i no gaire ben fets». A la mateixa nota hi afegeixen que des d'aleshores WireGuard i IPsec han millorat tots dos, que WireGuard continua treient avantatge en alguns casos pel seu multifil, que OpenVPN continua sent extremadament lent, i que substituir aquestes xifres per dades noves és feina pendent. És a dir: la taula de megabits que has vist en vint articles no l'avala ni qui la va publicar.

En la nostra experiència, en enllaços d'empresa el coll d'ampolla gairebé mai és el xifratge: és l'enllaç, l'equip barat de l'extrem, l'MTU mal calculada o un proveïdor que fa coses estranyes pel camí. Si estàs triant protocol de túnel mirant una taula de Mbps, estàs optimitzant la variable equivocada.

El que WireGuard fa millor de debò

• No hi ha res a negociar. La construcció criptogràfica és una de sola i està fixada al protocol: Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s. Ni fase 1 ni fase 2, ni proposals que no lliguen, ni el clàssic «pel seu costat veuen el túnel aixecat i pel nostre no». Si les dues claus públiques i l'AllowedIPs estan bé, puja; si no, no puja.
• Roaming de debò. La documentació oficial ho descriu sense adorns: cada extrem envia a l'últim punt del qual va desxifrar correctament, de manera que hi ha «roaming d'IP complet a tots dos extrems». A la pràctica, un portàtil que salta de l'oficina al 4G o una seu amb IP dinàmica deixen de ser tema de conversa.
• Es llegeix sencera. Una configuració de WireGuard cap en pantalla i l'entén qui entra de guàrdia sense haver-la muntat ell. Això, el dia de l'incident, val més que qualsevol prestació. És el mateix criteri amb què mirem quan compensa una SD-WAN i quan sobra: cada capa que hi afegeixes cal saber depurar-la de matinada, no només dibuixar-la a la proposta.
• Darrere de NAT es comporta. Un PersistentKeepalive de 25 segons —el valor que recomana el mateix manual per a interfícies que parlen poc i són darrere de NAT— manté viva la traducció del router i s'ha acabat el problema. No hi ha dead peer detection per ajustar ni temporitzadors de tres llocs diferents.

El que IPsec continua fent millor (i no és nostàlgia)

• A l'altra banda del túnel no sempre hi manes tu. El tallafoc que ja té el client, el router del proveïdor de l'altra seu, el núvol públic: tots parlen IKEv2 i no tots parlen WireGuard. La documentació d'AWS ho diu sense embuts —«Site-to-Site VPN admet connexions VPN IPsec», amb IKEv2 a la llista de característiques—, i el mateix val per a la resta de VPN gestionades del mercat. Triar WireGuard exigeix que els dos extrems siguin teus o vulguin ser-ho.
• WireGuard no sap què és una persona. No hi ha concepte d'usuari ni de sessió: hi ha claus públiques i rangs permesos, i prou. Per a accés remot d'empleats això vol dir que la identitat corporativa, l'MFA, l'alta i —sobretot— la baixa te'ls muntes tu per sobre, amb el que implica el dia que algú marxa. IKEv2 porta EAP de sèrie i s'endolla a RADIUS i a certificats d'usuari sense inventar res.
• Només UDP, i de vegades això importa. La documentació de WireGuard és explícita: «WireGuard no admet deliberadament el túnel sobre TCP, pel rendiment clàssicament terrible d'encapsular TCP sobre TCP». Tècnicament tenen raó. Operativament, la Wi-Fi de l'hotel que només deixa sortir pel 443/TCP no atén raons —i de com d'hostils són aquestes xarxes ja n'hem escrit. Hi afegeixen que «WireGuard no se centra en l'ofuscació»: on algú filtra a consciència, no és l'eina.
• El que no es negocia, tampoc no es canvia. La criptografia fixa de WireGuard evita les suites dolentes i els downgrades, que és exactament el pecat històric d'IPsec. El preu és simètric: el dia que calgui canviar d'algorisme, no hi ha on tocar — cal canviar de versió de protocol.

El factor del 2026: tots dos arriben tard al postquàntic

Aquest és el punt pel qual avui tornem a obrir la comparativa, perquè ha deixat de ser teòric i té calendari. El juny del 2025, el grup de cooperació NIS de la Unió Europea va publicar un full de ruta coordinat que recomana als estats membres arrencar la seva estratègia nacional de transició a criptografia postquàntica abans de finals del 2026 i tenir migrats els casos d'ús d'alt risc com a molt tard a finals del 2030. A l'altra banda de l'Atlàntic, l'esborrany públic del NIST IR 8547 (novembre del 2024, encara sense versió final) posa data de caducitat al mateix intercanvi de claus que fan servir avui els teus túnels: ECDH queda desaconsellat després del 2030 en els seus paràmetres de 112 bits i prohibit —en totes les variants, també les de 128 bits o més— a partir del 2035.

Cap dels dos protocols, tal com està muntat avui a la majoria de llocs, és resistent a un ordinador quàntic. WireGuard ho diu ell mateix, amb aquella honestedat que l'honora: «WireGuard no és, per defecte, postquànticament segur», i ofereix com a remei una clau precompartida que es barreja amb l'intercanvi de claus. El curiós és que IPsec té exactament el mateix pedaç, i a més amb número d'RFC: el RFC 8784, de juny del 2020, «Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security». El mateix apedaçat que WireGuard ja duia des del seu article del 2017, però estandarditzat.

I aquí hi ha el gir que ens sembla la part interessant de tot plegat. L'agilitat criptogràfica, que durant vint anys va ser el pecat d'IPsec, és avui la seva sortida. Des del RFC 9370 (maig del 2023), IKEv2 pot encadenar diversos intercanvis de clau dins de la mateixa negociació i combinar el clàssic amb un de postquàntic, de manera que el secret final es calcula a partir de tots ells: n'hi ha prou que un resisteixi. WireGuard va resoldre el problema d'ahir —que es negociés brossa— i per això té el problema de demà: no hi ha res a negociar quan el que toca és canviar. El seu camí passa per una versió nova del protocol o per muntar un handshake postquàntic per sobre; cap de les dues coses no es fa un dimarts a la tarda.

Sense dramatitzar, que és fàcil vendre por amb això: per a la majoria d'empreses, el 2030 no és una emergència, és una data de renovació. El risc real avui té nom —«recol·lectar ara, desxifrar després»— i només estreny si per aquell túnel viatja alguna cosa que continuï sent sensible d'aquí a deu anys: expedients clínics, propietat industrial, secrets contractuals llargs. Si pel teu hi passa trànsit d'ERP que caduca en un trimestre, respira. Però l'equip que compris aquest any probablement encara hi serà el 2030, i això sí que és una pregunta per a avui: el fabricant té camí postquàntic, o t'està venent ferro amb data de caducitat criptogràfica?

Què posem nosaltres, i on

Som operador amb xarxa pròpia i no venem llicències de ningú, així que aquí no hi ha comissió a defensar. Aquest és el criteri de la casa, tal qual:

• Entre màquines i seus on controlem tots dos extrems: WireGuard. Linux contra Linux, nodes de virtualització, serveis interns que es parlen entre datacenters. Menys peces, menys matinades.
• Contra l'equip d'un tercer o un núvol gestionat: IPsec/IKEv2, sense discussió. El túnel que cal documentar perquè l'entengui el proveïdor de l'altra banda es fa amb allò que aquell proveïdor sap llegir. Barallar-s'hi és perdre temps i quedar malament.
• Accés remot de persones: el túnel és el que menys importa. Aquí el problema no és el protocol, és la identitat — qui entra, amb quin factor i què passa quan aquella persona deixa l'empresa. Triar WireGuard o IPsec sense resoldre això és decorar.
• El que NO fem: canviar un IPsec que funciona perquè WireGuard és més modern. Un túnel estable que ningú toca des de fa tres anys val més que quaranta línies menys de configuració. Migrar-lo té un cost real —finestra, proves, documentació, el sobresalt— i el benefici, si l'actual no dona guerra, és zero.

I un recordatori que donem sempre, perquè el túnel s'endú tota l'atenció i després passa el que passa: xifrar el trànsit no defensa l'enllaç. Si algú et satura la línia, tant se val quin protocol porti a dins; això es resol aigües amunt i amb qui opera la xarxa, no al teu extrem.

El que preguntem abans de decidir

• De qui és l'altre extrem? Si no és teu, la resposta ja està decidida i no és WireGuard.
• Connecta màquines o persones? Màquines, WireGuard encaixa. Persones, necessites identitat, i aquí el túnel és només la meitat del problema.
• Des de quines xarxes s'ha d'aixecar? Si ha de funcionar des d'hotels, aeroports i clients amb sortida filtrada, tingues en compte que l'UDP no sempre passa.
• Quants anys ha de continuar sent secret allò que hi passa per dins? Si la resposta passa de cinc, el calendari postquàntic ja és teu i convé mirar quin camí té el teu equip.

El túnel mai no va ser el projecte

Després de tot això, la conclusió que ens surt és poc èpica: l'elecció de protocol és la decisió menys important de la teva VPN. El que decideix si aquella connexió et donarà problemes és qui la documenta, qui la monitora, qui revoca l'accés quan algú marxa i qui sap què fer quan deixa de pujar. Res d'això ho arregla WireGuard, i res d'això ho espatlla IPsec.

Així que la pregunta que deixem no és quin dels dos és millor. És aquesta: sabries dir avui quants túnels té aixecats la teva empresa, contra qui, qui els va muntar i quin d'ells va deixar de tenir sentit fa dos anys? Aquest inventari gairebé ningú no el té al dia, i quan es fa de debò sol aparèixer algun túnel obert cap a un proveïdor amb qui ja no es treballa. Això preocupa més que el nom del protocol.

Fonts (verificades): primitives i construcció fixa Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s, i el mode de clau precompartida, a wireguard.com/protocol; el «roaming d'IP complet a tots dos extrems», a wireguard.com; l'absència de TCP («WireGuard no admet deliberadament el túnel sobre TCP…»), la manca d'ofuscació i el «WireGuard no és, per defecte, postquànticament segur», a limitacions conegudes; l'advertiment «aquests benchmarks són vells, atrotinats i no gaire ben fets» —juntament amb la nota que WireGuard i IPsec han millorat des d'aleshores i que WireGuard continua per davant en alguns casos pel seu multifil—, a wireguard.com/performance; el keepalive de 25 segons i l'absència de concepte d'usuari o sessió, al manual de wg(8). La xifra de ~4.000 línies davant de les més de 100.000 d'OpenVPN i l'entrada al kernel 5.6 (març del 2020), a BleepingComputer; la cita de Linus Torvalds (llista del kernel, agost del 2018, demanant que s'integrés), recollida a The Register. IPsec: RFC 8784 (juny del 2020, «Mixing Preshared Keys in IKEv2 for Post-quantum Security»; el mode de clau precompartida de WireGuard és anterior, del seu article del 2017) i RFC 9370 (maig del 2023, múltiples intercanvis de clau a IKEv2, que permeten combinar clàssic i postquàntic). Suport d'IPsec/IKEv2 a la VPN site-to-site d'AWS, a la seva documentació oficial. Calendari europeu (estratègia nacional iniciada abans de finals del 2026, casos d'alt risc migrats com a molt tard a finals del 2030), al full de ruta coordinat del grup de cooperació NIS; ECDH desaconsellat després del 2030 en els seus paràmetres de 112 bits i prohibit en totes les variants després del 2035, a l'esborrany públic (novembre del 2024, sense versió final) de NIST IR 8547. Cites traduïdes per nosaltres de l'original en anglès. El criteri, els exemples i les opinions són nostres.