ipcop 1.4.0b3 : BUG VPN: Pblme de route et adresses sources!

[guiguid]

Bonjour,

1
IPcop 1.4.0b3
Green+red is modem
pppoa fast 800
green 192.168.0.254/24


2
IPcop 1.4.0b3
green+RED pppoe
modem pppoe
green 192.168.1.254/24

VPN site a site shared key

le vpn fonctionne !

sauf de passerelle a passerelle !!!!
le problème vient de l'adresse source :

exemple :

wget -c 192.168.1.254

--00:03:20-- http://192.168.1.254/
=> `index.html'
Connecting to 192.168.1.254:80... 00:03:20.746792 81.51.196.x.1080 > 192.168.1.254.80: S 2666397357:2666397357(0) win 32440 <mss 16220> (DF)

et evidement pas de réponse !

Que fait mon adresse RED sur le lien VPN !
Ce dervait etre 192.168.0.254 non ?
Lorsque je ping depuis l'intérieur du lan l'autre lan, pas de problème, c'est bien des adresse privees !
exemple :
tcpdump -n -i ipsec0
00:10:45.770607 192.168.0.12 > 192.168.1.3: icmp: echo request (DF)
00:10:45.910794 192.168.1.3 > 192.168.0.12: icmp: echo reply
00:10:46.771937 192.168.0.12 > 192.168.1.3: icmp: echo request (DF)
00:10:46.918614 192.168.1.3 > 192.168.0.12: icmp: echo reply
00:10:47.772432 192.168.0.12 > 192.168.1.3: icmp: echo request (DF)
00:10:47.910428 192.168.1.3 > 192.168.0.12: icmp: echo reply

losque je pinge depuis une passerelle :
tcpdump -n -i ipsec0
00:10:50.021881 81.51.196.x > 192.168.1.254: icmp: echo request (DF)
00:10:50.041845 81.51.196.x > 192.168.1.254: icmp: echo request (DF)
00:10:50.081851 81.51.196.x > 192.168.1.254: icmp: echo request (DF)

Mais que fait mon adresse RED dans le tunnel IPSEC ????

Gesp, une idée ?
Tu confirmes le bug ?

Guillaume

[guiguid]

J'ai bidouillé un debut de solution, neamoins fonctionnelle :
sur 1 :
iptables -I POSTROUTING -t nat -o ipsec0 \! -s 192.168.0.0/24 -j SNAT --to-source 192.168.0.254

sur 2 :
iptables -I POSTROUTING -t nat -o ipsec0 \! -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.254

D'accord, c'est crade, mais ca fonctionne !

Guillaume

[guiguid]

J'ai aussi noté un problème de MTU :

16436 c'est un peu beaucoup ! sachant que la couche supérieure (chez moi) ne peut en transporter que 1492 .... vite la fragmentation ....

Il serait souhaitable, a l'etablissement du tunnel, de regler
la MTU à taille MAXI de l'interface de sortie - taille du header IPSEC.

Cela éviterait des problèmes comme : viewtopic.php?t=15475

Si quelqu'un peu faire remonter tout ca avant la finale ....

Guillaume

[bisol]

As-tu envoyé 1 mail sur la mailing-list Devel ?

Je pense que cela touchera + de monde / Développeurs !

ou même mieux remplir la buglist

http://sourceforge.net/tracker/?atid=42 ... unc=browse

[guiguid]

C'est fait :
943276

[Gesp]

est-ce que tu utilises le proxy en cache transparent?
Dans ce cas, regarde le message d'aujourd'hui de Roy Walker

C'est surtout son restartsquid.c qui peut t'interesser.

[guiguid]

heuu,
J'ai ni trouvé dans les mailling list ni dans le bugtrack
ni dans le CVS restartsquid.c date d'il y a 3 mois !

Un lien ?

Merci

Guillaume

[guiguid]

trouvé
http://marc.theaimsgroup.com/?l=ipcop-d ... 800183&w=2

[guiguid]

En fait ca ne résoud pas mon probleme,
mais ca résoud celui la :

viewtopic.php?t=15550&start=30

[antolien]

C'est un faux problème, as-tu déjà analysé les trames sur autre chose qu'ipcop ?

C'est un problème inhérent aux serveurs vpn, comment veux tu communiquer en utilisant la même interface, des trames encapsulées passant par l'interface wan, alors que cette même interface doit envoyer des paquets déjà cryptés vers l'interface publique de l'autre serveur vpn ?

j'aurais pas assez de temps pour expliquer concrètement, mais franchement il faut bien comprendre ce qu'il se passe au niveau du routage avant de parler de BUG !

[tomtom]

J'ajouterai qu'en lisant un minimum de doc sur freeswan (voir sur ixus, car ca a deja été dit), tu saurais que pour faire communiquer 2 passerelles protegeant chacune un lan avec un vpn, il faut ajouter 3 tunnels : 1 ipcop 1 -> lan 2, un ipcop2 -> lan1, et un ipcop1->ipcop2

Il est tout à fait logique que par defaut, ta passerlle route via son interface par defaut !


t.

[guiguid]

C'est un faux problème, as-tu déjà analysé les trames sur autre chose qu'ipcop ?

Absoluement, sur 2 autres machines sur chaque lan, et meme constat.


C'est un problème inhérent aux serveurs vpn

T'as jamais utilisé autre chose qu'ipsec, parce que si tu avis utilisé PPTP ou Vtund tu saurait que c'est tout a fait possible !

comment veux tu communiquer en utilisant la même interface,


qui parle de la meme interface ?

ipcop1 --- ppp0 -- IPRED -- INTERNET --IPRED -- ppp0 -- ipcop2
ipsec0____/........................................................................\____ipsec0


Lan0 : 192.168.0.0/24
Lan1 : 192.168.1.0/24

tcpdump -i ipsec0 -->
seulement du trafic LAN2LAN avec des adresse privées !

tcpdump -i ppp0 -->
seulement du trafic WAN2WAN avec des adresse publiques !

tu le dis toi meme :
des trames encapsulées passant par l'interface wan, alors que cette même interface doit envoyer des paquets déjà cryptés vers l'interface publique de l'autre serveur vpn ?


j'aurais pas assez de temps pour expliquer concrètement, mais franchement il faut bien comprendre ce qu'il se passe au niveau du routage avant de parler de BUG !

Va-y prend ton temps, explique...
si t'arrive a m'expliquer pourquoi dans mon tunnel ipsec j'ai des packet ip avec une adresse source publique et une adresse destination privée, je t'invite a bouffer.

Guillaume

[guiguid]

tomtom ---->

C'est exact, j'ai du lire un peu plus la doc.

Parcontre, ce n'est pas un problème de route : le destination est bien trouvé !
C'est l'adresse source qui n'est pas la bonne WAN.

Je vais essayer d'etre plus clair :

#route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
193.253.160.3 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
193.253.160.3 0.0.0.0 255.255.255.255 UH 0 0 0 ipsec0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 193.253.160.3 0.0.0.0 UG 0 0 0 ppp0
192.168.1.0 193.253.160.3 255.255.255.0 UG 0 0 0 ipsec0

Lan1 192.168.0.0/24 ipcop 192.168.0.254
Lan2 à l'autre bout 192.168.1.254

lorsqu'un poste de LAN1 envois un packet (ping) au LAN2,
de la forme IPs=192.168.0.10 vers IPd=192.168.1.45
il envois ce packet avec l'adresse MAC destinaltion d'ipcop1
celui-ci faisant du routage, regarde s'il connait la route pour 192.168.1.0/24
oui, par l'interface ipsec0, il donne ce packet à ipsec0, encapsulation pour le transport : IPs'=WAN1,
definition du bout du tunnel : IPd'=WAN2, cryptage de la partie transportée,
recherche du chemein pour IPd'=WAN2, c'est ppp0, passage à ppp0, prochian routeur etc, etc....

Jusqu'a ipcop2
arrivé du packet sur WAN2, protocole 50, on passe a ipsec0, qui decrypte la partie transporte enlève IPs' et IPd', (on retouve donc IPs et IPd), il connait la route pour IPd, c'est son LAN2 par eth0, transmission du packet.

ce qui se passe d'ipcop1 à LAN2 ou ipcop2 à LAN1 ou ipcop1 à ipcop2, c'est que dans le tunnel, on a des packets avec IPs=WAN1 et IPd=LAN2 !! (bien sur ecapsuler dans IPs'=WAN1 et IPd'=WAN2)
Donc forcement LAN2 va directement répondre vers WAN1 et le packet est perdu.
C'est pour ca que j'ai résolu le problème avec :

sur ipcop1 :
iptables -I POSTROUTING -t nat -o ipsec0 \! -s 192.168.0.0/24 -j SNAT --to-source 192.168.0.254

sur ipcop2 :
iptables -I POSTROUTING -t nat -o ipsec0 \! -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.254

C'est quand meme pas grand chose et resoud bien le problème suivant :

Tout le LAN1 (ipcop compris) accede au LAN2 (ipcop compris) et réciproquement.

Disons, pour ceux qui sont un peu irrité de leur journée et qui ne supporte pasle mot BUG entre 23h30 et 0h30 que je me suis mal exprimer :
Ce nest pas un bug, mais un AJOUT DE FONCTIONNALITE.

A +
Guillaume

(J'espère que vous aurez passé une nuit bien repossante, et qu'un discussion bénéfique et sans cris s'en suivra.)
Le monde c'est ce que l'on en fait !

passage à l'interface ppp0,