Se mandando pacchetti grandi la VPN sembra morire, probabilmente avete problemi di MTU sul percorso. Potete mettere una pezza inserendo nella configurazione (del server o del client, basta uno solo dei due) la riga

mssfix XXXX

dove "XXXX" è la dimensione in byte del pacchetto massimo trasmissibile nella vpn. Il default se non specificato è 1450. Si può provare con valori più bassi nel caso di problemi.

Applicando (lato server) a un link fra due connessioni FTTH e VDSL, che andando in pppoe hanno MTU di 1492, un mssfix di 1450 la risultante velocità di un rsync (con forte traffico dal client al server) dentro la VPN è passata da circa 8 Mbit a 49 Mbit fissi. Considerando che il link della VDSL è da 50 Mbit e quello della FTTH da 100, direi che abbia fatto una differenza abissale.

La cosa buffa e` che leggendo il manuale di openvpn intuisco che 1450 dovrebbe essere il valore di default, ma ho verificato che impostandolo a 1450 si risolvono problemi, il che mi fa pensare che forse il valore di default era diverso da 1450 in alcune versioni piu` vecchie di openvpn. In ogni caso il trucco e` provare ad abbassarlo e vedere se si mette a funzionare correttamente.

Sempre stando al manuale, con 1450 come valore del parametro mssfix, il pacchetto udp risultante (fuori dalla vpn) dovrebbe poter passare su un path MTU di 1473 bytes, quindi dovrebbe stare dentro a qualsiasi connessione "normale", comprese quelle in pppoe che hanno MTU di 1492.

Un'altra soluzione potrebbe essere usare "fragment" per forzare la frammentazione DENTRO la VPN, in modo trasparente per i client. Questo pero` aumenta di 4 bytes la dimensione di ogni pacchetto.

fragment 1300
mssfix

Mi sono reso conto che con certe installazioni di openvpn moderno (2.5 e 2.6) dietro a un PPPOE (MTU 1492) mi succede che dentro la vpn non mi passano i pacchetti grandi da 1441 a 1448 bytes. Tutti gli altri si. La prova la si può fare semplicemente con un ping in questo modo:

ping -c 1 -s 1420 IP DENTRO LA VPN

Dovrebbe fallire da 1412 a 1420 compresi, e riuscire sia sopra che sotto questi valori.

Per fare funzionare la vpn in queste condizioni le soluzioni possibili sono queste:

• Usare "fragment" dentro la vpn (il client android non lo supporta?)
• Usare "tun-mtu 1420" dentro la vpn (basta lato server, il client riceve la config in push) cosi` riduciamo l' MTU fuori dal tunnel a meno di 1492. Però se poi abbiamo un MTU ancora più piccolo che succede?
• Impostare "mtu-disc no" nel server e nel client, questo dovrebbe dire a openvpn di non impostare MAI il flag "DF" nei suoi pacchetti UDP, ergo questi verranno frammentati quando è necessario. Provato e funziona almeno in un paio di casi.

PS: Ho come l'impressione che sia openwrt che è particolarmente rognoso ma non capisco perché, devo indagare oltre.

Riferimento: https://github.com/OpenVPN/openvpn/issues/823

lanciando uno dei due lati della vpn (il client, tipicamente) con il parametro "--mtu-test", si fa un test dell' MTU sul link. Un esempio di esecuzione potrebbe essere questo:

sudo openvpn --mtu-test --config il_tuo_file_di_config.ovpn 

Il risultato mostrera` la dimensione massima dei pacchetti che openvpn e` riuscito a fare transitare nei due versi. Attenzione però: questo risultato comprende una eventuale frammentazione e ricostruzione ad opera dei vari apparati di rete lungo il tragitto. Se si vuole verificare l' MTU senza alcuna frammentazione, occorre eseguire il test cosi`:

sudo openvpn --mtu-disc yes --mtu-test --config il_tuo_file_di_config.ovpn --proto udp4

In questo modo si setta il flag DF nei pacchetti usati nel test, e si otterra` tipicamente un valore piu` basso come risultato. Se si tiene conto di questo valore nell'impostare mssfix e/o fragment dentro la vpn, si dovrebbe ottenere una condizione nella quale i pacchetti non vengono mai frammentati e quindi non di dovrebbero avere problemi di latenza, di ordine di arrivo non congruente, di firewall che bloccano i frammenti perche` sono stronzi, ecc.