[LuKePicci]

Sto preparando un 4130 da mettere nell'altra casa, mi sono imbattuto in un problema con strongswan quando usato in dhcp con ip della lan. In pratica c'è un servizio dosprotect - che credo abbia a che fare col chip wireless 5GHz - che rompe le scatole. La VPN si collegava correttamente ma poi non passava quasi nulla tranne qualche ping. Non ne sono sicuro, ma credo si ricordi i mac address che blocca, infatti provando a connettermi prima in locale e poi in remoto comunque la connessione non funzionava, mentre cambiando mac del client vpn (cioè disabilitando identity_lease)  ha preso a funzionare in remoto, ma non in locale. Provo a capire se c'è modo di lasciare dosprotect attivo con una configurazione più opportuna.

PS in aes128 ho toccato i 140Mbit/s

PS2 @FrancYescO niente da fare per wireguard

[a1pollo]

"Non ne sono sicuro, ma credo si ricordi i mac address che blocca, infatti provando a connettermi prima in locale e poi in remoto comunque la connessione non funzionava".

Anche a me e' successo un problema simile al tuo, mi trovavo fuori casa al rientro trovo il secondo router (collegato come estensione della lan,) su cui girava il solo il server strongswan, in bootlooop, lo riattivo e niente strongswan non mi fa accedere, riprovo sul primario chiudendo le porte e anche qui' non mi fa' accedere.
Cambio i settaggi da rightsourceip=%dhcp a rightsourceip=192.168.1.120/32 , e riprende a funzionare.
Quindi il problema ha a che fare col dhcp, anche su luci prima vedevo il fake mac con l'indirizzo assegnato, ora non piu'.

PS  Su strongswan possiamo anche configurare l'accensione di un led, usando uno di quelli mappati:

Codice: [Seleziona]

/etc/strongswan.d/charon/led.conf:

led {

    activity_led = ambient1:white

    blink_time = 50 #non lampeggia

    # Whether to load the plugin. Can also be an integer to increase the
    # priority of this plugin.
    load = yes

}

Per la velocita' mi va' in media a 75, anche sul router scarico e con aes128.

[LuKePicci]

Quella cosa del crash subito dopo la connessione (appena inizia a scambiare traffico) me la fa solo con acceleratore hw attivo e se come primo client vpn connetto windows via dhcp. Se prima di lui connetto android (app strongswan, stesso certificato, quindi stessa identity) sempre in dhcp, poi anche windows si connette normalmente. E questo me lo fa sia sul 4131 che sul 4130, non ho però indagato se disattivando identity_lease la cosa cambia. Sospetto ci sia qualche magagna con i mac address dei pacchetti che accelera perchè l'SPU non accelera solo la crittografia aes ma tutta la gestione di ESP per IPsec.. Di fatto il mio 4131 fa uptime di qualche mese quando non sto a sperimentare cose nuove, quindi quando mi connetto da fuori casa è assai probabile io abbia connesso almeno una volta android prima di quel momento.

Il problema di rpfilter (attivato in dosprotect solo nel 4130/2 e non nel 4131) non ha a che fare col reboot e nè con l'acceleratore hw, si presenta solo usando dhcp, semplicemente blocca qualsiasi traffico con sorgente ip di lan che non proviene da interfaccia lan. Ho deciso di poter vivere anche senza rpfilter e l'ho disabilitato.

Invece ho visto che sempre in dosprotect c'è un limite ai pacchetti UDP, ho rimosso quelle regole (ora ce l'ho come sono impostati tcp ed esp) e l'upload mi si è sbloccato oltre i 10mbit a cui era limitato.

[ivan1970]

Ciao Luke,
provo a spostare questa discussione in questo thread.. ma non ho capito la tua domanda. In che senso devo escludere il traffico in uscita dal NAT?

ciao a tutti,
sto cercando di attivare una connessione punto punto IPSEC tra il mio modem TG789vac2 con il firmware uno, verso un server strongswan su debian. Ho attivato la connessione con pre shared key e ikev2, purtroppo, avendo due subnet che si sovrappongono, ho dovuto anche gestire un virtual IP dal lato del mio modem per mascherare i miei IP.
Detto questo, riesco ad attivare la connessione IKE e anche il tunnel tra i due siti, dal server debian riesco anche ad effettuare un ping verso il mio modem, ma al contrario purtroppo non viene creata la rotta.
Probabilmente perchè, come qui descritto:
https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
per creare la rotta, deve creare questo dispositivo VTI, e per fare ciò è necessario il modulo "kmod-ipvti" che non ho trovato da nessuna parte.
Come posso trovare questo modulo? oppure cambiando configurazione posso ovviare a questo problema?

[LuKePicci]

la chain in cui applichi il masquerade sui pacchetti normalmente routati da lan a wan agisce prima di quella che ributta indietro il traffico per passarlo sul tunnel ipsec. Qui lo trovi spiegato meglio: https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#General-NAT-problems

[ivan1970]

non capisco come possa dipendere dal firewall. Io sul mio modem non trovo proprio la rotta verso la subnet remota, quindi, se dal modem provo a fare un ping verso l'IP del server remoto, non va da nessuna parte.
se eseguo questo comando sul modem:

Codice: [Seleziona]

ip route list table 220
non restituisce nulla
se invece lo eseguo sul server remoto la rotta è creata correttamente:

Codice: [Seleziona]

192.168.168.126 via 192.168.0.254 dev eth1 proto static src 192.168.1.1

comunque queste sono le regole inserite nel firewall

Codice: [Seleziona]

#strongswan ipsec
iptables -I INPUT  -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables -I FORWARD  -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables -I FORWARD  -m policy --dir out --pol ipsec --proto esp -j ACCEPT
iptables -I OUTPUT   -m policy --dir out --pol ipsec --proto esp -j ACCEPT
iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT


[LuKePicci]

Hai detto di aver creato un ip virtuale sul modem in modo da ovviare al problema delle subnet sovrapposte. Immagino che questo significhi sostanzialmente far arrivare sul server debian qualsiasi pacchetto proveniente dal modem tramite tunnel ipsec con il campo "source" riempito coll'ip virtuale. In pratica ti occorre nattare il traffico uscente dal modem verso il tunnel da ip locale qualsiasi a ip virtuale.

Se ti trovi con quanto ho appena detto allora  la regola

Codice: [Seleziona]

iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPTnon può fare al caso tuo.perchè gli stai esplicitamente dicendo di non fare il natting che ti occorre.

Il VTI dimenticatelo, non esiste in linux 3.4

[ivan1970]

ok, grazie mille, ho eliminato quella regola ma non è cambiato nulla.
non mi ero ancora focalizzato sulle regole del nat perchè, al momento, non sono ancora riuscito a raggiungere il server neanche dal modem.
Se il vti non serve, non capisco come dovrebbe fare a creare la regola di routing, dovrebbe creare un'interfaccia virutale? dovrebbe fare tutto in automatico o devo creare io qualche script?
questo è il file ipsec.conf

Codice: [Seleziona]

config setup
        charondebug="all"

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

conn homeivan-to-office
        auto=start
        authby=secret
        leftid=xxxx.ddns.net
        right=xx.xx.xx.xx
        [email protected]
        leftsourceip=%config
        left=%any
        rightsubnet=192.168.1.0/24
        leftfirewall=yes


aggiungo che questo è il tunnel che vedo attivo sul modem:

Codice: [Seleziona]

ipsec status
Security Associations (1 up, 0 connecting):
homeivan-to-office[1]: ESTABLISHED 5 minutes ago, Public IP local[xxxx.ddns.net]...Public IP Rempote[xxxx.yyyy.it]
homeivan-to-office{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c5350e79_i c6a5c929_o
homeivan-to-office{1}:   192.168.168.126/32 === 192.168.1.0/24

ho eseguito questo comando:

Codice: [Seleziona]

ip route add 192.168.1.0/24 dev br-lan src 192.168.168.126 table 220
e adesso riesco a pingare le macchine della rete remota dal modem.

quindi dovrei creare uno script di up_down per creare manualmente la rotta?

adesso però ho il problema che non riesco ad accedere alla rete remota dalla mia rete locale.

l'IP Virtuale che ho utilizzato per accedere alla rete remota si trova sull'interfaccia br-guest mentre la mia lan sull'interfaccia br-lan, devo creare un routing tra le due interfacce?

[LuKePicci]

Il funzionamento normale è basato sul matching di policy ipsec, ovvero si decide se mandare o meno un determinato traffico dentro un tunnel ipsec se matcha una policy ipsec attiva. Questa cosa non è "routing", quindi non va sotto il nome di route-based tunneling per il quale servirebbero vti, interfacce xfrm o altri trucchi con GRE o TUN. Il route-based tunneling consiste nel decidere se mandare o meno un determinato traffico dentro un tunnel ipsec quando lo si vede provenire da una interfaccia di rete, in cui puoi quindi routare traffico tramite route. Ha dei vantaggi ma non credo ti occorrano necessariamente per quello che vuoi fare tu. C'è una pagina sulla wiki di strongswan in cui ti spiega tutto riguardo al route-based tunneling, puoi leggertela per curiosità se ti va: https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN

Avendo tu usato leftsourceip=%config nell'initiator (il technicolor), dovresti dirmi cosa hai impostato come rightsourceip e rightsubnet sul responder (debian) per l'ip virtuale. Inoltre, qui sul technicolor vedo che hai impostato rightsubnet=192.168.1.0/24 il che, pur non conoscendo le tue subnet dai due lati, mi sa di sbagliato in quanto la documentazione di strongswan dice chiaramente che:

The traffic selectors in swanctl.conf and ipsec.conf (local|remote_ts and left|rightsubnet, respectively) default to the value dynamic or %dynamic, respectively. If virtual IPs are used, this value gets dynamically replaced by the received or assigned virtual IP.
Therefore, no local traffic selector must be configured on the client and no remote traffic selector on the server when using virtual IPs. This ensures the client's traffic selector is correctly narrowed to the assigned virtual IP.

[ivan1970]

scusami, hai ragione, non ti ho descritto la mia architettura:
la mia rete office ha la subnet 192.168.1.0/24
il server debian dove è installato strongswan ha l'ip della rete interna = 192.168.1.1 e l'ip della rete esterna = 192.168.0.2
la mia rete home ha la subent 192.168.0.0/24 e l'ip del modem è 192.168.0.1

quindi la sovrapposizione è solo relativa all'IP esterno del server debian con la mia subnet di casa ma, dovendo accedere solo alla subnet interna non dovrebbero esserci problemi, corretto?

questa la configurazione ipsec remota:

Codice: [Seleziona]

config setup
        charondebug="all"
        uniqueids=no

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
        mobike=no

conn office-to-homeivan
        auto=add
        authby=secret
        right=%xxxx.ddns.net
        rightid=xxxx.ddns.net
        rightsourceip=192.168.168.126/32
        left=192.168.0.2
        leftid=xxxx.yyyy.it
        leftsubnet=192.168.1.0/24



[LuKePicci]

Ok, allora, il rightsubnet sull'initiator, il modem, eliminalo o mettilo sul default che è %dynamic. Com'è ora non è sbagliata ma non ha senso specificarla lì.

Detto questo, non hai bisogno di alcun virtual IP in strongswan in quanto le subnet ai due lati sono disgiunte. Quindi ripulisci tutto ciò che hai creato relativamente a quel virtual ip custom, lascia che gli venga assegnato un ip virtuale appartenente alla subnet remota 192.168.1.0 e rimetti la regola di nat exemption nel firewall. A quel punto fai le varie prove a raggiungere la rete 192.168.1.0 dal technicolor e dai suoi host lan, e viceversa dal server debian la rete 192.168.0.0 quando l'altra sulla stessa subnet non esiste.

Dopodiché, per risolvere il conflitto che hai sul server debian che giustamente non sa come raggiungere 192.168.0.0 e famiglia quando c'è connessa sia la VPN che l'altra rete, devi escogitare qualcosa dal suo lato che però non ha niente a che fare con ipsec e strongswan. Ovviamente io preferirei cambiare la subnet di casa, non so se hai già scartato questa soluzione ma sarebbe un bel passo avanti perchè a quel punto ti basterebbe aggiungere una banale rotta verso 192.168.0.0 sul technicolor attraverso 192.168.1.1 o altro router su quella rete.

[ivan1970]

ma quindi, se io non avessi la necessità di raggiungere dalla rete debian la rete del technicolor, ma mi servisse solo la rotta al contrario, non dovrei fare nient'altro?

[LuKePicci]

se l'unico scopo è raggiungere dalla rete lan del technicolor l'altra rete 192.168.0.0 a cui è connesso il server debian ma che non è quella tramite la quale il server agisce da responder ipsec allora  non dovresti fare nient'altro che creare dal lato del technicolor la rotta che ti dicevo, perchè i tuoi dispositivi nella rete del technicolor verrebbero visti dall'altra parte come un unico 192.168.1.N (rightsourceip) che molto probabilmente gli altri host sulla 192.168.0.0 già sanno come raggiungere, ma questo lo sto solo ipotizzando, se così non fosse sono altre cose a cui badare dall'altor lato.

[ivan1970]

dopo una serie di tentativi sono riuscito a riattivare il tunnel ma non senza definire un virtual IP, però non sono riuscito ad ottenere un IP da utilizzare lato initiator.
questa è la configurazione di entrambe le macchine:
 

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
        leftid=xxxx.ddns.net
        right=85.18.44.44
        rightid=xxxx.yyyy.it
        leftsourceip=%config4
        rightsubnet= %dynamic
        rightsourceip=%dhcp
        rightsubnet=192.168.1.0/24



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
      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
      leftsubnet=192.168.1.0/24

ho anche provato ad aggiungere nel strongswan.conf questo:

Codice: [Seleziona]


    plugins {
        attr {
            dns = 192.168.1.15, 192.168.1.16
            dhcp = 192.168.1.15, 192.168.1.16
        }
    }


[LuKePicci]

No scusa lascia perdere il dhcp, non mettere in mezzo altre cose, sul technicolor non ci va nessun rightsourceip, e togli anche quella rightsubnet statica. E' sul server che devi mettere rightsourceip=%dhcp o per il momento solo un ip singolo a tua scelta tipo 192.168.1.42/32 Quella roba che hai messo nei plugin levala, non serve a nulla per quello che stai cercando di fare.