Passi avanti!!!
Almeno credo di aver capito quale sia il problema, che puo' essere quindi spiegato adesso in modi più tecnici e precisi.
Ricollegandomi al post precedente, e più precisamente alla parte in cui affermavo che il meccanismo di occupazione/liberazione delle porte da parte delle richieste sembrava funzionasse a dovere... Ebbene!! Ribadisco che questo meccanismo funziona... ma .... in maniera del tutto inaspettata mi accorgo che invece è la disponibilità delle connessioni massime che col tempo subisce un degrado allarmante...
E' come se il carburante di un serbatoio di un'automobile si consumasse normalmente senza alcun intoppo... ma col tempo le capacità del serbatoio si restringessero inesorabilmente.

Questo problema è molto comune nei router di "piccola taglia" come questi... per la rete e nei forum troverete diverse notizie al riguardo questa problematica, legata perlopiù alla piccola quantità di memoria riservata al servizio NAT nella progettazione di questi apparecchi.
Il punto dolente cmq è un altro... Mentre qualcuno potrebbe individuarne la causa nell'uso spropositato o eccessivo di programmi che aprono in simultanea diverse porte (tipo soft. P2P) con traffico dati a flusso continuo, questa ipotesi, assicuro, è completamente da escludere, poiché "la forbice delle connessioni" si restringe con qualsiasi tipo di attività sul router, anche quelle più stupide e meno impegnative; a riprova di cio' e a scanso di equivoci ho provato a NON aprire mai programmi P2P, limitandomi a navigare e basta con un browser... e la situazione purtroppo non cambia.
Addirittura, e paradossalmente, uno potrebbe pensare di accelerare il processo di esaurimento delle porte, usando a manetta questi programmi; ma a dimostrazione di quanto questa cosa sia assolutamente falsa, e di come il problema NON è minimamente legato all'uso di taluni programmi, il router se ne sbatte e funziona alla grande... Ha un suo orologio!!!, ha un "metabolismo" che rispetta senza che venga perturbato da un utilizzo minimo o pesante dello stesso.

Individuato il vero problema, resta adesso da accertare quale sia la causa. Qua, probabilmente se intervenisse qualcuno più esperto sarebbe meglio.
- Se, per ipotesi, quel valore della disponibilità delle connessioni è strettamente legato alla computazione della memoria residua riservata al NAT allora la causa potrebbe essere quasi certamente legata al firmware e alla cattiva e grave gestione della risorse allocate da esso.
- Sempre per ipotesi, ma meno convincente, potrebbe esserci qualche connessione attiva mappata nel software Discus che, per qualche strano motivo non libera le porte che impegna di volta in volta (ma non credo sia possibile.. altrimenti le "Active Connections" dovrebbe notificare quelle assenti all'appello)
Posto 2 snaps che si spiegano da sole e che rivelano, una volta e per tutte, i VERI sintomi del problema menzionato nel topic:
PRIMA:

DOPO 10 ORE:

Dopo 24 ore la forbice verrà ridotta a circa 22 mila porte, e
dopo 48 ore potrete immaginare voi stessi...
A quel punto l'accesso al router diventerà lento e impossibile e nella più rosea delle situazioni si autoriavvierà da solo.
Porte o connessioni aperte e mantenute prima del raggiungimento del valore critico, riusciranno ancora a instradare dati, inbound o outbound, senza problemi fino a inevitabile auto-crash, motivo per cui software adibiti a chat/p2p continueranno a funzionare imperterriti e "a velocità ADSL" indipendentemente dalla situazione disastrosa del router.
Il traffico dati via un normale browser è invece COMPROMESSO, poiché ad ogni richiesta web si chiede al router l'apertura di una nuova porta.
Interventi altrui al riguardo sono auspicabili e ben accetti.
Ciao e grazie.
P.S.: i firmware AGPF a partire dalla 4.3.4 in poi, attualmente
NON fixano il bug, nemmeno la + recente 4.4.0.0018. Versioni più vecchie si presume si comportino alla stessa maniera, tuttavia io non le ho MAI testate.