[jack.mauro]

Ciao a tutti,
Io ho una configurazione di rete semplificabile come rappresentato nella seguente immagine:


Il router A è un DGA4132 Tim con root e gui sbloccata.
Sul router A ho aggiunto le seguenti route statiche, utilizzando la GUI:
   route add -net 192.168.12.0 netmask  255.255.255.0 gw 192.168.11.53
Il "Router" B è una VM con un VPN server, ma ai fini del problema è assimilabile ad un rotuer fisico.

Se dal client windows C provo a pingare un host sulla rete D, ottengo risposta come atteso,
Anche eseguendo un traceroute ottengo la risposta attesa
    Tracing route to 192.168.12.20 over a maximum of 30 hops
      1    14 ms     5 ms     2 ms  192.168.11.254
      2    11 ms     4 ms     2 ms  192.168.11.53
      3    53 ms    42 ms    43 ms  192.168.12.99
      4    52 ms    43 ms    43 ms  192.168.12.20
    Trace complete.

Tuttavia se cerco di accedere a qualsiasi risorsa, la connessione non va a buon fine: la connessione TCP sembra aprirsi ma poi non avviene lo scambio dati e il tutto cade per timeout.

Se inserisco sul client C una route statica come la seguente:
   ROUTE ADD 192.168.12.0 MASK 255.255.255.0 192.168.11.53
allora tutto funziona, ma vorrei evitare di dover aggiungere rotte su ogni device...

Se sostituisco il router A con un Linksys WRT610N (DD-WRT) con pari configurazione, tutto funziona.

Ho provato a disabilitare il firewall del router A DGA4132 tramite la GUI ma non ho notato cambiamenti. (anche perché l'impostazione controlla giusto qualche regoletta minore).

Secondo voi quale può essere il problema? Io ho pensato a:
- MTU (il ping piccolo passa, gli altri pacchetti grandi no)
- Firewall (Potrebbe in qualche modo essere bloccato il routing asimmetrico)
- Firewall bis (Potrebbe essere bloccato tutto intra-zone LAN to LAN)

Qualcuno ha avuto problemi simili o qualche idea da suggerirmi?

[fabiobassa]

1) - MTU (il ping piccolo passa, gli altri pacchetti grandi no) NO!! altrimenti non ti funzionerebbe con le rotte statiche

2) - Firewall (Potrebbe in qualche modo essere bloccato il routing asimmetrico) Non capisco perche parli di routing asimmetrico : tutto entra ed esce dalla vpn dunque è simmetrico

Ho una mia piccola idea ma non so se è giusta: ma se da rete d accedi a c funziona ?
se funziona è perche da qualche parte stai nattando la 10 e la 172 !!!

Perche il pacchetto che arriva da d ha come campo sorgente 192.168.12.x oppure 10.x.x.x oppure 172.x.x.x. adesso il problema è che queste altre due rotte che sono le risorse che ti interessano al 4132 sono sconosciute . l'unica rotta conosciuta è la 192.168.12.x
percui il ping verso 192.168.12.20 va... ma le risorse se sono 10.x.x.x o se sono 172.x.x.x sono sconosciute

prova ad aggiungere nel 4132 anche le rotte 10 e 172 sempre con gateway 192.168.11.53

[jack.mauro]

Ciao, riguardo le rotte 172.x.x.x e 10.x.x.x sono presenti, le avevo tralasciate per semplificare l'esempio.

Il tuo post mi ha convinto ad installare wireshark sia su C che su un web server in D, e vedo succedere questo:
1) C invia a D un pacchetto TCP SYN per aprire la connessione. (il pacchetto transita attraverso A che lo redirige a B).
2) D invia a C un pacchetto TCP SYN,ACK. (il pacchetto arriva da D, attraversa B ed arriva a C senza attraversare A).
3) C invia a D un pacchetto TCP ACK, ma D non lo riceve. Poiché C invia il paccheto ad A e questo non sa che la connessione è stata stabilita dato che il pacchetto 2 non è transitato attraverso di lui, quindi lo droppa.

Ho provato ad esaminare le regole di iptables del router e le sue configurazioni.
in /etc/config/firewall trovo:
config defaults
        option syn_flood '1'
        option drop_invalid '1'

che inseriscono, tra il resto, anche le seguenti regole:
-A dosprotect ! -s 0.0.0.0/32 -m rpfilter --invert -j rpfilter_DROP
-A FORWARD -m conntrack --ctstate INVALID -m comment --comment "!fw3" -j DROP

Entrambe le opzioni mi droppano i pacchetti, la prima perché controlla il reverse path del pacchetto (routing asimmetrico) e la seconda perché controlla lo stato della connessione TCP (non valida perché il router non ha mai visto il SYN ACK).

Mettendo le opzioni a 0 tutto funziona, ma perdo le protezioni sulla WAN.

La mia soluzione definitiva è quindi stata di aggiungere queste righe al file /etc/firewall.user:
iptables -t raw -I dosprotect -s 192.168.11.0/24 -d 192.168.0.0/16 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t filter -I FORWARD -s 192.168.11.0/24 -d 192.168.0.0/16 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t raw -I dosprotect -s 192.168.11.0/24 -d 172.16.0.0/12 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t filter -I FORWARD -s 192.168.11.0/24 -d 172.16.0.0/12 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t raw -I dosprotect -s 192.168.11.0/24 -d 10.0.0.0/8 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT
iptables -t filter -I FORWARD -s 192.168.11.0/24 -d 10.0.0.0/8 -i br-lan -m comment --comment "!fw3: static routes" -j ACCEPT

Così facendo i pacchetti vengono accettati prima dei test di reverse path e stateful inspection e tutto funziona correttamente. Spero queste info possano essere utili anche ad altri possessori del DGA4130/DGA4132

Ciao e grazie!

[fabiobassa]

@jack.mauro
Bene, anche se partita da una considerazione iniziale sbagliata, ti ha dato l'input per analizzare  piu a fondo la questione.

Lieto tu abbia risolto