[Marvel]

Nella regola sopra hai inserito "wanw" invece di "wan2"

Cavolo, hai ragione. Ho corretto e riavviato. Continua a non funzionare il port forwarding, ma lo immaginavo poiché avevo già provato ieri.

Quando guardi l'output ti iptables non puoi fare grep in quel modo, cerca la riga "Chain >nome della chain>", quello che devi guardare è lì sotto. Se usi grep come hai fatto vedi solo le regole che puntano A quella chain e non quelle da cui la chain è composta.

Rifaccio i test.

#POSTEDIT
@LuKePicci , hai ragione, prima ho fatto una scemenza colossale, immagino la grossa risata che ti sei fatto, di seguito i valori corretti tentando di accedere all'ip pubblico di wan 2:

In questa chain i contatori aumentano: iptables -L zone_wan2_forward -n -v -t filter

Codice: [Seleziona]

Chain zone_wan2_forward (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   32  1920 forwarding_wan2_rule  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3: user chain for forwarding */
   32  1920 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT /* !fw3: Accept port forwards */
    0     0 zone_wan2_dest_DROP  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3 */

In questa chain invece no: iptables -L forwarding_wan2_rule -n -v -t filter

Codice: [Seleziona]

Chain forwarding_wan2_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination

ma la stessa cosa accade per la rispettiva chain su wan: iptables -L forwarding_wan_rule -n -v -t filter

Codice: [Seleziona]

Chain forwarding_wan_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination


Rifai i test facendo il tcpdump su br-lan2

Ok.

#POSTEDIT2
Allora sul sito https://www.yougetsignal.com/tools/open-ports/ ho inserito ip pubblico di wan2 ed ho fatto testare la porta 80, il sito mi dice che la porta è chiusa, sul router ho dato il comando:
tcpdump -pnvvi br-lan2 port 80
ed in effetti qualcosa succede:

Codice: [Seleziona]

tcpdump: listening on br-lan2, link-type EN10MB (Ethernet), capture size 262144 bytes
17:37:50.234104 IP (tos 0x0, ttl 52, id 9180, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45577 > 192.168.0.3.80: Flags [S], cksum 0x9c7e (correct), seq 2466117550, win 14600, options [mss 1360,sackOK,TS val 1996149874 ecr 0,nop,wscale 8], length 0
17:37:50.236252 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45577: Flags [S.], cksum 0x0e36 (correct), seq 722364025, ack 2466117551, win 28960, options [mss 1460,sackOK,TS val 1885208 ecr 1996149874,nop,wscale 7], length 0
17:37:51.232522 IP (tos 0x0, ttl 52, id 9181, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45577 > 192.168.0.3.80: Flags [S], cksum 0x9b84 (correct), seq 2466117550, win 14600, options [mss 1360,sackOK,TS val 1996150124 ecr 0,nop,wscale 8], length 0
17:37:51.234558 IP (tos 0x0, ttl 52, id 56624, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45579 > 192.168.0.3.80: Flags [S], cksum 0x725a (correct), seq 2876770396, win 14600, options [mss 1360,sackOK,TS val 1996150124 ecr 0,nop,wscale 8], length 0
17:37:51.236637 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45577: Flags [S.], cksum 0x0dd2 (correct), seq 722364025, ack 2466117551, win 28960, options [mss 1460,sackOK,TS val 1885308 ecr 1996149874,nop,wscale 7], length 0
17:37:51.238799 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45579: Flags [S.], cksum 0xabeb (correct), seq 871011679, ack 2876770397, win 28960, options [mss 1460,sackOK,TS val 1885308 ecr 1996150124,nop,wscale 7], length 0
17:37:52.232040 IP (tos 0x0, ttl 52, id 56625, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45579 > 192.168.0.3.80: Flags [S], cksum 0x7160 (correct), seq 2876770396, win 14600, options [mss 1360,sackOK,TS val 1996150374 ecr 0,nop,wscale 8], length 0
17:37:52.234026 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45579: Flags [S.], cksum 0xab87 (correct), seq 871011679, ack 2876770397, win 28960, options [mss 1460,sackOK,TS val 1885408 ecr 1996150124,nop,wscale 7], length 0
17:37:52.237278 IP (tos 0x0, ttl 53, id 44682, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45580 > 192.168.0.3.80: Flags [S], cksum 0xbef1 (correct), seq 3981670637, win 14600, options [mss 1360,sackOK,TS val 1996150375 ecr 0,nop,wscale 8], length 0
17:37:52.239250 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45580: Flags [S.], cksum 0x2c60 (correct), seq 752052277, ack 3981670638, win 28960, options [mss 1460,sackOK,TS val 1885408 ecr 1996150375,nop,wscale 7], length 0
17:37:52.630952 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45577: Flags [S.], cksum 0x0d46 (correct), seq 722364025, ack 2466117551, win 28960, options [mss 1460,sackOK,TS val 1885448 ecr 1996149874,nop,wscale 7], length 0
17:37:53.230963 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45580: Flags [S.], cksum 0x2bfc (correct), seq 752052277, ack 3981670638, win 28960, options [mss 1460,sackOK,TS val 1885508 ecr 1996150375,nop,wscale 7], length 0
17:37:53.237237 IP (tos 0x0, ttl 53, id 44683, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45580 > 192.168.0.3.80: Flags [S], cksum 0xbdf7 (correct), seq 3981670637, win 14600, options [mss 1360,sackOK,TS val 1996150625 ecr 0,nop,wscale 8], length 0
17:37:53.239331 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45580: Flags [S.], cksum 0x2bfc (correct), seq 752052277, ack 3981670638, win 28960, options [mss 1460,sackOK,TS val 1885508 ecr 1996150375,nop,wscale 7], length 0
17:37:53.430984 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45579: Flags [S.], cksum 0xab0f (correct), seq 871011679, ack 2876770397, win 28960, options [mss 1460,sackOK,TS val 1885528 ecr 1996150124,nop,wscale 7], length 0
17:37:54.630955 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45577: Flags [S.], cksum 0x0c7e (correct), seq 722364025, ack 2466117551, win 28960, options [mss 1460,sackOK,TS val 1885648 ecr 1996149874,nop,wscale 7], length 0
17:37:55.230979 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45580: Flags [S.], cksum 0x2b34 (correct), seq 752052277, ack 3981670638, win 28960, options [mss 1460,sackOK,TS val 1885708 ecr 1996150375,nop,wscale 7], length 0
17:37:55.430977 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45579: Flags [S.], cksum 0xaa47 (correct), seq 871011679, ack 2876770397, win 28960, options [mss 1460,sackOK,TS val 1885728 ecr 1996150124,nop,wscale 7], length 0
17:37:58.630983 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45577: Flags [S.], cksum 0x0aee (correct), seq 722364025, ack 2466117551, win 28960, options [mss 1460,sackOK,TS val 1886048 ecr 1996149874,nop,wscale 7], length 0
17:37:59.230972 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45580: Flags [S.], cksum 0x29a4 (correct), seq 752052277, ack 3981670638, win 28960, options [mss 1460,sackOK,TS val 1886108 ecr 1996150375,nop,wscale 7], length 0
17:37:59.431000 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45579: Flags [S.], cksum 0xa8b7 (correct), seq 871011679, ack 2876770397, win 28960, options [mss 1460,sackOK,TS val 1886128 ecr 1996150124,nop,wscale 7], length 0
17:38:06.631084 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45577: Flags [S.], cksum 0x07ce (correct), seq 722364025, ack 2466117551, win 28960, options [mss 1460,sackOK,TS val 1886848 ecr 1996149874,nop,wscale 7], length 0
17:38:07.230997 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45580: Flags [S.], cksum 0x2684 (correct), seq 752052277, ack 3981670638, win 28960, options [mss 1460,sackOK,TS val 1886908 ecr 1996150375,nop,wscale 7], length 0
17:38:07.430969 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45579: Flags [S.], cksum 0xa597 (correct), seq 871011679, ack 2876770397, win 28960, options [mss 1460,sackOK,TS val 1886928 ecr 1996150124,nop,wscale 7], length 0
17:38:22.631029 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45577: Flags [S.], cksum 0x018e (correct), seq 722364025, ack 2466117551, win 28960, options [mss 1460,sackOK,TS val 1888448 ecr 1996149874,nop,wscale 7], length 0
17:38:23.430978 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45580: Flags [S.], cksum 0x2030 (correct), seq 752052277, ack 3981670638, win 28960, options [mss 1460,sackOK,TS val 1888528 ecr 1996150375,nop,wscale 7], length 0
17:38:23.630961 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.80 > 198.199.98.246.45579: Flags [S.], cksum 0x9f43 (correct), seq 871011679, ack 2876770397, win 28960, options [mss 1460,sackOK,TS val 1888548 ecr 1996150124,nop,wscale 7], length 0
^C
34 packets captured
34 packets received by filter
0 packets dropped by kernel

E se lo lascio girare un bel po ho:

Codice: [Seleziona]

tcpdump: listening on br-lan2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:01:48.314003 IP (tos 0x0, ttl 64, id 42146, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.3.51267 > 104.207.143.23.80: Flags [S], cksum 0xb15b (correct), seq 1543328122, win 29200, options [mss 1460,sackOK,TS val 2029016 ecr 0,nop,wscale 7], length 0
18:01:48.451802 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    104.207.143.23.80 > 192.168.0.3.51267: Flags [S.], cksum 0xe9af (correct), seq 32363405, ack 1543328123, win 28960, options [mss 1360,sackOK,TS val 451008658 ecr 2029016,nop,wscale 7], length 0
18:01:48.453855 IP (tos 0x0, ttl 64, id 42147, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.3.51267 > 104.207.143.23.80: Flags [.], cksum 0x8845 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 2029030 ecr 451008658], length 0
18:01:48.590008 IP (tos 0x0, ttl 51, id 2706, offset 0, flags [DF], proto TCP (6), length 52)
    104.207.143.23.80 > 192.168.0.3.51267: Flags [.], cksum 0x8764 (correct), seq 1, ack 90, win 227, options [nop,nop,TS val 451008796 ecr 2029030], length 0
18:01:48.591508 IP (tos 0x0, ttl 51, id 2707, offset 0, flags [DF], proto TCP (6), length 307)
    104.207.143.23.80 > 192.168.0.3.51267: Flags [P.], cksum 0x380e (correct), seq 1:256, ack 90, win 227, options [nop,nop,TS val 451008797 ecr 2029030], length 255: HTTP, length: 255
HTTP/1.1 200 OK
Date: Sun, 16 Feb 2020 17:01:48 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16
X-Powered-By: PHP/5.4.16
Content-Length: 32
Connection: close
Content-Type: text/html; charset=UTF-8

Current IP Address: yy.yy.yy.yy[!http]
18:01:48.593771 IP (tos 0x0, ttl 51, id 2708, offset 0, flags [DF], proto TCP (6), length 52)
    104.207.143.23.80 > 192.168.0.3.51267: Flags [F.], cksum 0x8663 (correct), seq 256, ack 90, win 227, options [nop,nop,TS val 451008797 ecr 2029030], length 0
18:01:48.595777 IP (tos 0x0, ttl 64, id 42149, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.3.51267 > 104.207.143.23.80: Flags [.], cksum 0x864c (correct), seq 90, ack 256, win 237, options [nop,nop,TS val 2029044 ecr 451008797], length 0
18:01:48.597747 IP (tos 0x0, ttl 64, id 42150, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.3.51267 > 104.207.143.23.80: Flags [F.], cksum 0x864a (correct), seq 90, ack 257, win 237, options [nop,nop,TS val 2029044 ecr 451008797], length 0
18:01:48.733001 IP (tos 0x0, ttl 51, id 2709, offset 0, flags [DF], proto TCP (6), length 52)
    104.207.143.23.80 > 192.168.0.3.51267: Flags [.], cksum 0x85c6 (correct), seq 257, ack 91, win 227, options [nop,nop,TS val 451008939 ecr 2029044], length 0

Io però non so interpretare questa situazione e non so nemmeno se ho eseguito correttamente il test, è questo ciò che volevi?

Intanto ti assicuro che il server su 192.168.0.3 è correttamente configurato al 100%, riesco a raggiungerlo in locale e se riconfiguro la rete e lo sposto su br-lan/pppoe-wan funziona correttamente anche il port-forwarding, al momento non c'è né firewall né altro che possa causare problemi, c'è solo apache in ascolto su 80 e 443.

#POSTEDIT3
Ti voglio far presente che ho anche notato una cosa alquanto strana.
Se su un pc collegato in br-lan/ppoe-wan apro il browser e inserisco l'indirizzo pubblico di ppoe-wan, allora vengo correttamente reindirizzato sul server presente in br-lan ed esposto tramite pppoe-wan.
Se su un pc collegato in br-lan/ppoe-wan apro il browser e inserisco l'indirizzo pubblico di ppoe-wan2, allora non succede assolutamente nulla e non riesco ad accedere al server presente in br-lan2 e che dovrebbe essere esposto tramite pppoe-wan2.
Se su un pc collegato in br-lan2/ppoe-wan2 apro il browser e inserisco l'indirizzo pubblico di ppoe-wan, allora vengo reindirizzato sulla pagina di accesso del router (?!?!?!?!?).
Se su un pc collegato in br-lan2/ppoe-wan2 apro il browser e inserisco l'indirizzo pubblico di ppoe-wan2, nemmeno succede nulla e non riesco ad accedere al server presente in br-lan2 e che dovrebbe essere esposto tramite pppoe-wan2.

[LuKePicci]

Ok allora il port forward funziona, i pacchetti arrivano al tuo server e lui risponde pure ma la risposta non arriva a destinazione (di preciso, arriva SYN, lui risponde SYN+ACK ma non arriva mai l'ACK finale). Ora se tu stessi facendo una SYN scan sarebbe anche normale, ma se il test dice che la porta non è aperta vuol dire che il SYN+ACK non gli arriva.

Sulle chain di forward è tutto ok, passi da zone_wan2_forward, entri in forwarding_wan2_rule che è vuota quindi torni in zone_wan2_forward e finisci in ACCEPT. A questo punto de guardi il counter in -iptables -t nat vedi la traduzione ma già sappiamo che funziona perchè abbiamo visto da tcpdump che la fa correttamente. Guardando invece il tcpdump fatto su pppoe-wan2 mentre tentavi di raggiungere il server in lan2 si vede che da lì non passa alcun SYN+ACK (puoi vedere dal test fatto su pppoe-wan cosa sarebbe dovuto apparire se fossero passati), il che mostra come effettivamente al port tester non arrivi nulla. Adesso prova a fare una cosa, rifai lo stesso test verso il server su lan2 via wan2, ma tieni aperto il tcpdump su pppoe-wan (la 1, non la 2). Voglio vedere se epr caso il SYN+ACK mancante finisce su quell'interfaccia. Se li vedì lì, allora è un problema su mwan. Se invece non sono nemmeno lì, allora si sono persi da qualche parte nel nat in uscita (che ha a che fare con la regola che ti ho fatto aggiungere), in tal caso per sapere che fine fanno seguili sui counter di iptables alla stessa maniera, prima sulla filter di lan2, poi sulla nat e poi sulla filter di wan2, per non uscire da nessuna parte dovranno andare a finire su qualche regola DROP.

Le cose strane che hai nominato sono in parte ragionevoli. Quando crei un port-forward lui ti crea anche le relative regole di reflection, cioè sono fatte in modo tale ce da pc in locale tu possa "raggiungere" un servizio su ip pubblico del router. E' come se applicasse non solo la regola NAT alle connessioni provenienti da wan ma anche a quelle provenienti da lan. In più lui cambia anche l'ip sorgente del traffico in se stesso. Quindi:
1- ok, ce lo aspettavamo
2 -ok, se c'è una regola di reflection per dirottare tali richieste direttamente in lan2, allora è normale che non accada nulla perchè le relative interfacce br-lan e br-lan2 sono in zone lan e lan2 isolate tra loro, se non ci fosse (ma c'è, me l'hai fatta vedere qualche post addietro) la regola di reflection avendo quel problema di "porta chiusa" è ragionevole che non funzioni
3- è ragionevole, sappiamo che la webui del router è in ascolto su br-lan all'ip del router, immagino che con reflection questo risultato sia ammissibile
4- questa non me la spiego, se ci fosse relfection dovrebbe funzionare a prescindere da mwan, senza reflection sarebbe normale che non funzioni

[Marvel]

Guardando invece il tcpdump fatto su pppoe-wan2 mentre tentavi di raggiungere il server in lan2 si vede che da lì non passa alcun SYN+ACK (puoi vedere dal test fatto su pppoe-wan cosa sarebbe dovuto apparire se fossero passati), il che mostra come effettivamente al port tester non arrivi nulla.

Non volermene, è da quando hai scritto che sto cercando di capire cosa avrei dovuto vedere sul tcpump2 di pppoe-wan2 se SYN+ACK fossero passati. Non riesco a capire la differenza tra i due tcpdump, di pppoe-wan e pppoe-wan2. Non che non mi fidi eh, sia chiaro, solo che mi piacerebbe capire.

Adesso prova a fare una cosa, rifai lo stesso test verso il server su lan2 via wan2, ma tieni aperto il tcpdump su pppoe-wan (la 1, non la 2). Voglio vedere se epr caso il SYN+ACK mancante finisce su quell'interfaccia. Se li vedì lì, allora è un problema su mwan. Se invece non sono nemmeno lì, allora si sono persi da qualche parte nel nat in uscita (che ha a che fare con la regola che ti ho fatto aggiungere), in tal caso per sapere che fine fanno seguili sui counter di iptables alla stessa maniera, prima sulla filter di lan2, poi sulla nat e poi sulla filter di wan2, per non uscire da nessuna parte dovranno andare a finire su qualche regola DROP.

Intanto scollego il server in br-lan/ppoe-wan e faccio il test che mi ha chiesto. Se lo lascio attivo credo possa falsare il test.

#POSTEDIT
O, ho fatto il test che mi hai chiesto, mi sono collegato su https://www.yougetsignal.com/tools/open-ports/, ho inserito l'ip pubblico di pppoe-wan2 e la porta 80, poi ho lanciato:
tcpdump -pnvvi pppoe-wan port 80

Codice: [Seleziona]

tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:22:23.986661 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59698: Flags [S.], cksum 0x5170 (correct), seq 322838223, ack 3448019863, win 28960, options [mss 1360,sackOK,TS val 192509 ecr 1998618361,nop,wscale 7], length 0
20:22:24.983180 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59698: Flags [S.], cksum 0x510d (correct), seq 322838223, ack 3448019863, win 28960, options [mss 1360,sackOK,TS val 192608 ecr 1998618361,nop,wscale 7], length 0
20:22:24.992530 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59699: Flags [S.], cksum 0xba9e (correct), seq 4211629845, ack 1012439588, win 28960, options [mss 1360,sackOK,TS val 192609 ecr 1998618612,nop,wscale 7], length 0
20:22:25.984306 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59699: Flags [S.], cksum 0xba3a (correct), seq 4211629845, ack 1012439588, win 28960, options [mss 1360,sackOK,TS val 192709 ecr 1998618612,nop,wscale 7], length 0
20:22:25.994318 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59702: Flags [S.], cksum 0xf536 (correct), seq 2856302113, ack 1888756652, win 28960, options [mss 1360,sackOK,TS val 192709 ecr 1998618862,nop,wscale 7], length 0
20:22:26.002812 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59699: Flags [S.], cksum 0xba39 (correct), seq 4211629845, ack 1012439588, win 28960, options [mss 1360,sackOK,TS val 192710 ecr 1998618612,nop,wscale 7], length 0
20:22:26.184311 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59698: Flags [S.], cksum 0x5094 (correct), seq 322838223, ack 3448019863, win 28960, options [mss 1360,sackOK,TS val 192729 ecr 1998618361,nop,wscale 7], length 0
20:22:26.984286 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59702: Flags [S.], cksum 0xf4d2 (correct), seq 2856302113, ack 1888756652, win 28960, options [mss 1360,sackOK,TS val 192809 ecr 1998618862,nop,wscale 7], length 0
20:22:26.993524 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59702: Flags [S.], cksum 0xf4d2 (correct), seq 2856302113, ack 1888756652, win 28960, options [mss 1360,sackOK,TS val 192809 ecr 1998618862,nop,wscale 7], length 0
20:22:28.184327 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59698: Flags [S.], cksum 0x4fcc (correct), seq 322838223, ack 3448019863, win 28960, options [mss 1360,sackOK,TS val 192929 ecr 1998618361,nop,wscale 7], length 0
20:22:28.584317 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59699: Flags [S.], cksum 0xb936 (correct), seq 4211629845, ack 1012439588, win 28960, options [mss 1360,sackOK,TS val 192969 ecr 1998618612,nop,wscale 7], length 0
20:22:28.984269 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59702: Flags [S.], cksum 0xf40a (correct), seq 2856302113, ack 1888756652, win 28960, options [mss 1360,sackOK,TS val 193009 ecr 1998618862,nop,wscale 7], length 0
20:22:32.184408 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59698: Flags [S.], cksum 0x4e3c (correct), seq 322838223, ack 3448019863, win 28960, options [mss 1360,sackOK,TS val 193329 ecr 1998618361,nop,wscale 7], length 0
20:22:32.584482 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59699: Flags [S.], cksum 0xb7a6 (correct), seq 4211629845, ack 1012439588, win 28960, options [mss 1360,sackOK,TS val 193369 ecr 1998618612,nop,wscale 7], length 0
20:22:32.984336 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59702: Flags [S.], cksum 0xf27a (correct), seq 2856302113, ack 1888756652, win 28960, options [mss 1360,sackOK,TS val 193409 ecr 1998618862,nop,wscale 7], length 0
20:22:40.184416 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59698: Flags [S.], cksum 0x4b1c (correct), seq 322838223, ack 3448019863, win 28960, options [mss 1360,sackOK,TS val 194129 ecr 1998618361,nop,wscale 7], length 0
20:22:40.584494 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59699: Flags [S.], cksum 0xb486 (correct), seq 4211629845, ack 1012439588, win 28960, options [mss 1360,sackOK,TS val 194169 ecr 1998618612,nop,wscale 7], length 0
20:22:40.984390 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59702: Flags [S.], cksum 0xef5a (correct), seq 2856302113, ack 1888756652, win 28960, options [mss 1360,sackOK,TS val 194209 ecr 1998618862,nop,wscale 7], length 0
20:22:56.184556 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59698: Flags [S.], cksum 0x44dc (correct), seq 322838223, ack 3448019863, win 28960, options [mss 1360,sackOK,TS val 195729 ecr 1998618361,nop,wscale 7], length 0
20:22:56.584566 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59699: Flags [S.], cksum 0xae46 (correct), seq 4211629845, ack 1012439588, win 28960, options [mss 1360,sackOK,TS val 195769 ecr 1998618612,nop,wscale 7], length 0
20:22:56.984453 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    yy.yy.yy.yy.80 > 198.199.98.246.59702: Flags [S.], cksum 0xe91a (correct), seq 2856302113, ack 1888756652, win 28960, options [mss 1360,sackOK,TS val 195809 ecr 1998618862,nop,wscale 7], length 0
^C
21 packets captured
21 packets received by filter
0 packets dropped by kernel
Dove yy.yy.yy.yy è effettivamente l'ip pubblico di pppoe-wan2.
Ma la cosa strana è che ho fatto questo test due volte, la prima volta il tcpdump risultava vuoto, la seconda volta mi ha dato questo.

Ho inoltre notato che se ad esempio faccio lo scan di una porta non aperta su una delle due wan e metto in ascolto tcpdump su quella porta, comunque ottengo qualcosa. Ad esempio qui ho testato la porta 82 su ip pubblico di pppoe-wan2, sul router ho lanciato:
tcpdump -pnvvi pppoe-wan2 port 82
ed ho ottenuto questo:

Codice: [Seleziona]

tcpdump: listening on pppoe-wan2, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:26:36.659187 IP (tos 0x0, ttl 53, id 30859, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.58255 > yy.yy.yy.yy.82: Flags [S], cksum 0xd77b (correct), seq 1049562417, win 14600, options [mss 1460,sackOK,TS val 1998681530 ecr 0,nop,wscale 8], length 0
20:26:37.657408 IP (tos 0x0, ttl 53, id 30860, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.58255 > yy.yy.yy.yy.82: Flags [S], cksum 0xd681 (correct), seq 1049562417, win 14600, options [mss 1460,sackOK,TS val 1998681780 ecr 0,nop,wscale 8], length 0
20:26:37.659124 IP (tos 0x0, ttl 54, id 42764, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.58262 > yy.yy.yy.yy.82: Flags [S], cksum 0x74d3 (correct), seq 3685667256, win 14600, options [mss 1460,sackOK,TS val 1998681780 ecr 0,nop,wscale 8], length 0
20:26:38.654436 IP (tos 0x0, ttl 53, id 5075, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.58266 > yy.yy.yy.yy.82: Flags [S], cksum 0xa8c1 (correct), seq 335438973, win 14600, options [mss 1460,sackOK,TS val 1998682030 ecr 0,nop,wscale 8], length 0
20:26:38.660518 IP (tos 0x0, ttl 54, id 42765, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.58262 > yy.yy.yy.yy.82: Flags [S], cksum 0x73d9 (correct), seq 3685667256, win 14600, options [mss 1460,sackOK,TS val 1998682030 ecr 0,nop,wscale 8], length 0
20:26:39.650948 IP (tos 0x0, ttl 53, id 5076, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.58266 > yy.yy.yy.yy.82: Flags [S], cksum 0xa7c7 (correct), seq 335438973, win 14600, options [mss 1460,sackOK,TS val 1998682280 ecr 0,nop,wscale 8], length 0
è normale?

[LuKePicci]

Il secondo è del tutto normale, sono i test in arrivo, sono tutti SYN, con nessuna risposta perchè su quella porta non c'è nulla in ascolto.

Il primo test invece sono tutti SYN-ACK... quelli che dovevano arrivare dall'altra parte, eccoli qua.

Effettivamente l'output di tcpdump così com'è è un po' illeggibile se non sai cosa stai cercando di preciso, ti conviene aggiungere l'opzione -w /tmp/cattura.pcap e aprire il file risultante in wireshark per vedere meglio cosa hai davanti.

E niente, per qualche ragione del tutto fuori dalla mia comprensione i pacchetti di risposta stanno finendo tutti sull'interfaccia sbagliata. Il colmo è che l'interfaccia viene selezionata correttamente, infatti il pacchetto viene fatto uscire con ip sorgente pari a quello di pppoe-wan2 ma viene comunque buttato sulla prima. Torno a dire che il problema è quel gateway identico sulle due connessioni. Non proverei a passare ad mwan3, nella docu fa comunque esempi che hanno un gateway diverso per ogni rotta quindi ho il leggero presentimento che non abbiamo mai gestito un caso del genere. Farei due cose: uno, scasserei le palle a quelli di mwan3 cercando di farmi dire se una situazione del genere è gestibile secondo loro, e due, proverei lo stesso test tenendo spenta pppoe-wan.

[Marvel]

Non ricordo con quale comando, ma ieri sono riuscito a controllare i mark che venivano assegnati alle due interfacce wan, ed arano lo stesso, quindi credo sia quasi normale quello che accade, non credi? E se provassi a mettere un mark diverso su wan2? Ieri c'ho provato ma sono andato a tentativi senza validi risultati.

Provo a ricordare come ho fatto ieri e posto tutto qui.

#POSTEDIT
Intanto cito da qui:
https://kb.kurgan.org/LinuxDebian/MultiWAN

Se serve il NAT entrante (per esempio, un host della LAN pubblica una porta sulle due WAN, in modo che da fuori, collegandosi a uno qualsiasi dei due ip pubblici, si raggiunga sempre lo stesso host della LAN) allora la cosa si complica un pochino. Dovremo infatti usare il modulo fwmark di iptables, e gestire i mark nelle regole di routing. Diciamo che vogliamo nattare la porta 25 (smtp) in ingresso, e mandarla a un server che sta in LAN.
Nel firewall dobbiamo fare il DNAT, e questo e` ovvio. Facendo due regole, una per interfaccia, dico al firewall che qualsiasi connessione entrante da fuori sulla 25 (e su tutte e due le WAN) venga mandata allo stesso host interno
Nel firewall però dobbiamo anche marcare con fwmark le connessioni che stiamo andando a nattare, allo scopo di poterle poi "ricondurre" alla giusta interfaccia WAN, ovvero per fare in modo che i pacchetti di risposta ad una connessione che entra dalla interfaccia WAN numero 1 vengano mandati fuori dalla interfaccia WAN numero 1 e non dall'altra (e viceversa ovviamente). Per farlo, ci sono 3 cose da fare; marcare le connessioni entranti (operazione che avviene nella table "mangle") distinguendo con un mark diverso quelle della interfaccia WAN 1 da quelle della WAN 2, e poi restorare il mark nei pacchetti "related, established" che tornano dalla LAN alla WAN, in modo che poi possiamo "dirigerli" verso la giusta interfaccia WAN usando una "ip rule".

Mi sembra proprio che nel mio caso i pacchetti di risposta ad una connessione che entra dalla interfaccia WAN numero 2 vengano mandati fuori dalla interfaccia WAN numero 1 e stando a quanto riportato è "normale" senza un mark corretto. Sbaglio? O ho capito male io?

[LuKePicci]

ip -4 rule

A me i marker non sono uguali, tu cosa intendi di preciso?

Codice: [Seleziona]

root@OpenWrt:~# ip -4 rule
0:      from all lookup prelocal
1:      from all lookup local
220:    from all lookup 220
1016:   from all iif vlan935_eth4 lookup main
1017:   from all iif pppoe-test lookup main
1018:   from all iif pppoe-wan lookup main
2016:   from all fwmark 0x10000000/0xf0000000 lookup main
2017:   from all fwmark 0x20000000/0xf0000000 lookup iptv
2018:   from all fwmark 0x30000000/0xf0000000 lookup main
3016:   from all fwmark 0x10000000/0xf0000000 unreachable
3017:   from all fwmark 0x20000000/0xf0000000 unreachable
3018:   from all fwmark 0x30000000/0xf0000000 unreachable
10000:  from 10.152.0.28 lookup main
10000:  from 62.11.174.217 lookup main
10000:  from 82.84.71.101 lookup iptv
20000:  from all to 10.152.0.28/21 lookup main
20000:  from all to 62.11.174.217 lookup main
20000:  from all to 82.84.71.101 lookup iptv
32766:  from all lookup main
32767:  from all lookup default
90029:  from all iif lo lookup main
90032:  from all iif lo lookup main
90033:  from all iif lo lookup iptv
root@OpenWrt:~#
Lasia perdere i marker, rimetti mano allo script che crea le default route di ppp, fai in modo che le default route appaiano fatte in questo modo (deve sparire la direttiva via _ip_gw_[/i) e dimmi se internet funziona ancora e se è cambiato qualcosa:

Codice: [Seleziona]

default dev pppoe-wan  proto static

[LuKePicci]

Secondo me l'esempio che hai riportato non c'entra nel tuo caso, serve quando ad uno stesso pc (ad esempio in lan2) sia concesso di raggiungere internet attraverso sia wan che wan2. A quel punto esiste il problema di "rilegare" il traffico stabilito su una connessione sulla medesima. Questa è una cosa che MultiWAN non faceva di suo, ma che mwan3 fa con un parametro specifico. Se questo fosse il tuo caso, vedresti uscire da pppoe-wan i pacchetti SYN-ACK di risposta a quelli ricevuti da pppoe-wan2 ma li vedresti uscire con ip sorgente uguale a quello pubblico di wan e non wan2 (come si vede nel tuo dump).

Il tuo caso è più subdolo, lui ha capito da quale interfaccia uscire, del resto ne ha una sola, ma non lo fa.

[Marvel]

A me i marker non sono uguali, tu cosa intendi di preciso?

Ok, con questo comando anche a me risultano differenti. Ieri sera avevo visto qualcosa che mi aveva fatto credere di avere gli stessi mark su wan e wan2, sul router non c'è l'history e non ricordo proprio che avevo fatto. Sicuramente però avrò frainteso qualcosa.

Lasia perdere i marker, rimetti mano allo script che crea le default route di ppp, fai in modo che le default route appaiano fatte in questo modo (deve sparire la direttiva via _ip_gw_[/i) e dimmi se internet funziona ancora e se è cambiato qualcosa:

Codice: [Seleziona]

default dev pppoe-wan  proto static

Ok, fatto a mano al momento senza script. Fatto sia per pppoe-wan che per pppoe-wan2. Internet funziona, navigo, ma per l'accesso al server non è cambiato nulla.

ip route show

Codice: [Seleziona]

default dev pppoe-wan proto static scope link metric 10
192.168.0.0/24 dev br-lan2 proto kernel scope link src 192.168.0.1
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
192.168.100.1 dev pppoe-wan proto kernel scope link src xx.xx.xx.xx
192.168.168.0/25 dev wl0_1 proto kernel scope link src 192.168.168.1
192.168.168.128/25 dev wl1_1 proto kernel scope link src 192.168.168.129

ip route show table main2

Codice: [Seleziona]

default dev pppoe-wan2 proto static scope link metric 20
192.168.100.1 dev pppoe-wan2 proto kernel scope link src yy.yy.yy.yy metric 20


Farei due cose: uno, scasserei le palle a quelli di mwan3 cercando di farmi dire se una situazione del genere è gestibile secondo loro, e due, proverei lo stesso test tenendo spenta pppoe-wan.

Avevo dimenticato di risponderti a questo, ieri avevo già provato a spegnere pppoe-wan per vedere se riuscivo ad accedere al server su pppoe-wan2, ma nulla, non riuscivo.

[LuKePicci]

E dove vanno a finire quei pacchetti quando pppoe-wan è spenta? Se non funziona vuol dire che non vanno né in pppoe-wan (Spenta) nè in pppoe-wan2 (tcpdump ti dovrebbe dare la conferma), quindi dovresti vederli finire in qualche regola DROP in iptables. Scopri quale.

[Marvel]

Ok, allora con wan spenta, test della porta 80 su pppoe-wan2 dal solito sito, lancio sul router:
tcpdump -pnvvi pppoe-wan2 port 80

Codice: [Seleziona]

23:26:20.917560 IP (tos 0x0, ttl 54, id 34892, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.53254 > yy.yy.yy.yy.80: Flags [S], cksum 0x25c4 (correct), seq 3708686371, win 14600, options [mss 1460,sackOK,TS val 2001377634 ecr 0,nop,wscale 8], length 0
23:26:20.925563 IP (tos 0x0, ttl 53, id 4543, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.53259 > yy.yy.yy.yy.80: Flags [S], cksum 0x4d6c (correct), seq 1017612509, win 14600, options [mss 1460,sackOK,TS val 2001377634 ecr 0,nop,wscale 8], length 0
23:26:21.916706 IP (tos 0x0, ttl 53, id 4544, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.53259 > yy.yy.yy.yy.80: Flags [S], cksum 0x4c72 (correct), seq 1017612509, win 14600, options [mss 1460,sackOK,TS val 2001377884 ecr 0,nop,wscale 8], length 0
23:26:26.295716 IP (tos 0x0, ttl 54, id 46326, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.53273 > yy.yy.yy.yy.80: Flags [S], cksum 0x4417 (correct), seq 2671061589, win 14600, options [mss 1460,sackOK,TS val 2001378979 ecr 0,nop,wscale 8], length 0
23:26:27.294928 IP (tos 0x0, ttl 54, id 46327, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.53273 > yy.yy.yy.yy.80: Flags [S], cksum 0x431d (correct), seq 2671061589, win 14600, options [mss 1460,sackOK,TS val 2001379229 ecr 0,nop,wscale 8], length 0
23:26:27.296422 IP (tos 0x0, ttl 54, id 65050, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.53276 > yy.yy.yy.yy.80: Flags [S], cksum 0x9c90 (correct), seq 244146567, win 14600, options [mss 1460,sackOK,TS val 2001379229 ecr 0,nop,wscale 8], length 0
23:26:28.293733 IP (tos 0x0, ttl 54, id 65051, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.53276 > yy.yy.yy.yy.80: Flags [S], cksum 0x9b96 (correct), seq 244146567, win 14600, options [mss 1460,sackOK,TS val 2001379479 ecr 0,nop,wscale 8], length 0
23:26:28.302336 IP (tos 0x0, ttl 54, id 46001, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.53280 > yy.yy.yy.yy.80: Flags [S], cksum 0x8a0e (correct), seq 1852969766, win 14600, options [mss 1460,sackOK,TS val 2001379479 ecr 0,nop,wscale 8], length 0
23:26:29.296492 IP (tos 0x0, ttl 54, id 46002, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.53280 > yy.yy.yy.yy.80: Flags [S], cksum 0x8914 (correct), seq 1852969766, win 14600, options [mss 1460,sackOK,TS val 2001379729 ecr 0,nop,wscale 8], length 0

e vedo che ad incrementare sono i contatori in zone_wan2_src_DROP:

Codice: [Seleziona]

Chain zone_wan2_src_DROP (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   45  4714 DROP       all  --  pppoe-wan2 *       0.0.0.0/0            0.0.0.0/0            /* !fw3 */

#POSTEDIT
Ho riacceso wan, ho fatto lo stesso test di prima su wan2/porta80, ho notato che con tcpdump -pnvvi pppoe-wan port 80 ci sono nuovamente le stesse cose di prima di wan2, ed anche in questo caso il contatore di zone_wan2_src_DROP continua ad incrementarsi.

@LuKePicci , per me ora è tutto arabo, ho finito le idee e quindi sono prossimo ad alzare bandiera bianca, quando ti sarai stancato fammelo sapere e ci fermiamo, non voglio veramente farti perdere tempo.
Eventualmente mi compilo haproxy e uso lui per esporre entrambi i server sulle porte standard, anche se la soluzione della doppia wan sarebbe stata fantastica.

#POSTEDIT2
Vedo che anche i contatori di zone_wan_src_DROP non sono pari a zero.

Codice: [Seleziona]

Chain zone_wan_src_DROP (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   31  3098 DROP       all  --  pppoe-wan *       0.0.0.0/0            0.0.0.0/0            /* !fw3 */


[LuKePicci]

Ok, magari il prossimo fine settimana faccio qualche prova anch'io. che mmpbx avesse problemi di suo posso anche capirlo ma che un port forward vada in aceto in questo modo balordo è a dir poco assurdo. Ormai è una questione di principio.

Aspetta, ma in tutto questo tempo hai sempre tenuto questa in main2?

Codice: [Seleziona]

192.168.100.1 dev pppoe-wan2 proto kernel scope link src yy.yy.yy.yy metric 20
Prova a rispostarla dov'era in principio.

[Marvel]

Ok, magari il prossimo fine settimana faccio qualche prova anch'io. che mmpbx avesse problemi di suo posso anche capirlo ma che un port forward vada in aceto in questo modo balordo è a dir poco assurdo. Ormai è una questione di principio.

Ah, ma se tu non ti arrendi io ci continuo a sperare ed a provare, mi arrenderei solo perché non ho le competenze per risolvere da solo questo problema e non mi via di scocciarti così tanto. Pensa che mi ero ricompilato anche il kernel del serverino arm per poter aggiungere il supporto 8021q.

Aspetta, ma in tutto questo tempo hai sempre tenuto questa in main2?

Codice: [Seleziona]

192.168.100.1 dev pppoe-wan2 proto kernel scope link src yy.yy.yy.yy metric 20
Prova a rispostarla dov'era in principio.

Oggi è sempre stata lì, quindi durante tutti i nostri test. Ho fatto una stron*ata? Devo ripeterli?
Ieri però l'avevo messa dove era in principio e non era cambiato nulla, continuava a non funzionare.

P.S.: è molto complicato compilare in crosscompile per questo dispositivo utilizzando il toolchain di Ansuel (per compilarmi haproxy)? Sono solito compilare in crosscompile per i miei serverini arm e per i miei telefoni android ma non l'ho mai fatto per openwrt.

#POSTEDIT
Ho notato che alcune chain presenti per wan, non esistono per wan2, ad esempio la chain zone_wan_dest_REJECT, non esiste zone_wan2_dest_REJECT.

#POSTEDIT2
Ho rifatto al volo i test dopo aver rimesso al posto originale

Codice: [Seleziona]

192.168.100.1 dev pppoe-wan2 proto kernel scope link src yy.yy.yy.yy metric 20 non è cambiato nulla, stessi identici comportamenti che abbiamo notato fino ad ora.

[LuKePicci]

Non so dirti di preciso se potesse creare problemi, ma era comunque un qualcosa che avevamo toccato quindi volevo appurare che non fosse proprio quello il problema. Siccome lo spostarla non ha sortito alcun effetto io la rimetterei dov'era in origine in pianta stabile. Prova a individuare tutte le differenze tra le due zone in termini di chain, per avere qualcosa di tangibile devo provare in prima persona.

Comunque nell'output di tcpdump tu hai due righe per pacchetto, quello che guardo io è quel "Flags [ ..]" nella righe relative a tcp, che contiene il flag S (SYN) nel primo pacchetto inviato da entrambe le parti alla connessione, e l'identificativo del segmento riportato in ack. Il primo pacchetto della connessione è inviato da chi tenta di connettersi ed ha S settato ma non fa ack di nulla. Quello in risposta ha anche lui S settato ma fa ack del primo segmento appena ricevuto, il terzo in risposta a quest'ultimo ha solo ack del primo segmento inviato.
Per cui. questo era un SYN:

Codice: [Seleziona]

16:31:43.201678 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    xx.xx.xx.xx.80 > 198.199.98.246.42793: Flags [S.], cksum 0xc2d8 (correct), seq 1271775184, ack 2538660444, win 28960, options [mss 1452,sackOK,TS val 254551618 ecr 1995158099,nop,wscale 7], length 0questo era un SYN+ACK:

Codice: [Seleziona]

16:31:43.396143 IP (tos 0x0, ttl 54, id 20489, offset 0, flags [DF], proto TCP (6), length 52)
    198.199.98.246.42793 > xx.xx.xx.xx.80: Flags [.], cksum 0x6251 (correct), seq 1, ack 1, win 58, options [nop,nop,TS val 1995158149 ecr 254551618], length 0e questo è l'ACK con cui la connessione è ufficialmente aperta:

Codice: [Seleziona]

16:31:43.399216 IP (tos 0x0, ttl 54, id 20490, offset 0, flags [DF], proto TCP (6), length 52)
    198.199.98.246.42793 > xx.xx.xx.xx.80: Flags [F.], cksum 0x6250 (correct), seq 1, ack 1, win 58, options [nop,nop,TS val 1995158149 ecr 254551618], length 0

Il fatto che i SYNACK provenienti dal server su lan2 finissero su pppoe-wan non me lo spiego, potrebbe dipendere dal solito ordine di avvio delle interfacce o magari si è risolto togliendo il gw dalle defaultroute. Il fatto che con pppoe-wan spenta comunque tu abbia il problema è in un certo qual modo confortante, significa che c'è qualcosa di errato nelle config che si può sistemare. Quello che voglio provare a fare io è creare la seconda zona wan2 e vedere se ho anch'io problemi a fare forwarding su di essa. Proverò prima con una porta a caso su cui il router non è anch'esso in ascolto e vediamo che succede. Magari ci provo prima su un altro router openwrt puro.

[Marvel]

Non so dirti di preciso se potesse creare problemi, ma era comunque un qualcosa che avevamo toccato quindi volevo appurare che non fosse proprio quello il problema. Siccome lo spostarla non ha sortito alcun effetto io la rimetterei dov'era in origine in pianta stabile.

Fatto, rimessa in pianta stabile dove era, ho rimosso i permessi di esecuzione alls script ppp che la spostava.

Prova a individuare tutte le differenze tra le due zone in termini di chain, per avere qualcosa di tangibile devo provare in prima persona.

Ok, cerco ti trovare tutte le differenze tra le due zone in termini di chain, appena fatto ti posto tutto qui.

Comunque nell'output di tcpdump tu hai due righe per pacchetto, quello che guardo io è quel "Flags [ ..]" nella righe relative a tcp

Perfetto, ora è tutto chiaro, veramente non capivo come facevi a interpretare le informazioni. C'ho perso quasi un'ora ieri per provare a capirlo :-) Grazie mille, se non altro sto imparando molte cose per me nuove.

Il fatto che i SYNACK provenienti dal server su lan2 finissero su pppoe-wan non me lo spiego, potrebbe dipendere dal solito ordine di avvio delle interfacce o magari si è risolto togliendo il gw dalle defaultroute.

Ho rimosso il gw dalle defaultroute ed ho rifatto i test, i SYNACK provenienti dal server su lan2 finiscono ancora su pppoe-wan.

Il fatto che con pppoe-wan spenta comunque tu abbia il problema è in un certo qual modo confortante, significa che c'è qualcosa di errato nelle config che si può sistemare.

Speriamo, sarebbe fantastico se si riuscisse a sistemare il tutto, e probabilmente se si riuscisse a sistemare questa cosa potrebbe funzionare correttamente anche mmmpbx.

Quello che voglio provare a fare io è creare la seconda zona wan2 e vedere se ho anch'io problemi a fare forwarding su di essa. Proverò prima con una porta a caso su cui il router non è anch'esso in ascolto e vediamo che succede. Magari ci provo prima su un altro router openwrt puro.

Se nel frattempo ti viene qualche idea o vuoi farmi fare qualche prova io sono a tua completa disposizione.


Ne approfitto in tanto per chiederti aiuto su un'altra cosa. Questa notte ho provato a compilarmi haproxy con la toolchain messa a disposizione da @Ansuel qui:
https://github.com/Ansuel/GUI_ipk

Ho impostato tutte le variabili, ho preparato la buildroot, l'ambiente base riesco a prepararlo con successo, ma mi fallisce la compilazione di tutti i pacchetti. Ti elenco tutti gli step che ho seguito:

ho scaricato ed estratto la toolchain in:
/home/marvel/DGA4132/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_glibc_eabi/
poi:

Codice: [Seleziona]

cd /home/marvel/DGA4132/
export ARCH=arm
export PATH=/home/marvel/DGA4132/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_glibc_eabi/bin/:$PATH
export STAGING_DIR=/home/marvel/DGA4132/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_glibc_eabi/
export CROSS_COMPILE=arm-openwrt-linux-gnueabi
arm-openwrt-linux-gnueabi-gcc -v
git clone https://github.com/openwrt/chaos_calmer.git
cd chaos_calmer/
./scripts/feeds update
make defconfig -j6
make package/symlinks -j6
make menuconfig
make tools/install -j6
make toolchain/install -j6
make target/compile -j6

fino a qui funziona tutto correttamente, poi

Codice: [Seleziona]

./scripts/feeds install haproxy
make /package/feeds/packages/haproxy -j6

e qui la compilazione del pacchetto fallisce con il seguente errore:

Codice: [Seleziona]

make[1] /package/feeds/packages/haproxy
make -r /package/feeds/packages/haproxy: build failed. Please re-run make with -j1 V=s to see what's going on
/home/marvel/DGA4132/chaos_calmer/include/toplevel.mk:181: set di istruzioni per l'obiettivo "/package/feeds/packages/haproxy" non riuscito
make: *** [/package/feeds/packages/haproxy] Errore 1

Ti chiedo scusa in anticipo se scoccio sempre te, volevo chiedere info in questo thread:
https://www.ilpuntotecnico.com/forum/index.php?topic=77766.60
ma ho visto che anche su questa cosa sei molto preparato ed ho pensato di chedere direttamente a te. Non è colpa mia se sei così troppo preparato :-) :-) :-)

Ovviamente io c'ho sbattuto la testa fino alle 5 di stanotte e dalle 10 di stamane ad ora ma non capisco perché non va.

[larsen64it]

Se usi un semplice make V=s capisci subito dove è il problema.
Per compilare singoli pacchetti a volte bisogna compilare le dipendenze prima.
Alcuni pacchetti non gradiscono la compilazione parallela.