Ciao a tutti,
vi volevo raccontare una storia davvero curiosa che mi sta accadendo ed approfittarne per chiedervi qualche consiglio.
Tutto parte quando tento di configurare un tunnel IPSec tra l'utenza TIM Business, del tipo TIM comunica gestita, con un host su AS Virgin Media e un host su AS BT a Londra. Dopo innumerevoli tentativi non riesco a fare salire in nessun modo la connessione e nei vari tentativi di risoluzione faccio un Nmap sull'host TIM e orrore... tutte le porte filtrate, anche la 80 e la 443 sul quale abbiamo pubblicato il server web. E infatti il sito web va puntualmente in timeout. Provo vari Nmap da vari host in diversi AS in giro per il mondo e nulla, qualunque AS in italia da le porte aperte regolarmente, e la maggior parte degli host su AS esteri le da filtrate. A rendere la cosa ancora più strana è che la cosa si presenta in maniera random, ossia stesso host su stesso AS (esempio BT) nel 90% dei casi da filtered ma nel 5% dei casi raramente da la porta regolarmente aperta. Impazzisco, perchè queta cosa non ha alcun senso, soprattuto perchè il ping va sempre a buon fine, cosa che esclude problemi di routing a livello BGP.
Ovviamente la prima cosa che faccio terminati i mei test è stato contattare il supporto TIM Comunica, che fortunatamente ha un numero dedicato e non si passa da 187 o 191, anche perchè il router, un Huawei AR129 è loro e gestito in maniera inderogabile da loro in tutto, policy comprese. Una volta riuscito a spiegare e convincerli della problematica viene aperta la segnalazione e vengo ricontattato da Network di TIM. Fun fact, la prima cosa che mi dice il tecnico di Network è: la problematica che riporta lei è impossibile che si verifichi, è semplicemente una cosa impossibile. Gli spiego con calma che per quanto impossibile sta succedendo e gli mostro gli nmap effettuati e gli do la possibilità di farne anche lui live da host esteri. Riscontra anche lui il problema e inizia una lunga, anzi lunghissima giornata di test. Proviamo a cambiare Subnet IP assegnataci, nulla, proviamo a cambiare direttamente la classe della Subnet IP assegnataci, nulla. Effettua un upgrade e ripristino del firmware del router, nulla. Effettua un cambio di porta, ne proviamo varie, nulla. Alle 18, dopo una giornata di test, l'ultimo disperato tentativo, bypassare il router mettendo un IP in bridge su una porta fisica, esponenendo così l'host a internet direttamente, e taac, funziona, tutto va regolarmente. Proviamo allora a rimettere le cose come erano prima ma cambiando il tipo di nat, ad esempio NAT 1:1, nulla, tutto sempre bloccato dall'estero.
L'interpretazione della cosa da parte del tecnico è che evidentemente il Huawei AR129 non riesce a gestire correttamente il NAT, nessun tipo di NAT che abbiamo provato, e che quindi quando la latenza diventa leggermente maggiore (ad esempio per una connessione da un AS estero e non da un AS italiano) manda la connessione in timeout risultando in una porta filtrata. Secondo lo specialista è dovuto ad una errata interpretazione delle RFC da parte di Huawei.
Soluzione proposta da TIM? Cambio di router dall'AR129 ad un Tiesse Imola ed incrociare le dita che le cose così funzionino, anche se lo specialista non nutre grandi speranze. Altre soluzioni? Usare un router Cisco, solo che TIM non può offrircelo perchè di fascia superiore. Quindi diventa un problema nostro...

l'idea che mi è venuta è farmi fare un bridge di due IP su due porte LAN e usare un USG-3P come router per gestire il NAT di quei due IP e i server che ci starano dietro. Solo che non sono sicuro che la soluzione sia proprio il top.

Voi che ne pensate di tutta questa storia? Pensate che lo specialista abbia ragione e il problema sia il Huawei? Avete altre idee su come potere risolvere? Pensate che la mia idea possa reggere?

Grazie in anticipo

    P1R4NH4 Fai chiamare il commerciale Tim per provare ad avere un upgrade al Cisco “aggratis” 😀

      Max6502 Allora, la cosa si fa in realtà molto molto più interessante. Oggi vengono a fare il cambio Huawei con Tiesse Imola. Già il tecnico fisico che è venuto appena gli spiego la situazione esordisce con: impossibile! Arrieccoci... gli dimostro il tutto e si rassegna anche lui. Cambia il router, facciamo alcune prove e nulla, zero, nada, non va. Richiama lui direttamente Network, che gli dice di lasciare il Tiesse e andarsene che ora ci lavorano loro da remoto. Altra giornata al telefono con network, prove su prove. Però stavolta il Tiesse permette di fare monitoraggio delle porte. Quello che vedono è il Sync e basta. Il pacchetto dall'estero arriva e il router decide di non rispondere e la connessione va in timeout. Fine, non c'è altro, solo il sync. Network sempre più basito controlla anche altri clienti con router Tiesse e huawei e profilo tim uguale e taac, TUTTI gli altri clienti TIM Business su cui provano hanno lo STESSO problema.
      Ora domani mandano qualcuno per ulteriori test in locale, ma non ci stanno a capire più niente. Sembra un prroblema che riguarda tutti gli utenti TIM di questo tipo a livello nazionale e se ne stanno accorgendo ora.
      Intanto anche loro si stanno passando una mano sulla coscienza e vorrebbero provare a ricambiare il router mettendo il Cisco, solo che non c'è a magazzino nell'immediato. Comunque network sembrava meno convinto che il problema sia il router, visto che si presenta su entrambi i modelli di brand diversi.
      Vedremo domani...

        P1R4NH4 . Comunque network sembrava meno convinta che il problema sia il router presentandosi su entrambi i modelli di brand diversi.

        Infatti dalla descrizione che hai fatto sembrerebbe più l'effetto di qualche firewall/filtro anti-ddos, che di una implementazione errata lato CPE/router

        Visto che sospetti che il problema sia la latenza alta, hai provato a fare le prove da/verso una sim 4G?

          P1R4NH4 Ma hai di mezzo NAT 1:1 oppure la subnet ti viene ruotata direttamente ?

            handymenny in realtà il discorso latenza lo sospettava network di tim per via del modo in cui quei router gestiscono il NAT e ossia con un tunnelling virtuale interno. Ma in realtà sul Tiesse si vede chiaramente che il router ha il pacchetto in ingresso e non risponde. C'è solo il sync. Hanno inoltre visto che i pacchetti da AS italiane sono leggermente più piccoli di quelli da AS estere, per essere precisi è l'MSS ad essere più grande da AS estere.
            Network di TIM mi assicura al 100% che nella loro infrastruttura di routing non ci sono firewall o altri filtri, ergo impossibile che qualche apparato faccia il DROP. Comunque in effetti qualuque sim italiana in 4G si connette senza problemi, le rogne iniziano dall'estero.

            Matteo_Mabesolani No, la subnet dovrebbe essere ruotata direttamente da tim sul router, infatti il primo indirizzo è di rete e l'ultimo è di broadcast, quindi dovrebbe essere direttamente.

              P1R4NH4 Hanno inoltre visto che i pacchetti da AS italiane sono leggermente più piccoli di quelli da AS estere, per essere precisi è l'MSS ad essere più grande da AS estere.

              Interessante, hanno provato ad abbassarlo sul router? O hai provato tu ad abbassarlo dall'altro capo?

                handymenny Hanno provato ad alzare l'MSS sul router e in quel caso il router risponde e gira la richiesta al server che sta in NAT, ma a quel punto, sempre da log del Tiesse, è il server a non rispondere al forward locale del router.
                Non saprei come abbassare l'MSS dall'altro capo trattsandosi di una semplice richiesta via browser sulla 80. O se è possibile farlo non ne sono a conoscenza io, che ci starebbe eh.

                handymenny Infatti dalla descrizione che hai fatto sembrerebbe più l'effetto di qualche firewall/filtro anti-ddos, che di una implementazione errata lato CPE/router

                il discorso router era saltato fuori quando ieri girando un ip pubblico direttamente al server, senza nat, tutto andava senza problemi.

                  Di che valori di MSS parliamo ?
                  Sul router c’è un comando per aggiustare l’MSS in caso

                    gandalf2016
                    non so dirti di preciso che valori erano, mi hanno detto solo che erano leggermente superiori da AS estero.
                    Il comando c'è e infatti l'hanno usato per aumentare l'MSS sul router e questo ha iniziato a rispondere, ma comunque il forwarding non avviene perchè, secondo il Tiesse, il server web non risponde. Insomma nulla di fatto, dicono che il comportamento è assolutamente anomalo e che non dovrebbe comunque fare così.
                    Purtroppo il discorso di fondo è che io non posso mettere le mani sul router che deve essere, purtroppo inderogabilmente, gestito da Tim.

                    P1R4NH4 No, la subnet dovrebbe essere ruotata direttamente da tim sul router, infatti il primo indirizzo è di rete e l'ultimo è di broadcast, quindi dovrebbe essere direttamente.

                    Ok, ergo non hai NAT di mezzo.

                    P1R4NH4 il discorso router era saltato fuori quando ieri girando un ip pubblico direttamente al server, senza nat, tutto andava senza problemi.

                    Non ho capito questo pezzo: dando un IP pubblico al server quest ultimo risponde?

                      Matteo_Mabesolani esatto, ossia se diciamo al router di fare un semplice bridge IPv4 Esterno su Porta ETH GE0, quindi configurando il server direttamente con il pubblico e quindi non usando alcun tipo di NAT interna, si, funziona tutto in quel caso.

                        P1R4NH4 la problematica che riporta lei è impossibile che si verifichi, è semplicemente una cosa impossibile

                        Manco li caniii

                        P1R4NH4 mettendo un IP in bridge su una porta fisica, esponenendo così l'host a internet direttamente, e taac, funziona

                        Io avrei già messo un secondo router in cascata e assegnato tutto a lui se possibile. Lavorare così non si può.

                        P1R4NH4 satto, ossia se diciamo al router di fare un semplice bridge IPv4 Esterno su Porta ETH GE0, quindi configurando il server direttamente con il pubblico e quindi non usando alcun tipo di NAT interna, si, funziona tutto in quel caso.

                        Non mi è ancora chiaro: tu avrai la punto-punto con il POP e dietro questa punto punto la tua network pubblica assegnata. La situazione in cui tutto funziona è quella in cui il tuo server ha un indirizzo pubblico della tua network pubblica o della punto-punto ? Perchè il NAT non c'è in nessun caso. Magari fai un disegno in modo da capire.

                        • P1R4NH4 ha risposto a questo messaggio
                        • cdman ha messo mi piace.

                          Matteo_Mabesolani Si, la condizione in cui funziona è quella in cui il server stesso non usa un ipv4 interno, ossia 192.168.x.x ma usa direttamente uno degli indirizzi pubblici, quindi una porta del router in bridge e il server che usa ip pubblico e come gateway il pubblico del router.
                          Se non sono stato chiaro dimmelo e cerco di spiegarmi con un grafico magari.

                            P1R4NH4 Come gateway in bridge usi quale IP esattamente? L'IP pubblico della punto-punto lato router o lato Telecom? Perche' solo nel secondo caso sarebbe in qualche modo bridged "per davvero", nel primo caso lo chiamano commercialmente "bridge" ma c'e' comunque il loro router che fa routing, solo che e' senza NAT.

                            (Il secondo caso col bridge "vero" in layer2 sarebbe possibile solo se la punto-punto e' in IPoE e non in PPPoE, e se ti mettono una rotta /32 specifica lato loro che bypassa il router, mi sembra un accrocco strano "che non farebbero" ma pur sempre tecnicamente possibile, e se stanno andando a tentativi, tutto puo' essere... Altrimenti se non e' cosi' si passa per forza sempre dal router in layer3...)

                            Puo' darsi sia veramente un bug dell'implementazione del NAT (magari dell'accelerazione hardware/offloading), non sarebbe certo una novita', anzi...

                            Puoi fare un mtr "nattato" e uno "bridgeato" e vedere come cambiano?

                              P1R4NH4 Si, la condizione in cui funziona è quella in cui il server stesso non usa un ipv4 interno, ossia 192.168.x.x ma usa direttamente uno degli indirizzi pubblici, quindi una porta del router in bridge e il server che usa ip pubblico e come gateway il pubblico del router.

                              In realtà non è in bridge probabilmente, ma sulla subnet pubblica. Sarebbe meglio facessi un disegno, se hai voglia.

                              LATIITAY Come gateway in bridge usi quale IP esattamente? L'IP pubblico della punto-punto lato router o lato Telecom? Perche' solo nel secondo caso sarebbe in qualche modo bridged "per davvero", nel primo caso lo chiamano commercialmente "bridge" ma c'e' comunque il loro router che fa routing, solo che e' senza NAT.

                              Esatto, è quello che sto cercando di capire anche io.

                              LATIITAY Il secondo caso col bridge "vero" in layer2 sarebbe possibile solo se la punto-punto e' in IPoE e non in PPPoE

                              Solitamente su TIM questi circuiti non usano PPPoE, hai una punto punto con maschera /31 tra il tuo router e il POP.

                                LATIITAY Come gateway in bridge usi quale IP esattamente? L'IP pubblico della punto-punto lato router o lato Telecom? Perche' solo nel secondo caso sarebbe in qualche modo bridged "per davvero", nel primo caso lo chiamano commercialmente "bridge" ma c'e' comunque il loro router che fa routing, solo che e' senza NAT.

                                Si tratta sicuramente del primo caso, nessun NAT, ma il router fa il rouiting.

                                Matteo_Mabesolani Esatto, è quello che sto cercando di capire anche io.

                                spero di avere chiarito il discorso bridge, scusa se sono stato poco chiaro prima.

                                In ogni caso sono tornati, abbiamo fatto varie prove. si vedeva solo il pacchetto SYN inoltrato alcune volte e poi il server dava il FIN. Analizzando i pacchetti quelli che generavano il FIN risultavano sotto la parte TCP taggati come SYN inompleto. Problema rientrato mettendo il Cisco 897VA, quindi direi che era un problema del router. In realtà nenanche loro se lo spiegano, ma tant'è che con il Cisco funziona...

                                Grazie a tutti per l'aiuto!

                                  P1R4NH4 Son contento si sia risolto, vai a capire cosa succedeva prima. A mio parere trattasi di configurazione: magari su Cisco hanno più la mano e sanno configurare tutte le opzioni, sugli altri un po' meno (?).

                                    • [cancellato]

                                    P1R4NH4 Cisco 897VA

                                    Fammi capire, ti hanno montato ora un "coso" andato in EoS tre anni fa e lo spacciano per "categoria superiore"? Annamobbene...

                                    Per carità se funziona funziona, ma...

                                      Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                                      P.I. IT16712091004 - info@fibraclick.it

                                      ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile