pb routage ipcop vers Lan2 (shéma)

par **man_mickey2001** » 16 Déc 2006 21:50

Bonjour,
j'ai cherché un bon moment sans résultat et je lance donc un SOS aux Dieux ipcop

Je possède un ipcop (green , orange, red) allant vers internet via un routeur d'un fournisseur d'accès

Je possède aussi sur mon Lan (côté Green) un routeur me premettant d'accéder à des sites distants (liaison Wan )

tout d'abord un schéma :

maintenant je vous explique mon pb:
le poste sur Lan 1 (ip 172.16.64.101/255.255.254.0 gw 172.16.64.248) accède sans pb à Internet
Ce poste doit aussi se connecter en telnet sur le serveur de Lan2 en 172.16.32.12
Je ne veux pas effectué se routage statique sur les postes de mon Lan1, je voudrais que ce soit l'ipcop qui effectue les routages
sur ipcop connecté sur la lan1 en carte verte eth0: 172.16.64.248/255.255.254.0)
j'ai effectué un routage: /etc/rc.d/rc.local
route add -net 172.16.0.0 netmask 255.255.0.0 gw 172.16.64.1 eth0

Le poste lan1 pingue bien 172.16.32.12
le tracert de 172.16.64.101 vers172.16.32.12 indique qu'il passe par 172.16.64.248 puis 172.16.64.1 puis divers routeurs de mon fournisseurs d'accès puis 172.16.32.1 puis 172.16.32.12
par contre impossible de se connecter en telnet
la fenêtre de connexion s'ouvre avec un prompt: -
mais pas de login en retour
par contre si j'effectue un routage statique directement sur le poste Lan1:
route add 172.16.0.0 mask 255.255.0.0 172.16.64.1
là pas de pb de connexion en telnet, le login apparait et la connexion est possible

dans mon journal du pare feu ipcop j'ai ces messages lorsque 172.16.64.101 se connecte en telnet à 172.16.32.12:
17:39:42 NEW not SYN? eth0 TCP 172.16.64.101 1443 ::::: 172.16.32.12 23(TELNET)

Je comprend pas du tout ce qui se passe.

J'ai effectué un test avec une connexion TSE sur 172.16.32.12 , idem impossible de s'y connecter alors que cela fonctionne si j'effectue un routage statique sur le poste

Je ne veux pas avoir à effectuer des routages statiques sur tous les postes de mon LAn1

J'espère que mes information vous permettrons de m'aider
J'ai lu sur un post qu'il y aurait peut être des pb avec le SNAT mais là j'y comprend pas trop ..

Sur l'ipcop je n'ai installé que squidguard de Franck78 que je remercie au passage pour sa superbe interface et sarg pour générer des graphe des sites visités

Merci d'avance pour vos réponses

CDT

par **man_mickey2001** » 16 Déc 2006 22:16

juste une chose à laquelle je pense:
Dans service -> détection d'intrusion , j'ai coché Green, Orange et Red
ne faudrait-il pas décocher par hasard Green ?

Merci d'avance pour vos suggestions

par **man_mickey2001** » 19 Déc 2006 16:15

pour info:
le résultat d'un tracert à partir de 172.16.64.101 vers 172.16.32.12
tracert 172.16.32.12

Détermination de l'itinéraire vers 172.16.32.12 avec un maximum de 30 sauts.

1 <1 ms <1 ms <1 ms 172.16.64.248
2 5 ms 1 ms 1 ms 172.16.64.1
3 41 ms 42 ms 33 ms 172.31.28.5
4 65 ms 44 ms 43 ms 172.31.2.77
5 61 ms 72 ms 70 ms 172.31.2.78
6 * 68 ms 58 ms 172.16.32.12

Itinéraire déterminé.
Je passe bien par mon ipcop (passerelle par défaut) puis suis routé vers 172.16.64.1 qui est mon routeur vers mon Lan2
le ping à partir de 172.16.64.101 vers 172.16.32.12 fonctionne sans pb

j'ai effectué sur mon ipcop la commande suivante :
tcpdump -t -n -i eth0 host 172.16.32.12
puis lancé un telnet 172.16.32.12 à partir de 172.16.64.101
voici le résultat:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
IP 172.16.64.101.2584 > 172.16.32.12.23: S 1943103253:1943103253(0) win 64512 <m ss 1260,nop,nop,sackOK>
IP 172.16.64.101.2584 > 172.16.32.12.23: S 1943103253:1943103253(0) win 64512 <m ss 1260,nop,nop,sackOK>
IP 172.16.64.101.2584 > 172.16.32.12.23: . ack 1564887910 win 64512
IP 172.16.64.101.2584 > 172.16.32.12.23: . ack 1 win 64512
IP 172.16.64.101.2584 > 172.16.32.12.23: . ack 1 win 64512
IP 172.16.64.101.2584 > 172.16.32.12.23: . ack 1 win 64512

J'ai essayé en remontant un autre ipcop 1.4.11 sans aucun addon, le pb est identique le ping fonctionne par contre impossible de se connecter en telnet sur 172.16.32.12 ou sur un tse d'un serveur sur mon Lan2
Rq: les serveurs de mon lan2 ont comme passerelle par défaut 172.16.32.1
Merci pour vos suggestions

par **jmripert** » 19 Déc 2006 16:43

(nb: superbe explication !)

Depuis le lan2 tout passe ? réponse au ping vers lan1? résultat d'un tracert vers 172.16.64.101 depuis 172.16.32.12 ?

ps: je ne comprend pas pourquoi ton routeur-lan1 n'est pas derrière l'ipcop ? en parallèle du routeur internet... ça fait un gros trou quand même... :shock:

par **man_mickey2001** » 19 Déc 2006 18:12

j'avance un peu , ce doit être uneègle iptables qui bloque mais ne suis pas vraiment connaisseur.
en lançant une commande
iptables -F afin de supprimer les règles, le telnet vers le serveur 172.16.32.12 fonctionne

je vous joind le résultat de la commande iptalbes -L afin de voir si quelqu'un pourra me trouver la règle à appliquer afin d'auhoriser le routage vers mes réseaux distant 172.16.x.x:

Chain BADTCP (2 references)
target prot opt source destination
PSCAN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG
PSCAN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE
PSCAN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN
PSCAN tcp -- anywhere anywhere tcp flags:SYN,RST/SYN,RST
PSCAN tcp -- anywhere anywhere tcp flags:FIN,SYN/FIN,SYN
NEWNOTSYN tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state NEW

Chain CUSTOMFORWARD (1 references)
target prot opt source destination

Chain CUSTOMINPUT (1 references)
target prot opt source destination

Chain CUSTOMOUTPUT (1 references)
target prot opt source destination

Chain DHCPBLUEINPUT (1 references)
target prot opt source destination

Chain DMZHOLES (1 references)
target prot opt source destination

Chain GUIINPUT (1 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere icmp echo-request

Chain INPUT (policy DROP)
target prot opt source destination
ipac~o all -- anywhere anywhere
BADTCP all -- anywhere anywhere
CUSTOMINPUT all -- anywhere anywhere
GUIINPUT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
DROP all -- 127.0.0.0/8 anywhere state NEW
DROP all -- anywhere 127.0.0.0/8 state NEW
ACCEPT !icmp -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere
DHCPBLUEINPUT all -- anywhere anywhere
IPSECRED all -- anywhere anywhere
IPSECBLUE all -- anywhere anywhere
WIRELESSINPUT all -- anywhere anywhere state NEW
REDINPUT all -- anywhere anywhere
XTACCESS all -- anywhere anywhere state NEW
LOG all -- anywhere anywhere limit: avg 10/min burst 5 LOG level warning prefix `INPUT '

Chain FORWARD (policy DROP)
target prot opt source destination
ipac~fi all -- anywhere anywhere
ipac~fo all -- anywhere anywhere
BADTCP all -- anywhere anywhere
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
CUSTOMFORWARD all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
DROP all -- 127.0.0.0/8 anywhere state NEW
DROP all -- anywhere 127.0.0.0/8 state NEW
ACCEPT all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere
WIRELESSFORWARD all -- anywhere anywhere state NEW
REDFORWARD all -- anywhere anywhere
DMZHOLES all -- anywhere anywhere state NEW
PORTFWACCESS all -- anywhere anywhere state NEW
LOG all -- anywhere anywhere limit: avg 10/min burst 5 LOG level warning prefix `OUTPUT '

Chain IPSECBLUE (1 references)
target prot opt source destination

Chain IPSECRED (1 references)
target prot opt source destination

Chain LOG_DROP (0 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 10/min burst 5 LOG level warning
DROP all -- anywhere anywhere

Chain LOG_REJECT (0 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 10/min burst 5 LOG level warning
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

Chain NEWNOTSYN (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 10/min burst 5 LOG level warning prefix `NEW not SYN? '
DROP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ipac~i all -- anywhere anywhere
CUSTOMOUTPUT all -- anywhere anywhere

Chain PORTFWACCESS (1 references)
target prot opt source destination

Chain PSCAN (5 references)
target prot opt source destination
LOG tcp -- anywhere anywhere limit: avg 10/min burst 5 LOG level warning prefix `TCP Scan? '
LOG udp -- anywhere anywhere limit: avg 10/min burst 5 LOG level warning prefix `UDP Scan? '
LOG icmp -- anywhere anywhere limit: avg 10/min burst 5 LOG level warning prefix `ICMP Scan? '
LOG all -f anywhere anywhere limit: avg 10/min burst 5 LOG level warning prefix `FRAG Scan? '
DROP all -- anywhere anywhere

Chain REDFORWARD (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere
ACCEPT udp -- anywhere anywhere

Chain REDINPUT (1 references)
target prot opt source destination

Chain WIRELESSFORWARD (1 references)
target prot opt source destination

Chain WIRELESSINPUT (1 references)
target prot opt source destination

Chain XTACCESS (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere "ip carte red publique masquée" tcp dpt:ident

Chain ipac~fi (1 references)
target prot opt source destination
all -- anywhere anywhere
all -- anywhere anywhere
all -- anywhere anywhere

Chain ipac~fo (1 references)
target prot opt source destination
all -- anywhere anywhere
all -- anywhere anywhere
all -- anywhere anywhere

Chain ipac~i (1 references)
target prot opt source destination
all -- anywhere anywhere
all -- anywhere anywhere
all -- anywhere anywhere

Chain ipac~o (1 references)
target prot opt source destination
all -- anywhere anywhere
all -- anywhere anywhere
all -- anywhere anywhere

par **man_mickey2001** » 19 Déc 2006 18:14

pour jmripert:

les routeur 172.16.64.1 et 172.16.32.1 se trouvent sur un réseau sécurisé crypté de mon fournisseur d'accès donc pas de pb.
Ces routeurs n'a aucun accès au web
(liaison VPN faite sur les routeurs Cisco)

Le serveur 172.16.32.12 ping bien 172.16.64.101,
le serveur 172.16.32.12 a comme passerelle 172.16.32.1

il me semble que les paquets à destination de 172.16.32.x (et ne faisant pas partie d'adresses publiques) sont rejetés car ne faisant pas partie de mon lan (172.16.64.0)

par **jmripert** » 19 Déc 2006 18:43

Ok, je me disais bien qu'il yavait qqch... :roll:

Pour iptable je dis rien, je n'ai pas de brègles personnalisés ce qui arrange bien mes journées...

par **man_mickey2001** » 19 Déc 2006 19:08

pour jmrippert:

C'est bien le pb qd on ne maitrise pas iptables
Merci tout de même pour ta réponse

J'ai envisagé de mettre un routeur intercalé entre mon lan1 et l'ipcop qui lui fasse le routage
mais ca me complique le réseau
Si quelqu'un a une idée ...
Merci d'avance

par **man_mickey2001** » 22 Déc 2006 23:02

Bonsoir,
Personne ne connais bien iptables pour me premettre de me sortir de ce pb
j'ai beau chercher dans ce forum, aucune remarque sur ce pb de routage avec un ipcop et un routeur sur le Lan côté vert
HHHHHHEEEEEEELLLLLLLLPPPPPPPPP
Bonnes fêtes à tous

par **Franck78** » 23 Déc 2006 02:32

LE tcpdump dans le cas qui marche (iptables -F) serait tout aussi intéressant que dans le cas 'bloqué'.

Les régles de base du protocole IP veulent que dans ton cas de figure, l'IPCop renvoie au client un message icmp 'redirect' qui en gros veut dire: je ne suis pas le bon routeur, utilise plutôt celui-la...

Or, il n'y a rien qui sort de l'IPCop en retour.

Puis ton tcpdump est bien trop filtré. Contente toi de -i eth0 pour commencer.

Ce soir, j'ai pas le fonctionnement IPCop en tête. J'ai envie de dire qu'il n'envoie pas son icmp redirect.

par **tomtom** » 23 Déc 2006 13:01

Hello,

Mon avis : le problème se passe au niveau du handshake TCP :

- le paquet SYN passe par ipcop
- le paquet SYN/ACK ne passe pas par ipcop (la destination est directement joignable par le routeur) -> la connexion ne passe pas en l'etat established au niveau des conntracks
- la station du lan1 recoit le SYN/ACK et dont envoie le ACK.

Problème, cette configuration tcp n'est pas valide pour IPCop (cf chaine BADTCP) : en effet, voila une nouvelle connexion (NEW) qui passe directement au ACK sans fair le handshake. pas Glop ! -> DROP (comme te le signale ta log d'ailleurs, avec l'indication peu précise "new not syn?" ).

Analyse :
- IPCop devrait effectivement renvoyer un icmp redirect pour indiquer à la station emmetrice que les paquets ne doivent pas passer par elle car il y a une route plus directe. Or visiblement il ne le fait pas ou alors ta station n'en tient pas compte. Il arrive que par securité on ne tienne pas compte de ces paquets -> vérifier la configuration des hotes pour savoir s'ils le prennent en compte (sous linux, /proc/sys/net/ipv4/conf/*/accept_redirects , sous win ??)

Solutions palliatives dans l'ordre décroissant de pertinence :

- ajouter les routes sur les stations (pas une option pour toi, pourtant la bonne méthode

)

- "gruger" en masquant les adresses du lan 1 vis à vis du lan2 :

Code: Tout sélectionner: iptables -t nat -A POSTROUTING -p tcp -s @lan1/mask -d @lan2/mask -j MASQUERADE

ainsi les paquets retour passeront par ipcop aussi et le problème sera contourné.

- bricoler la BADTCP pouraccepter les trucs zarbis comme des paquets NEW sans SYN pour les connexions vers le lan2 (je te laisse le plaisir de trouver toi-même les règles iptables si cette solution te plait).

t.

par **Franck78** » 23 Déc 2006 13:40

C'est clair que le handshake ne se fait pas. Le client essaie même deux fois.
Le tcpdump dira si l'IPCop émet le message ICMP. Peut être bloqué, j'ai pas envie d'aller voir le source quand la réponse peut être llivrée.
L'accès vers GREEN est toujours interdit...

par **tomtom** » 23 Déc 2006 13:41

http://forums.ixus.fr/viewtopic.php?t=2 ... op+routage

Visiblement, une certaine version de IPCop au moins envoyait bien les icmp redirect

Par ailleurs ce post est interressant pour comprendre bien ce qui se passe !

A+

t.

par **man_mickey2001** » 24 Déc 2006 20:41

Un très grand merci à TomTom et Franck78 pour leur réponses

j'ai un peu de mal à comprendre tout mais j'essayerai dès la semaine prochaine ta commande Tomtom:
iptables -t nat -A POSTROUTING -p tcp -s @lan1/mask -d @lan2/mask -j MASQUERADE

De plus la solution que tu préconisais (un routage vers lan2 sur toutes les stations, j'aurais bien aimé mais plus de 80 postes à me cogner , je pensais à effectuer un routage statique paramétré sur mon serveur dhcp qui attribue les adresses mais le dhcp n'accepte que des routages statiques vers une seule station, on ne peux pas router un Lan (j'utilise un serveur dhcp sous Linux sur mon Lan1)

Franck78,
j'essayerai ta demande:
LE tcpdump dans le cas qui marche (iptables -F) serait tout aussi intéressant que dans le cas 'bloqué'.
et vous rendrais compte

merci beaucoup pour votre aide et très bonnes fêtes de fin d'année
Attention à l'alcool tout de même ...

par **man_mickey2001** » 27 Déc 2006 17:59

Me revoilou,
tout d'abord un grand grand MERCI à nTomtom et Franck78 pour leur aide.

J'ai appliqué la règle ds /etc/rc.d/rc.local:
route add -net 172.16.32.0 netmask 255.255.254.0 gw 172.16.64.1
iptables -t nat -A POSTROUTING -p tcp -s 172.16.64.0/255.255.254.0 -d 172.16.0.0/255.255.0.0 -j MASQUERADE

rebooté mon ipcop et là oh merveille!!!!!
CA MARCHE
à partir de LAn1 j'accède bien aux serveurs telnet Citrix, TSE sur mon site Lan2

Si je comprend bien la règle iptable,
le paquet lorsqu'il est envoyé de mon pc sur Lan1 vers mon serveur Telnet, y est inclu l'adresse de mon Firewall pour le retour ?

j'abuserais enore un tout petit peu auprès de Tomtom ou Franck78:
cette règle ne crée-t-elle pas un trou de sécurité sur le Firewall ?
pourrais-je affiner un peu la règle pour ne l'appliquer que sur la carte GREEN de mon Firewall ?

Merci encore pour votre aide