Newsgroup: it.comp.os.linux.sys
Titolo: IPSec e routing

Ciao,
sciaguratamente devo configurare una VPN IPSec.
Non l'ho mai fatto e sto avendo difficoltà.
(uso vyatta)
Il tunnel va su, come confermato anche dagli
operatori dall'altro capo del tunnel.
Però, non riesco a raggiungere un loro ip dietro
la VPN. Presumo mi manchi il routing che dica di
instradare le richieste verso xxx.xxx.xxx.xxx/32
tramite il tunnel.
Con OpenVPN mi ritrovo una interfaccia con un suo ip
verso il quale fare routing, con ipsec no.
Come faccio a ruotare il traffico verso xxx.xxx.xxx.xxx
tramite il tunnel?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 tramite il tunnel.
Credo di aver risolto, mi avevano comunicato i dati errati.


 tramite il tunnel?
Su plain linux, setkey(8).
Su vyatta boh.
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Su vyatta boh.
In ambo i sistemi:
si prende la cornetta e si fa:
"Hey, mi vuoi dare la subnet corretta oppure no?"


 "Hey, mi vuoi dare la subnet corretta oppure no?"
Ci ho provato, ma la cornetta non mi ha risposto...


 Ci ho provato, ma la cornetta non mi ha risposto...
ROTFL
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la


 Ci ho provato, ma la cornetta non mi ha risposto...
  Cornetta non IPSec enabled?  Routing scazzato?  Pacchetti dropped tra te e
il ricevente?
  Ciao,
-- 
Alessandro Selli, 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

 tramite il tunnel.
Ok, tunnel UP ed IP remoto pingabile.
Il problema, però, è che lo pingo solo dal firewall
che apre il tunnel. Io devo raggiungere l'ip remoto
anche tramite la LAN locale, che ha il firewall come
default gateway e che fa masquarade.
Se da un client locale pingo l'ip remoto dietro il
tunnel, ricevo un host unreachable di risposta da
parte del mio gateway (quello con il link attivo).
Però, se sul gateway pingo l'ip remoto, lo raggiungo
correttamente.
Presumo ci sia un problema di routing, come posso
risolvere? Quache dritta? 'Ste VPN ipsec mi stan già
sui maroni, spero di non doverne configurare altre.
L'IP remoto è presente in tabella:
$ show ip route 
10.1.56.141/32
Routing entry for 
10.1.56.141/32
   Known via "kernel", distance 0, metric 0, best
   * directly connected, eth5
ed il nat dalla mia rete locale verso eth5 funziona correttamente,
tant'è che riesco ad uscire verso qualunque destinazione
tranne l'estremo del tunnel ipsec.


 l'estremo del tunnel ipsec.
iptables, tabella nat, fai in modo che ci sia un bel -j RETURN quando -s 
è la tua LAN e -d è la loro LAN dietro la VPN.
ovvero: non nattare ciò che esce sull'interfaccia del default gateway che 
però è destinata ad andare sulla VPN.

 però è destinata ad andare sulla VPN.
Già fatto.
Non va.
Dal momento che è la primissima volta in assoluto che configuro ipsec,
faccio una domanda banale:
il "local-address" del tunnel può essere diverso da quello del mio
nat, dico bene?
Esempio:
10.100.100.1/30
 <-> gateway <-> 
10.0.0.1/24
 <-> client
Quel 10.100.100.1 va bene, o deve essere obbligatoriamente
un indirizzo "mio" come ad esempio 10.0.0.2 ?


 però è destinata ad andare sulla VPN.
Tra l'altro le prove le sto facendo con nat staccato.
Dai client non vado da nessuna parte, han solo impostato il firewall
come default gateway, il tunnel a livello di gateway lo vedo UP e
funzionante, ma i client non raggiungono l'ip remoto (il gw si)


 funzionante, ma i client non raggiungono l'ip remoto (il gw si)
Bho, proprio non capisco.
Il routing c'è:
$ sudo ip route
default via 192.168.0.1 dev eth5  proto zebra
10.1.56.141 dev eth5  scope link  src 172.18.11.41
127.0.0.0/8
 dev lo  proto kernel  scope link  src 127.0.0.1
172.18.11.40/30
 dev eth5  proto kernel  scope link  src 172.18.11.41
192.168.0.0/24
 dev eth5  proto kernel  scope link  src 192.168.0.44
il firewall dialoga correttamente con l'ip remoto (10.1.56.141)
ma i client nattati no.
Il forwarding è attivo:
$ sudo cat /proc/sys/net/ipv4/ip_forward
1
Il nat è bello pulito:
$ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 VYATTA_PRE_DNAT_HOOK  all  --  *      *       
0.0.0.0/0
 
 
0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 VYATTA_PRE_SNAT_HOOK  all  --  *      *       
0.0.0.0/0
 
 
0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
Chain VYATTA_PRE_DNAT_HOOK (1 references)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 RETURN     all  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
Chain VYATTA_PRE_SNAT_HOOK (1 references)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 RETURN     all  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
A logica, io devo nattare per raggiungere una rete differente
dalla mia come quella della VPN. Ma come faccio a nattare
se non ho una interfaccia verso la quale farlo ?


 
10.100.100.1/30
 <-> gateway <-> 
10.0.0.1/24
 <-> client
Se ipsec l'hai configurato con questi parametri, le policy faranno 
passare nel tunnel SOLO i pacchetti che sono contenuti nelle subnet 
specificate.
Dubito che i tuoi client stiano tutti nella 
10.100.100.1/30
 e secondo me 
è quello il problema.

 è quello il problema.
Dimmi che posso instradare/nattare in qualche modo. Non posso, se non
con un gran casino logistico, cambiare gli IP a 45 client che non usano
DHCP.
192.168.0.44 è l'ip del mio firewall, lato WAN (sono nel laboratorio
quindi la WAN sarebbe la rete del mio ufficio)
172.18.11.41/30
 mi è stato assegnato dal gestore del tunnel ed è un IP
associato alla nic che guarda la WAN (nel disegnino di prima, il lato
sinistro, assieme al mio IP e che punterà al router adsl)
La 
10.100.100.1/30
 era una mia prova non riuscita.
10.1.56.141/32
 è l'ip che devo raggiungere dietro la VPN.
I pc del cliente saranno in 
10.0.0.0/24
 e, OVVIAMENTE (murphy docet)
è la stessa subnet usata dai gestori del tunnel quindi non possono
cambiarmi l'indirizzo (che attualmente è impostato a 
172.18.11.41/30
)
in 10.0.0.0
Confermi quindi che devo 'dichiarare' 10.0.0.0 come local-subnet su
ambo gli estremi del tunnel se voglio collegarmi tramite apparati
attestati su tale rete?
Non posso routare o nattare in qualche modo? Cambiare i 45 computer
è improponibile, davvero.
Loro posso 'autorizzare' la mia subnet ? Nella mia configurazione
vede "allow-nat-networks disable" attivo di default, magari loro hanno
qualche cosa di simile in cui dichiarare 10.0.0.0


 su tale rete?
Hai molto molto molto casino in testa.
Non posso biasimarti, ipsec è una brutta bestia per chi si avvicina la 
prima volta.
Ma poi è tutto abbastanza banale e tradizionale.
Tu per configurare ipsec hai, tendenzialmente, bisogno di 4 cose, ovvero 
di 4 IP (lasciamo perdere i parametri in merito alla crittazione).
IP gateway locale | ip gateway remoto.
Questi sono gli ip PUBBLICI dei due gateway e servono alle due macchine 
per parlarsi con i dati incapsulati ( protocolli ESP/AH ) e 
l'autenticazione ike (udo/500).
Nulla di particolare, 2 regoline sul firewall.
Ricorda che ESP Ed AH sono procotolli, non servizi.
Gli altri due parametri sono le reti nattate.
Se indichi ad esempio:
- 
1.2.3.4/32
 e 
5.6.7.8/32
 stai facendo una VPN tra due host semplici.
- 
1.2.3.4/24
 e 
5.6.7.8/32
 vpn tra un host (laptop??) ed una lan
- 
1.2.3.4/24
 e 
5.6.7.8/24
 vpn tra due lan.
Anche quanto sopra è abbastanza banale. 
Si applica lo stesso proincipio a opwnvpn e a tutto il resto.
FINE.
L'unica cosa che devi sapere in più è che su linux ed i 2.6.X, se ti 
metti in questo caso
 tuo lato  
1.2.3.4/24
  <---> 
5.6.7.8/24
  loro lato
non devi fare un cazzo ma i pacchetti verso la 5.6.7.8 se escono 
dall'interfaccia di default GW, verranno nattati a meno che tu gli dica 
di non farlo.
------------------------------------------------------------------------
Premesso quanto sopra, tu nel tuo post mi rigurgiti una svalangata di IP 
e di subnet che mi mandano in confusione ma i dati
                     local-subnet 
172.18.11.41/30
                     remote-subnet 
10.1.56.141/32
Sicuramente mi indicano che la tua subnet ha solo 2 IP utilizzabili e non 
so cosa ci vuoi fare.
la remote subnet è invece un singolo host.
Su questa rete non passerà mai un cazzo per la 
10.0.0.0/24
 che sono gli 
IP del cliente.
A meno che tu non gli dica che per raggiungere la 10.0.0.0 deve farsi 
parecchi giri per andare sul 10.1.56.141 che a sua volta deve fare da 
router.
Così, su due piedi, potrei dirti che questa entità terza che gestisce 
IPSEC non ha capito un cazzo di cosa devi fare e ti ha fornito degli IP 
at catzum con lo scopo di complicarti la vita.

 at catzum con lo scopo di complicarti la vita.
Quoto tutto, perchè faccio riferimento a tutta questa tua parte.
La situazione attuale è questa:
il cliente ha come allocazione 
10.0.0.0/24
 e circa 45 client che
attualmente escono su internet tramite una ADSL ed un mio firewall/
gateway.
Il cliente ha stipulato un contratto con un ente esterno, che mette a
disposizione un server (ecco il perchè del /32) raggiungibile tramite
una VPN ipcazz.
L'attuale firewall non ha il supporto ipsec compilato e ricompilare il
tutto è un massacro (anche perchè il cliente rimarrebbe fermo per
$tanto tempo, quindi gli abbiamo venduto un nuovo apparato.
Il nuovo apparato è qui in laboratorio da me, (nattato più e più
volte, ma non è un problema) e dovrà svolgere le funzioni di firewall,
gateway e gateway verso la vpn.
L'allocazione 
172.18.11.41/30
 mi è stata assegnata dai gestori VPN
come test per verificare il funzionamento del link, e funziona tutto
correttamente. Ho provato quindi a chiedere ai gestori della VPN di
settare il loro concentratore (credo cisco) su 10.0.0.X in modo da
avere la stessa allocazione del mio cliente, ma non possono farlo
perchè va in overlap con la loro rete interna.
Adesso, se avessi avuto una VPN tipo OpenVPN potevo benissimo fare una
rotta statica dicendo che l'ip remoto 
10.1.56.141/32
 è raggiungibile
tramite il next-hop 172.18.11.42 (che corrisponde alla punto-punto che
mi han rilasciato quelli della VPN), l'ho fatto mille trilioni di
volte e non ho mai avuto problemi. Ho fatto la stessa cosa con sto
ipcazzo e non funziona... un cazzo.
Questo è quanto. Io devo far vedere l'ip 
10.1.56.141/32
 (dietro vpn)
dalla rete del mio cliente settata su 
10.0.0.0/24
. I gestori VPN non
possono settarsi su 10.0.0.0, quindi:
 - o trovo il modo di ruotare il traffico localmente
 - o cambio tutte le configurazioni dei 45 apparati del cliente (tra
cui stampanti e minchiate varie di cui tutti, me compreso, ignoriamo
le password di accesso)
Chi ha una soluzione? (si, ho provato a dire: non infiliamoci in
casini vari con ipsec, non l'ho mai configurato, potrei impiegare
mooooooooooooooooolto tempo, ma non mi han dato retta)

 router.
Il problema è che la subnet "ipsec" deve essere attestata sulla stessa
interfaccia d'uscita, e non sulla mia LAN.
Ho provato a spostare l'allocazione che mi è stata assegnata dal gestore
VPN attestandola alla nic interna piuttosto che quella esterna e non
raggiungo più l'estremo dietro la VPN, nemmeno creando un routing.
Di conseguenza, se anche loro mi assegnassero una allocazione valida
per tutti gli host della mia rete (
10.0.0.0/24
), non potrei comunque
usarla, dovendo attestarla sulla nic lato wan. E certamente non posso
avere due nic facenti parte della stessa subnet, su un firewall, sia
lato WAN che lato LAN.
In pratica:
VPN <-- 
10.0.0.0/24
 <-- firewall --> 
10.0.0.0/24
 --> LAN
Ovviamente non può andare.
Attualmente ho:
VPN <-- 
172.18.11.41/30
 <-- firewall --> 
10.0.0.0/24
 --> LAN
e funziona solo lavorando direttamente sul firewall, non a valle.
Spostando 
172.18.11.41/30
 lato LAN:
VPN <-- 192.168.0.0 <-- firewall --> 
172.18.11.41/30
 --> LAN
non raggiungo l'estremo della VPN, "Destination Host Unreachable"
nel caso di un routing statico verso la nic lato WAN, oppure
"Destination Net Unreachable" nel caso rimuovessi il routing
statico.
(192.168.0.0 è la mia rete in uscita, quella che dal cliente
corrisponderebbe al router adsl)


 interfaccia d'uscita, e non sulla mia LAN.
Ci son riuscito. Bisogna creare obbligatoriamente un SNAT.
Adesso come adesso, tutto ciò che è diretto verso l'ip remoto
dietro la VPN, proveniente dalla mia subnet interna 
10.0.0.0/24
viene snattato sull'ip locale del tunnel (la punto-punto che mi
è stata assegnata).
Funziona. e ne ho avuto conferma con una prova scientifica:
se stacco lo snat non va, se lo riattivo, riparte.
