WireGuard/IPSec: massime prestazioni ottenibili con RouterOS e pfSense

nxdrd in questo momento non ho modo di effettuare test, ricordo però che effettuando uno speedtest un core andasse quasi 100%, mentre gli altri intorno al 40%.

Servirebbero i dati di ambo gli endpoint ma penso se ne possa ragionevolmente concludere che non hai offloading o acccelerazioni disponibili.
Non trascurare wtf la scelta dello MTU é cruciale per le prestazioni ed i valori potrebbero essere ben diversi tra VPS e 'tik.
Su github trovi uno script al proposito per wg: ci sarà sicuramente altro in giro ma per provare potrebbe andare.

Sulla differenza di prestazioni tra wg e ipsec, YMMV: potrebbe pure essere di pochissimi punti percentuali.
Con ipsec introduci pure differenti cripto e la combo cripto / mtu può variarti le prestazioni (per ambo gli endpoint).

Technetium
Andavo a memoria, in realtà mi riferivo ai test in IPsec.

wtf
Quelli sono i risultati con Ros6. Con ros7 sono un pochino meno perchè l'os nel suo complesso "pesa" di più. E tieni conto che sono test fatti senza firewall.
In ogni caso, nel caso reale, una connessione gigabit più o meno la saturi (perchè i pacchetti non pesano tutti uguali)

wtf Il RB4011 dovrebbe riuscire a farlo 1 Gb/s attraverso la VPN.

Bisogna anche specificare quale
Ipsec, se scegli algoritmi di criptazione con accelerazione, si. Se scegli algoritmi non accelerati, no.
Wiregurad, non ci arriva.
OpenVPN, non ci arriva.
SSTP, non ci arriva.

Technetium Bisogna anche specificare quale

Certo, era buttata lì, nel senso che ci può arrivare, naturalmente poi dipende da altre n (con n grande a piacere) variabili !

Ciao @nxdrd , se usi come router RB450Gx4 potresti provare GRE + IPsec, molto semplice l'implementazione.
WireGuard ho calcolato MTU di 1432 con IPv4 e PPPoE MTU 1492.

Avevo fatto alcuni test su hAP ac3 ed hEX, le prestazioni con entrambi i protocolli erano forse 1/5 della linea.
Potresti anche provare a sostituire new-mss=clamp-to-pmtu con
/ip firewall mangle add action=change-mss chain=forward new-mss=... in-interface="..." protocol=tcp tcp-flags=syn tcp-mss=...-6553 dovrebbe essere più leggero

ST_ Potresti anche provare a sostituire new-mss=clamp-to-pmtu con
/ip firewall mangle add action=change-mss chain=forward new-mss=... in-interface="..." protocol=tcp tcp-flags=syn tcp-mss=...-6553 dovrebbe essere più leggero

Però sono cose un po' diverse.
Con il primo, fa un path MTU discovery e poi imposta quella dimensione, e lo fa ad ogni riconnessione.
Con il secondo, sei tu che imponi la dimensione.

Se tu imponi la dimensione devi essere sicuro che venga rispettata. Sempre.

Io ho avuto problemi con linee Wind e Fastweb perchè a seconda dell'instradamento interno, l'MTU variava. Risultato, si frammentavano e quando avanzavano pochi bit, spesso andavano persi. Come se la rete interna dell'ISP scartasse i pacchettini per fare pulizia. Risultato: il link stallava... poi si riconnetteva.. poi stallava... un disastro.

Qualche benchmark dal sito wireguard.

wtf Qualche benchmark dal sito wireguard.

IkeV2?

documibozu Zyxel nwa50ax pro

È un access point...

documibozu Netgear wax220

È un access point

documibozu gli.inet mt6000

Fa 900mbps con wireguard... e non so se ti sei accorto del fatto che monta un processore a 64 bit che arriva 2Ghz. E anche con routeros e pari processore, saturi la gigabit con wireguard. L'ho scritto sopra.

Mandami una schermata del gli.inet mt6000 per vedere se a 900mbs di wireguard satura un core o per che motivo non va oltre.

documibozu A dire il vero wireguard non è single core / single thread, quello è (era) openvpn...

Ovunque dicono che la limitante è più la frequenza del processore.
In ogni caso su routeros, ma anche anche su altri se mandi il tunnel wireguard a saturazione, finisce per saturare un core (prova su un linux con processore multicore..).
Fai una ricerca e vedrai che ci sono molti riferimenti al fatto che wireguard tende a saturare un core e dopo di che a limitarsi. Infatti ci sono degli studi per cercare di evitare questo.
Ed è uno dei motivi per cui non viene adottato su vasta scala in ambiti high-performace.
Questi, stanno sprecando il loro tempo ?
https://netdevconf.info/0x18/sessions/talk/achieving-linear-cpu-scaling-in-wireguard-with-an-efficient-multi-tunnel-architecture.html

O fai un giro su reddit / Wireguard e vedi che è un problema continuamente riportato.

In particolare dovrebbe essere il processo che fa il fowarding dei pacchetti sull'interfaccia a mandare in saturazione il core. Purtroppo va fatto in ordine ed è difficile farlo in multicore.

documibozu Con mikrotik non ce la fai perché in alcuni casi monta processori vecchiotti e ti fa pagare caro routeros, in altri monta processori nuovi ma è limitata da Routeros (sembra strano ma è purtroppo così)

Può essere una visione... ma è il vantaggio di essere programmabili che ha un peso.
Comunque il flint 2 non fa di meglio a parità di processore.

documibozu Il flint2 non fa meglio, il problema è che fa uguale in inferiorità di costi.

C passano 20 euro.
Di contro il flint non fa cose che con ros puoi fare e viceversa. Dipende cosa serve.

documibozu Wax e nwa50ax sono access point certo, ma li puoi utilizzare agevolmente come roas, hanno un'interfaccia a 2.5gbps

Sarei abbastanza stupito se fa 900mbps... ha un processore dual core, 1300Mhz a 64bit.