Blocage par IPCop de paquets d'un VPN Equant (au niveau LAN)

[hp.menga]

Bonjour,
J'explique mon cas:

J'ai deux réseaux A et B reliés par un VPN Equant:
A a un plan d'adressage 10.162.192.0/20 + IPCop (V1.4.11: adresse VERTE/LAN 192.162.192.7)
B a un plan d'adressage 10.163.192.0/20 sans IPCop

Le routage du VPN Equant (deux routeurs sur chaque LAN) se fait de la manière suivante:
A ---> routeurA (192.162.192.50) -> EQUANT -> routeurB (192.163.192.50) -B
Pour cela toutes les machines du LAN-A ont comme gateway IPCop et dans IPCOp, j'ai ajouté un routage pour accéder aux machines du LAN-B (route add -net 192.163.192.0/20 gw 192.9.192.50 eth0).
En conséquence, à partir du réseau A, je peux pinger n'importe quelle machine du réseau B (et le traceroute est tout beau).
Par contre, à partir du réseau B, je n'arrive pas à pinger une machine du A!
Après quelques tcpdump sur la carte verte (eth0) d'IPCop, je vois bien du traffic ICMP, et là où j'ai confirmation que le problème vient d'IPCop, c'est que je retrouve dans les logs du pare-feu les paquets arrêtés:

Code: Tout sélectionner

Chaîne       Interface     Proto     Source     Port source     Destination     Port destination
OUTPUT       eth0        ICMP     10.162.200.73   ICMP  10.163.200.86   ICMP

Le seul moyen pour que j'arrive à pinger une machine du LAN-A (à partir du LAN-B), c'est de lui ajouter une route pour ne pas passer par IPCop, mais directement sur le routeurA pour la plage d'adresse du LAN-B (bref, de shunter IPCop)

Donc IPCop fait comme si la réponse d'une machine du LAN-A à une machine du LAN-B était bloquée alors que traditionnellement, tout ce qui vient du LAN (vert) et chaine OUTPUT est ouvert.
J'ai beau essayé de rajouter des règles iptables sur la chaine OUTPUT (à la main d'abord), j'ai l'impression que tout est by-passé.

Si quelqu'un a une idée ?

[Franck78]

Mais tu ne peux pas pinguer une machine derrière IPCop. C'est impossible.

IPCop masque son 'green' derrière une seule IP (le masquerade)
Le seul moyen d'atteindre une cible dmz ou green, c'est d'indiquer le port (le fameux transfert).


Je rapelle qu'IPCop n'agit pas comme un routeur. Il n'est pas fait pour ça à la base.

[hp.menga]

Bonjour Franck78,
je ne pinge pas une machine à travers IPCop, mais au travers des routeurs Equant (qui sont branchés sur chaque LAN de chaque réseau):
du LAN-A, une machineA pinge une machine B:
aller machineA ->IPCop -> routage vers routeurA -> EQUANT ->routeurB ->machineB >réponse ->routage vers routeurB ->machineA (OK)

mais du LAN-B, une machineB pinge une machineA:
aller machine -> routeurB -> EQUANT ->routeurA -> machineA > réponse ->IPCop ->blocage

alors que si sur la machineA, j'ajoute une route du type "route add -net 10.163.192.0/20 gq routeurA", le ping est OK, le traceroute est nickel, etc...

[Franck78]

je ne pinge pas une machine à travers IPCop

Alors je ne dois pas être le seul à ne rien comprendre à la façon dont tu as branché tout ça...!

[Franck78]

Désolé de t'envoyer ça en email privé, mais j'ai peur de poster plus que de raison, et être de moins en moins clair au fil des messages.

c'est vrai que je ne suis pas très clair en disant que je ne pinge pas au travers d'IPCop (bien sûr que ça passe par Ipcop à partir de eth0 (LAN).

Je ré-essaye:
les routeurs Equant sont sur le LAN. Pour utiliser le VPN Equant, j'ai effectivement ajouté une route supplémentaire (je sais, ce n'est pas génial) à IPCop (pour ne pas avoir à modifier toutes les machines du LAN-A dont la gateway par défaut est IPCop). Donc le traffic du LAN-A vers le LAN-B passe d'abord par la gateway (donc IPCop) puisque les machines du LAN-B ne sont évidemment pas dans la plage du LAN-A. La route d'IPCop transfère le flux vers le routeurA, ça sort de mon réseauA vers le LAN-B (via Equant), etc... et ça marche.

A l'inverse, le traffic du LAN-B à destination du LAN-A passe par le routeurB, arrive à destination sur la machineA, mais le retour (acknowledge ou ?, je ne sais pas) passe par IPCop (puisque la gateway de la machineA est IPCop), et là, IPCop le bloque!

Ce problème, je le constate par le traffic (tcpdump de eth0 qui voit bien les pings d'une machineB vers machineA), dans le journal du pare-feu (les chaines OUTPUT bloquées), et finalement, comme je le disais dans le post, si je mets la même route au niveau de la machineA, tout va bien.

Je sens bien qu'une solution lourde mais fonctionnelle serait de modifier toutes les gateways des postes clients du LAN-A (et mettre le routeurA) et mettre une règle dans le routeurA indiquant que tout le traffic n'étant pas à destination du LAN-B doit être re-routé vers IPCop, mais c'est beaucoup de boulot.

[Franck78]

Je vois bien le NAT qui vient perturber le système.

B envoie un ping a A; ok
A repond a B; ok. Sauf que la réponse passant par IPCop, celui place SON adresse source à la place de A.
B recoit un truc depuis IPCop, alors qu'il n'attend rien.

Vérifies ca stp.

[hp.menga]

J'ai fait un tcpdump sur l'eth0 d'IPCop lors d'un ping de machineB vers machineA. La trace me donne:

Code: Tout sélectionner

IP 10.162.200.162 > 10.163.12.3: icmp 40 echo reply seq 22533

Ce qui semble être la réponse de machineA vers machineB passant par IPCop (sans notion de NAT, à mon avis).
Ceci dit, (en plus) cela n'explique toujours pas les paquets qui sont droppés (ceux affichés dans le journal du parefeu).

[Franck78]

C'est quand même assez trouble la façon dont est organisé ton réseau. Pond un beau schéma pour t'aider.
Puis trace avec avec tcpdump "-i nom-d'interface"