Newsgroup: it.comp.os.linux.sys
Titolo: stranezze su tunnel vpn con ipsec-tools

Ciao a tutti, sto cercando di risolvere un problema con una VPN, ma non 
ne vengo a capo.
La situazione è questa:
2 uffici collegati tra loro tramite VPN (tunnel). Ambedue gli uffici 
sono collegati a Internet tramite un firewall con Debian. Utilizzo 
ipsec-tools per terminare la VPN tra i due uffici.
192.168.190.0/24
       |
192.168.190.254 (eth0)
a.b.c.d (eth1)
       |
router ADSL
       |
internet
       |
router ADSL
       |
e.f.g.h (eth1)
192.168.191.254 (eth0)
       |
192.168.191.0/24
Il tunnel funziona. Le macchine si pingano:
da 192.168.191.100
PING 192.168.190.101 (192.168.190.101) 56(84) bytes of data.
64 bytes from 
192.168.190.101
: icmp_seq=1 ttl=62 time=88.5 ms
e viceversa, da 
192.168.190.101
:
PING 192.168.191.100 (192.168.191.100) 56(84) bytes of data.
64 bytes from 
192.168.191.100
: icmp_seq=1 ttl=62 time=95.8 ms
Dovrei essere tranquillo... e invece, le connessioni TCP in un senso
vanno, nell'altro no. Mi spiego meglio:
se da 192.168.191.100 provo a raggiungere la porta 80 di 192.168.190.101
riesco...
#telnet 192.168.190.101 80
Trying 192.168.190.101...
Connected to 192.168.190.101.
Escape character is '^]'.
ma non viceversa:
# telnet 192.168.191.100 80
Trying 192.168.191.100...
Li' per liì ho pensato a qualche problema di iptables... fatto varie
prove... niente. Allora ho provato a curiosare un po' con tcpdump, e ho 
scoperto una cosa strana. Se comparo il dump dei pacchetti tra le 4 
schede di rete dei 2 firewall, ecco cosa succede sul firewall della net 
190, quando lancio il telnet da 192.168.190.101 verso 
192.168.191.100
:
eth0 vede "partire" la richiesta
00:37:18.413305 IP 192.168.190.101.44808 > 192.168.191.100.80: S
369115004:369115004(0) win 5840 <mss 1460,sackOK,timestamp 135031618
0,nop,wscale 0>
eth1 vede arrivare il pacchetto di risposta...
00:37:18.504530 IP 192.168.191.100.80 > 192.168.190.101.44808: S
642549418:642549418(0) ack 369115005 win 5792 <mss 1460,sackOK,timestamp
1688810 135031618,nop,wscale 4>
ma pochi microsecondi dopo, su eth0 arriva un pacchetto con la source
port SBAGLIATA! (1 al posto di 80)
00:37:18.504584 IP 192.168.191.100.1 > 192.168.190.101.44808: S
642549418:642549418(0) ack 369115005 win 5792 <mss 1460,sackOK,timestamp
1688810 135031618,nop,wscale 4>
00:37:18.504662 IP 192.168.190.101.44808 > 192.168.191.100.1: R
369115005:369115005(0) win 0
00:37:22.414188 IP 192.168.191.100.1 > 192.168.190.101.44808: S
642549418:642549418(0) ack 369115005 win 5792 <mss 1460,sackOK,timestamp
1689788 135031618,nop,wscale 4>
Ho ricontrollato le regole di iptables: niente mangle, un po' di NAT e 
MASQUERADE... ma nulla che giustifichi una cosa del genere.
Ammetto di essere un po' arrugginito... ma non so che pesci pigliare.
Grazie per l'attenzione... e per le eventuali risposte.
-- 
Marco

 Ammetto di essere un po' arrugginito... ma non so che pesci pigliare.
stai nattando anche i pacchetti ipsec nella tabella NAT/postrouting.
Quello che è destinato verso l'altra subnet non dovrebbe essere nattato.
Max
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 Quello che č destinato verso l'altra subnet non dovrebbe essere nattato.
Concordo che ciň che č destinato all'altra subnet non dovrebbe essere 
nattato, quindi nelle regole di nat e masq escludo esplicitamente la LAN 
remota.
Nello specifico, le regole sono:
# Pool
iptables -A POSTROUTING -t nat -s ! 192.168.190.101 -o eth1 -d ! 
192.168.191.0/24
 -j MASQUERADE
# Ip pubblico per web server
iptables -A PREROUTING -t nat -d 81.112.x.y -i eth1 -j DNAT 
--to-destination 192.168.190.101
iptables -A POSTROUTING -t nat -s 192.168.190.101 -o eth1 -d ! 
192.168.191.0/24
 -j SNAT --to-source 81.112.x.y
e, specularmente, dall'altro lato... mi perplimo sempre piů.