[ivan1970]

avevo già provato senza successo.
se lascio %dhcp ricevo questo errore:

Codice: [Seleziona]

Oct 12 08:59:18 mail charon: 08[IKE] peer requested virtual IP %any
Oct 12 08:59:18 mail charon: 08[IKE] no virtual IP found for %any requested by 'xxxx.ddns.net'
Oct 12 08:59:18 mail charon: 08[IKE] no virtual IP found, sending INTERNAL_ADDRESS_FAILURE
Oct 12 08:59:18 mail charon: 08[IKE] traffic selectors 85.18.44.44/32 === 0.0.0.0/0 inacceptable
Oct 12 08:59:18 mail charon: 08[IKE] failed to establish CHILD_SA, keeping IKE_SA

se invece imposto un IP fisso (192.168.1.25/32) ricevo questo errore:

Codice: [Seleziona]

Oct 12 09:01:37 mail charon: 07[IKE] peer requested virtual IP %any
Oct 12 09:01:37 mail charon: 07[CFG] assigning new lease to 'xxxx.ddns.net'
Oct 12 09:01:37 mail charon: 07[IKE] assigning virtual IP 192.168.1.25 to peer 'xxxx.ddns.net'
Oct 12 09:01:37 mail charon: 07[IKE] traffic selectors 85.18.44.44/32 === 0.0.0.0/0 inacceptable
Oct 12 09:01:37 mail charon: 07[IKE] failed to establish CHILD_SA, keeping IKE_SA


Ovviamente io preferirei cambiare la subnet di casa

ho seguito il tuo consiglio ed ho cambiato la subnet nella mia rete di casa, ma il problema non è cambiato.. 

[FrancYescO]

https://anonfiles.com/N8iecc3fo4/kmod-bcm63xx-tch-spu_4.1.38-1_brcm63xx-tch_ipk

riuppi quando puoi? anzi se @Marvel lo mette anche in repo tanto meglio

[LuKePicci]

@ivan1970 cosa hai messo come rightsubnet sul server debian? è giusto con l'ip fisso, il dhcp ora non ti serve. Buono aver cambiato la subnet di casa, appena risolto quell'errore sul selector non dovresti avere problemi a raggiungere qualsiasi 192.168.1.0 dal technicolor (e dalla sua lan)

OT/ @FrancYescO se mi dite da dove è venuto fuori gli faccio il torrent /OT

[ivan1970]

@ivan1970 cosa hai messo come rightsubnet sul server debian? è giusto con l'ip fisso, il dhcp ora non ti serve. Buono aver cambiato la subnet di casa, appena risolto quell'errore sul selector non dovresti avere problemi a raggiungere qualsiasi 192.168.1.0 dal technicolor (e dalla sua lan)

questa è la configurazione adesso:

Codice: [Seleziona]

# initiator Technicolor
conn %default
        type=tunnel
        keyexchange=ikev2
        ike=aes256-aes128-sha256-sha1-modp3072-modp2048-modp1024
        esp=aes256-sha1!
        mobike=no
        installpolicy=yes

conn homeivan-to-office
        auto=start
        authby=secret
        left=192.168.222.1
        [email protected]
        right=85.18.44.44
        [email protected]



Codice: [Seleziona]

#receiver Debian
conn %default
        type=tunnel
        keyexchange=ikev2
        ike=aes256-aes128-sha256-sha1-modp3072-modp2048-modp1024
        esp=aes256-sha1!
        keyingtries=%forever
        ikelifetime=28800s
        lifetime=3600s
        dpddelay=30s
        dpdtimeout=120s
        dpdaction=clear
      mobike=no

conn office-to-homeivan
        auto=add
        authby=secret
      right=%xxxx.ddns.net
        rightid=xxxx.ddns.net
      left=192.168.0.2
      leftid=xxxx.yyyy.it
        rightsubnet=192.168.222.0/24

e non riesce ad effettuare la connessione IKE

Codice: [Seleziona]

Oct 12 18:49:25 mail charon: 12[NET] received packet: from 79.17.211.208[500] to 192.168.0.2[500] (840 bytes)
Oct 12 18:49:25 mail charon: 12[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
Oct 12 18:49:25 mail charon: 12[IKE] 79.17.211.208 is initiating an IKE_SA
Oct 12 18:49:25 mail charon: 12[IKE] local host is behind NAT, sending keep alives
Oct 12 18:49:25 mail charon: 12[IKE] remote host is behind NAT
Oct 12 18:49:25 mail charon: 12[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N(MULT_AUTH) ]
Oct 12 18:49:25 mail charon: 12[NET] sending packet: from 192.168.0.2[500] to 79.17.211.208[500] (584 bytes)
Oct 12 18:49:45 mail charon: 13[IKE] sending keep alive to 79.17.211.208[500]
Oct 12 18:49:55 mail charon: 14[JOB] deleting half open IKE_SA after timeout



[LuKePicci]

Il left sul server ha un valore che non ha senso, ma non sto capendo perché non ritorni alla situazione di partenza in cui avevi solo un problema sull'ip virtuale scelto, da lì eravamo molto più vicini al traguardo

[Marvel]

anzi se @Marvel lo mette anche in repo tanto meglio

Certamente, non ci sono problemi, se @LuKePicci mi da il permesso lo carico nel repo con i dovuti credits.

OT/ @FrancYescO se mi dite da dove è venuto fuori gli faccio il torrent /OT

In che senso dove è venuto fuori? L'hai caricato tu:
https://www.ilpuntotecnico.com/forum/index.php/topic,82673.msg265543.html#msg265543

[ivan1970]

Il left sul server ha un valore che non ha senso, ma non sto capendo perché non ritorni alla situazione di partenza in cui avevi solo un problema sull'ip virtuale scelto, da lì eravamo molto più vicini al traguardo

perchè prima avevo il virtual IP che adesso non dovrebbe più servire..
ho cercato di ridurre al minimo i parametri, adesso però la connessione IKE viene effettuata ma non va avanti perchè ricevo l'errore: traffic selectors  inacceptable
adesso la configurazione è questa:

Codice: [Seleziona]

#initiator
conn homeivan-to-office
        auto=start
        authby=secret
        left=%any
        leftid=[member=1153]xxxx[/member].ddns.net
        leftsubnet=192.168.222.0/24
leftfirewall=yes
        right=85.30.40.50
        rightid=xxxx.yyyy.it
        rightsubnet=192.168.1.0/24

#responder
conn office-to-homeivan
        auto=add
        authby=secret
right=%xxxx.ddns.net
        rightid=xxxx.ddns.net
leftid=xxxx.yyyy.it

in questo caso ricevo questo errore:
traffic selectors 192.168.1.0/24 === 192.168.222.0/24 inacceptable
invece togliendo il dalla configurazione dell'initiator i parametri leftsubnet e rightsubnet ricevo questo errore
traffic selectors 85.30.40.50/32 === 79.17.211.210/32 inacceptable
i due IP rappresentano i due IP pubblici dei due siti. Ma nel log quando effettua la connessione lato responder non mette l'IP pubblico ma quello della rete esterna al concentratore:
IKE_SA office-to-homeivan[2] established between 192.168.0.2[fqdn]...79.17.211.210[fqdn]
non vorrei che fosse questo parte del problema..

[ivan1970]

sono riuscito ad attivare il tunnel:

Codice: [Seleziona]

#initiator
root@modemtim:~# ipsec status
Security Associations (1 up, 0 connecting):
homeivan-to-office[1]: ESTABLISHED 15 seconds ago, 79.17.211.208[xxxx.ddns.net]...85.30.40.50[xxxx.yyyy.it]
homeivan-to-office{1}:  INSTALLED, TUNNEL, reqid 1,  ESP in UDP SPIs: cf84ecd7_i c4c75c86_o
homeivan-to-office{1}:   192.168.222.0/24 === 192.168.1.0/24

#responder
root@mail:~# ipsec status
Security Associations (1 up, 0 connecting):
office-to-homeivan[1]: ESTABLISHED 23 seconds ago, 192.168.0.2[xxxx.yyyy.it]...79.17.211.208[xxxx.ddns.net]
office-to-homeivan{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c4c75c86_i cf84ecd7_o
office-to-homeivan{1}:   192.168.1.0/24 === 192.168.222.0/24
però non esistono rotte tra le due subnet e non sono riuscito a crearne una manualmente.. ma devo creare io la rotto o dovrebbe essere creata in automatico alla connessione?

abilitando il parametro leftfirewall=yes su entrambi i siti, adesso sul server debian trovo questa rotta:

Codice: [Seleziona]

ip route list table 220
192.168.222.0/24 via 192.168.0.254 dev eth1 proto static src 192.168.1.1
mentre sul technicolor non trovo nulla.. ma ciò nonostante non c'è routing in nessun verso..

[LuKePicci]

Ottimo, mi sono accorto di aver confuso io le tue due subnet su debian, sul server in rightsubnet ci va 192.168.0.0/24 (ti avevo detto .1.1/24) e rightsourceip deve essere un ip in 192.168.0.0 tipo 192.168.0.42 (ti avevo detto .1.42)

A quel punto prova dal technicolor a raggiungere un qualsiasi indirizzo in 192.168.0.0, sia quello virtuale assegnato al tch, sia quello del server debian (che se ho ben intuito dovrebbe essere 192.168.0.2) sia gli altri nella rete esterna dell'ufficio. Dopodichè ti serve creare manualmente sul technicolor una rotta che gli indichi di poter raggiungere 192.168.1.0 attraverso il tunnel vpn, cosa che ora puoi fare senza conflitti avendo cambiato la subnet di casa in .222.0. Fatto questo dovresti poter raggiungere 192.168.1.1. Come vedi sul server spunta in automatico la rotta per il tragitto inverso che dice a lui dove rispedire i pacchetti destinati a 192.168.222.0, anche questa funzionerà senza conflitto perchè in ufficio non c'è una subnet con quell'id. Infine, se i vari host in 192.168.1.0 già usano 192.168.1.1 come default gateway non hai bisogno di dar loro alcuna regola perchè nel tentativo di raggiungere 192.168.222.0 (per loro un indirizzo non locale) andranno al default gateway (il server debian) e lui sa come mandarli avanti perchè ha quella rotta aggiunta automaticamente verso la rete di casa.

[ivan1970]

bene @LuKePicci, ci sono quasi 
impostando il leftsourceip a 192.168.0.250 non mi tirava su il tunnel. Quindi ho provato a creare un alias di quell'ip sul technicolor aggiungendolo alla scheda di loopback, ed in questo modo il tunnel viene tirato su correttamente e riesco anche a raggiungere la subnet 192.168.0/24 sia dal technicolor che dalla mia rete di casa.. 
non riesco ancora a far funzionare il contrario, nel senso che dal debian non raggiungo ne il 192.168.0.250 e tantomeno la subnet 192.168.222.0/24, ma questo problema al momento mi interessa poco..
Il problema che ho adesso, è che non ho capito come creare la rotta sul technicolor per raggiungere la subnet 192.168.1.0/24
ho provato con questo comando

Codice: [Seleziona]

ip route add 192.168.1.0/24 dev br-lan src 192.168.0.250 table 220
ho provato anche a togliere il table 200 (che non mi è chiaro a cosa serva).
ho anche provato a sostituire il device br-lan con lo (visto che associato l'p sorgente alla scheda di loopback).
tutto senza successo.. Scusami ma, probabilmente, mi manca qualche concetto di base.. 

edit

scusate..
ho scritto un saccco di cavolate.. a rispondere al ping sulla subnet 192.168.0.0/24 non è la rete remota, ma è sempre la mia loopback. 

[LuKePicci]

Perdonami, quello da mettere su 192.168.0.250 è il rightsourceip sul server, non left.

[ivan1970]

scusami @LuKePicci però a me manca un concetto:
che io sappia un IP deve sempre essere appoggiato ad un interfaccia di rete (fisica o virtuale che sia).
Se io non configuro un interfaccia di rete e, a quanto pare, non lo fa neanche strongswan, su che interfaccia verrà configurato l'IP 192.168.0.250?

[LuKePicci]

Semplicemente gli ip virtuali di strongswan non sono associati a nessuna interfaccia, infatti non hanno un indirizzo mac, puoi fare in modo che ne venga gestito uno finto ciascuno ma è solo per abilitare un certo tipo di logiche che senza non funzionerebbero. La connettività IP base funziona anche senza.

Se cerchi qualcosa in giro trovi sicuramente materiale a riguardo.

In effetti credo sia questo il motivo per cui si chiamano "virtuali"

[ivan1970]

questa è la mia ultima configurazione:

Codice: [Seleziona]

#initiator
conn homeivan-to-office
        auto=start
        authby=secret
        left=%any
        leftid=[member=1153]xxxx[/member].ddns.net
        leftsubnet=192.168.222.0/24
        leftsourceip=%config
      leftfirewall=yes
        right=85.30.40.50
        rightid=xxxx.yyyy.it
        rightsubnet=192.168.0.0/24

#responder
conn office-to-homeivan
        auto=add
        authby=secret
      leftid=xxxx.yyyy.it
      leftsubnet=192.168.0.0/24
      leftfirewall=yes
      right=%xxxx.ddns.net
        rightid=xxxx.ddns.net
        rightsubnet=192.168.222.0/24
      rightsourceip=192.168.0.250/32

adesso l'ip virtuale è stato tirato su e dal technicolor riesco a pingarlo, ma non vedo nessun altro server della rete 192.168.0.0/24.

in più adesso mi sembra che abbia tiruto su tutte questo nuove interfaccia che prima non mi sembrava di avere:

Codice: [Seleziona]

ifconfig -a
atm0      Link encap:Ethernet  HWaddr 10:13:31:B4:46:84
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

atmwan    Link encap:Ethernet  HWaddr 10:13:31:B4:46:84
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

br-ipsec0 Link encap:Ethernet  HWaddr 0E:FB:E8:BE:CD:96
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

gre0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-50-00-00-00-00-00-00-00                                                                                                             -00
          NOARP  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ifb0      Link encap:Ethernet  HWaddr 2A:98:0F:7B:06:1E
          BROADCAST NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ifb1      Link encap:Ethernet  HWaddr 2E:E0:FA:11:51:95
          BROADCAST NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ip6gre0   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00                                                                                                             -00
          NOARP  MTU:1448  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ip6tnl0   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00                                                                                                             -00
          NOARP  MTU:1452  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ptm0      Link encap:Ethernet  HWaddr 10:13:31:B4:46:84
          inet6 addr: fe80::1213:31ff:feb4:4684/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1508  Metric:1
          RX packets:1564614 errors:0 dropped:0 overruns:0 frame:0
          TX packets:665576 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1716452738 (1.5 GiB)  TX bytes:307101278 (292.8 MiB)

sit0      Link encap:IPv6-in-IPv4
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

teql0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00                                                                                                             -00
          NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tunl0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-50-00-00-00-00-00-00-00                                                                                                             -00
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

[LuKePicci]

Ok, ora mi sembra tutto giusto, prova un ping dal technicolor verso l'IP del server Debian. Il fatto che ti rispondano o meno al ping può dipendere (e dipende di sicuro su macchine windows) dal fatto che le risposte ai ping sono proibite quando giungono da io non appartenenti alla subnet locale. Abilitarlo non ha senso, se devi fare prove metti qualcosa in ascolto sui server in .0.0, assicurati che dal server Debian tu possa accedervi e poi prova anche dal technicolor (e sua LAN)