Newsgroup: it.comp.os.linux.sys
Titolo: SNAT e IPSEC

Salve a tutto il ng,
ho un problema concettuale, mi manca un tassello di conoscenza per 
riuscire a risolvere un problema.
Lo scenario:
due gateway, A e B, che instaurano un tunnel IPSEC, io controllo il 
gateway B mentre A è gestito da altri e non modificabile.
B è il default gw di una LAN 192.168.1.x mentre A è il default gw di una 
LAN 
172.16.20.0/22
Lo stato:
grazie a setkey e racoon riesco a creare un tunnel tra B e A e riesco a 
pingare un indirizzo della rete 
172.16.20.0/22
Il problema:
B ha attivi diversi tunnel IPSEC e su uno di questi è già attestata la 
rete 192.168.1.x, mi hanno chiesto quindi di "nattare" la mia rete 
privata su un'altra (192.168.150.x) e qui iniziano i miei problemi.
Non posso usare SNAT o MASQ poiché questi funzionano in postrouting 
mentre io ho bisogno di far vedere al kernel il nuovo indirizzo IP 
*prima* che venga decisa la route da seguire.
Mi manca sicuramente qualcosa, avete qualche idea o un qualche link su 
cui informarmi?
grazie
-- 
Mi contraddico, forse?
Ebbene mi contraddico (sono vasto, contengo moltitudini)
                                         -- Walt Whitman

 privata su un'altra (192.168.150.x) e qui iniziano i miei problemi.
a parte che io utilizzo openswan ho risolto cos�:
- modifichi i due GW per utilizzare la nuova rete
- crei un alias su una if di rete
- crei uno SNAT
ovviamente per� loro a te non si collegheranno.
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 ovviamente però loro a te non si collegheranno.
che loro non si colleghino a me non è un problema, purtroppo non posso 
modificare il gw A, ho il controllo solo sul B.
Avevo già provato ad aggiungere un alias al mio nodo senza risultati, ma 
dopo il tuo messaggio ci ho riprovato e in effetti qualcosa di nuovo è 
successo (si vede che ieri ero cotto).
Ho aggiunto l'IP 192.168.150.1 alla eth3:0 (eth3 è la nic della lan con 
indirizzi 192.168.1.x) e la regola di SNAT in postrouting.
Un ping da un host nella rete riesce a tirare su il tunnel IPSEC (lo vedo 
dai log di racoon) ma l'host non riceve la risposta (tutto ok se invece 
il ping lo eseguo dal gw specificando l'ip sorgente).
Ho verificato /proc/net/ip_conntrack e la connessione icmp è "tracked", 
secondo te come mai non ricevo indietro il ping? (iptables flushato a 
dovere).


 *prima* che venga decisa la route da seguire.
E perchè?



perchè non avevo capito io come funziona il supporto IPSEC nei kernel 
2.6 :)
Credevo che il kernel dovesse vedere il nuovo source address prima di 
secegliere la route per decidere di far passare il pacchetto tramite il 
tunnel crittografato, invece (vedi risposta a CtRiX) non e' cosi'.
byez


 dovere).
ok, mi rispondo da solo, 
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
e' bastato un occhio a dmesg per capire che ero invaso dai marziani.
byez


 2.6
In effetti, lo "shock culturale" nel passaggio da *swan a ipsec-tools
può essere notevole; io avevo già esperienza su *BSD e, tutto sommato,
non disdegno il nuovo sistema, anche se i vari *swan avevano alcune
peculiarità comode, come le interfacce di rete ipsec*

 peculiarità comode, come le interfacce di rete ipsec*
ecco, le interfaccie ipsec, mi sono perso qualcosa o adesso (senza usare 
openswan) l'unico modo per capire che esiste un tunnel ipsec è usare 
setkey -D ?
con openswan se non altro vedi le route particolari e ti si accende un 
campanello di allarme.
bye


 setkey -D ?
Non mi viene in mente altro.