Traffic ne passe pas pour 1 routeur/firewall derrière IpCop

[paradox]

Bonjour,

Je connais IpCop depuis des années.
MAis là, je bloque...

Nous avons un routeur/firewall Gortigate avec 2 interfaces externes (Wan1 et Wan2).

Wan1 était la seule utilisée.
Notre connexion au net accueillant VPN, extranet pour les clients, mails, surf, etc. je désire décharger cette connexion de la volumétrie WEB pour la renvoyer vers WAN2 (connexion Orange ADSL Max) gerée par un IpCop.


Si je place une ou plusieurs machines derrière cette IpCop, ça passe, en surd direct ou avec le proxy, et/ou avec le proxy transparent activé.


Quand, sur le Fortigate j'active la règle de routage vers Wan2 pour le port 80, ça ne passe pas !

Mais dans l'affichage des connexions en temps réel d'IpCop, je vois bien mon Fortigate tenter quelque chose. Mais rien ne passe... Les machines derrière ne peuvent plus surfer.


Exemple de logs connexions :

tcp (6) 52 SYN_RECV 192.168.1.2 :56098 209.85.129.147 :80 192.168.1.1 :800 192.168.1.2 :56098 use=1
tcp (6) 49 SYN_RECV 192.168.1.2 :56097 193.22.143.79 :80 192.168.1.1 :800 192.168.1.2 :56097 use=1
tcp (6) 55 SYN_RECV 192.168.1.2 :56099 193.22.143.67 :80 192.168.1.1 :800 192.168.1.2 :56099 use=1
tcp (6) 57 SYN_RECV 192.168.1.2 :56100 84.16.84.67 :80 192.168.1.1 :800 192.168.1.2 :56100 use=1
tcp (6) 58 SYN_RECV 192.168.1.2 :56101 83.243.23.28 :80 192.168.1.1 :800 192.168.1.2 :56101 use=1

Où 192.168.1.1 = Interface LAN d'IpCop
Où 192.168.1.2 = Interface Wan2 du Fortigate


Avez-vous une idée ?




Je n'ai pas installé de mod tel que SquidGuard.


D'avance, merci.

[Franck78]

salut,

sans schéma même simplfié de comment est sont branchés ipcop switches adsl et autres, impossible de faire quoi que se soit d'efficace

[paradox]

Désolé !



Internet --- LiveBox Pro --- IpCop (sans filtrage) --- Fortigate --- LAN de la société




A terme, le surf sera transféré sur le proxy d'une autre IpCop reliant le LAN à la LiveBox.
En attendant (charte informatique, utilisateurs prévenus du log, etc.) je veux transférer le surf sur la 2e ligne, celle chez Orange. Ma seule façon possible pour l'instant, ajouter une règle (Routing policy) dans le FortiGate.

Apparemment les tentatives de connexions sont bien lancées (cf l'extrait du log plus haut), mais rien ne revient/rentre dans le fortigate (c comme ça que je le comprends pour l'instant). Mais je bloque...

[Franck78]

c'est toujours obsur...


mais:
1) on imagine que le fortigate a une troisième patte non dessinée qui est WAN1
2) ca marche derrière IPCop et avant le fortigate

3) ta règle route le http de LAN vers la patte wan2 ou plutot cell d'IPCop.
4) la livebox envoie TOUT sur RED de ipcop (mode dmz)

Le problème est que IPCop n'est pas un routeur, n'a rien de prévu pour apprendre que derrière son GREEN, en passant par fortigate, il y a un LAN......

Alors surement ça part vers internet mais le retour, il doit bien se demander quoi faire l'IPCop !

mais doit bien y avoir un ADDON pour règler ça.

[paradox]

Désolé

1) Oui, Fortigate utilise depuis toujours WAN1 (vpn, web, mails dans les 2 sens, etc.).

2) Oui

3) Oui, la règle dit que le surf passe maintenant vers WAN2 (ADSL MAx orange avec un IpCop intermédiaire).

4) non, la Livebox est une première "protection", en mode routeur, avant l'IpCop



Je ne vois pas pourquoi l'IpCop a besoin de savoir ça. Il a un client qui est le fortigate, qui NAT. Le fortigate s'occupe de remettre les données en retour à ses clients (LAN).


Si ce n'est pas le cas, je veux bien + de détails

[Franck78]

Essaie de pinger DEPUIS IPCop:

1) le fortigate, patte wan2
2) une machine située sur LAN

[paradox]

Même pas la peine d'essayer, je sais quel sera le résultat.

L'IpCop ne peut connaitre l'adressage/la route vers le LAN.
Le fortigate est un firewall normalement connecté au net (et routeur). Il n'accepte pas le ping.

C'est le fortigate qui gère la connexion et fait l'intermédiaire pour les machines du LAN.

Comme un IpCop classique qui gère une connexion au net pour un LAN.

[Franck78]

L'IpCop ne peut connaitre l'adressage/la route vers le LAN

et tu espères quoi? Que les paquets réponses INTERNET->LAN trouveront seuls leur chemin?

[paradox]

Hey ho..

PAs la peine de me prendre pour un débile.



Tu sais très bien qu'un IpCop (exemple) fait l'intermédiaire pour un LAN, qu'il gère les accès au net et les paquets en retour (NAT / Proxy). Sur Internet, personne ne connait l'adressage et les routes pour atteindre ton LAN. L'IpCop tiens sa table de NAT, et sur le net, il faut répondre à l'IP Publique de l'IpCop et point.

Là, même chose. Mon Fortigate a le même rôle. Le seul client de l'IpCop, c'est l'IP entre Fortigate et IpCop. IpCop n'a pas à savoir si il y'a un réseau derrière. C'est le Fortigate qui gère sa propre table de NAT et les paquets en retour.


La preuve, l'extrait de log donné dans le 1er post. L'ip cliente qui demande, c'est l'Ip du Fortigate côté IpCop.

[Franck78]

Il a un client qui est le fortigate, qui NAT.

Qui Natte. Info très discrète n'est-il pas. Ok j'a lu trop vite.

tcpdump est plus utile que la table conntrack. Il montre ce qui ne va pas.

On fait l'enchainement des NATs ne peut pas marcher correctement.

Imagine que chaque client de l'IPCop soit un fortigate. Disons 65530 petits fortigate. Et derrière chacun, autant de clients. Ce qui donne ~ 4 gigas clients. Tout ça masqués derrière une IP et trié au retour par le seul port source.....

Il te faut partager les ports sources entre les deux tables de nat ou supprimer un nat.

[paradox]

1 - Je ne comprends pas prq ça bloque, puisque (pour moi), chaque élément gère sa propre table de NAT. L'ipCop central n'a que (dans ton exemple) les fortigates comme clients, et ces derniers gèrent eux même leur table pour les PC.
A quel niveau ça coince ? Pour le NAT, ma machine qui s'en occupe modifie les paquet/en tête ? Donc 2 fois de suite c'est impossible que ça revienne à la machine cliente ?

2 - Tu proposes de supprimer un NAT.
Dans mon cas, je dois placer un IpCop intermédiaire pour avoir une idée de la volumétrie, et préparer les règles de surfs (black/whitelists). LE fortigate est obligatoire pour ne pas changer (impossible pour l'instant) la configuration du LAN, et l'IpCop aussi pour les logs, filtrage, etc.

3 - Tu parles de tcpdump. As-tu + d'infos stp ? J'imagine que c'est une commande à lancer (je ne peux vérifier pour l'instant). Y'a t'il des paramètres spécifiques à passer ? Une procédure à suivre pour obtenir les infos que tu "attends" ?

Merci

[HaM]

Salut
Je me permet de poser une petite question.

Quel est le plan d'adressage derrière le Fortigate ?
Et le Fortigate apprécie il vraiment d'avoir une IP privée sur son interface Wan ? (Doc ?)

[Franck78]

Je ne comprends pas prq ça bloque , puisque (pour moi), chaque élément gère sa propre table de NAT.

En pratique ca bloque pas car tu n'as pas les 65536 ports utilisés par une seule machine natteuse (c-a-d 65536 connexions). Je me suis peut-être imaginé à tord que tu ne te fixais pas de limite au nombre de machine capable de natter d'autres machines.

2 - Tu proposes de supprimer un NAT.

C'est qu'il na pas vraiment d'utilité(WAN2-LAN). Conserver un réseau TCP/IP normal est préférable. Comme tu l'as si bien remarqué, plus besoin d'apprendre le routage. Un peu domage pour un protocole routable

Tu parles de tcpdump. As-tu + d'infos stp ?

sur la syntaxe de la ligne de commande=>google ou man.

Le principe est d'afficher un résumé de ce qui arrive ou part par une interface (physique comme eth0 ou virtuelle comme Lo).
On suit donc à la trace un paquet et surtout ce qu'il en advient en traverssant une machine. Quand tout va bien, le serveur renvoit sa réponse à la machine client et de nouveau tcpdump permet de tracer le cheminent du paquet.
Ainsi on peut découvrir un filtrage de port, un comportement inattendu, bref n'importe quoi.


tcpdump -t -n -i xxx -p port

-t : pas besoin de date
-n numric
-i xxx tracer l'interface xxx (ppp0, eth0,.....)


-p port limite la trace au seul 'port'

[paradox]

Salut
Je me permet de poser une petite question.

1 - Quel est le plan d'adressage derrière le Fortigate ?
2 - Et le Fortigate apprécie il vraiment d'avoir une IP privée sur son interface Wan ? (Doc ?)

1 - Malheureusement, un adressage public (impossible à changer sans un énorme travail, ce sera fait un jour...).


2 - Je ne sais pas, mais dès que je peux, je change ça (manque de temps..).




Franck :
2 - Le fait de maintenir la config actuelle du Fortigate m'apporte par exemple la continuité de son filtrage (AV, permissions de surfs, etc.), ainsi qu'un gain de temps (espéré avant ces prbs) : nous voulions détourner vers la nouvelle ligne ADSL le flux de surf pour se faire une idée de l'utilisation (volumétrie principalement).

Si demain (si j'ai bien compris ce que tu proposes) j'ouvre le robinet pour envoyer directement les requetes vers l'IPcop :
a - L'iPCop ne sait pas renvoyer vers l'IP du "routeur" (Fortigate) d'après toi
b - Je n'ai plus l'application des règles de surf
c - je ne sais pas si le fortigate est capable de router vers Wan2 seulement le surf (je vais me renseigner, m'enfin, d'façon, puisqu'IpCop ne saura pas faire...).




Merci pour TcpDump !

[paradox]

J'ai eu du mal avec TcpDump. Impossible de filtrer par port (-p n'est pas un paramètre).


Résultats de TCP Dump :

arp who-has 192.168.1.1 tell 192.168.1.2
arp reply 192.168.1.1 is-at 00:0c:29:ac:b0:6a
arp reply 192.168.1.1 is-at 00:0c:29:ac:b0:6a
IP 192.168.1.2.49379 > 193.22.143.80.80: S 3024469013:3024469013(0) win 5840 <mss 1460,sackOK,timestamp 922196013[|tcp]>
IP 193.22.143.80.80 > 192.168.1.2.49379: S 1269955554:1269955554(0) ack 3024469014 win 5840 <mss 1460>
IP 193.22.143.80.80 > 192.168.1.2.49379: S 1269955554:1269955554(0) ack 3024469014 win 5840 <mss 1460>
...
IP 192.168.1.2.49380 > 193.22.143.80.80: S 1705747928:1705747928(0) win 5840 <mss 1460,sackOK,timestamp 922196050[|tcp]>
IP 193.22.143.80.80 > 192.168.1.2.49380: S 1278813508:1278813508(0) ack 1705747929 win 5840 <mss 1460>
IP 193.22.143.80.80 > 192.168.1.2.49380: S 1278813508:1278813508(0) ack 1705747929 win 5840 <mss 1460>
....
IP 192.168.1.2.49383 > 83.243.23.28.80: S 4050280609:4050280609(0) win 5840 <mss 1460,sackOK,timestamp 922196132[|tcp]>
IP 83.243.23.28.80 > 192.168.1.2.49383: S 1279069376:1279069376(0) ack 4050280610 win 5840 <mss 1460>
IP 83.243.23.28.80 > 192.168.1.2.49383: S 1279069376:1279069376(0) ack 4050280610 win 5840 <mss 1460>