Connexion VPN depuis DMZ vers NET

par **pepito_le_biscuit** » 27 Déc 2007 16:50

Bonjour,

Je recontre des problèmes de connexion depuis mon réseau en DMZ vers l'extérieur et donc il est impossible de se connecter au VPN de nos clients.

Voici la configuration :

////////////////////////////////////////////////////////////////////////////////////////////////////////////
@ internet ------routeur---------192.1.1.10 eth0 |ipcop| eth1 192.168.1.1 -------------LOCAL
///////////////////192.1.1.1 //////////////////////////////////// eth2 172.16.1.1 ---------------DMZ

Au niveau de eth0 j'ai crée des interface virtuelle
exemple : 192.1.1.11 / 192.1.1.12 / 192.1.1.13

Et donc je redirige mes interfaces virtuelles vers le réseau DMZ
ainsi que les ports dont j'ai besoin uniquement
exemple : 192.1.1.11 ------------> 172.16.1.11
192.1.1.11:80 ----------> 172.16.1.11:80

En DMZ j'ai un poste en 172.16.1.11 sur le quel j'aimerais pouvoir me connecter en VPN chez mes clients externe "sur le net".

j'ai redirigé les flux arrivant sur l'interface virtuelle 192.1.1.11 vers 172.16.1.11
j'ai rédirigé tous les ports TCP et UDP et aussi le GRE des 192.1.1.11 vers 172.16.1.11
Et quand je tente une connexion vers le VPN d'un client externe j'arrive jusqu'à la phase d'authentification sur leur VPN, mais aprés blocage et la connexion échoue.
(pour information je me connecte avec le client VPN intégré à windows)

J'ai l'impréssion que le retour des packets se fait mal et cela depuis que j'ai fais la translation d'adresse de 192.1.1.11 vers 172.16.1.11

Quelque sais t'il comment resoudre le problème ou à t'il déja rencontré ce cas de figure ?

Si je me connecte avec un poste client placer entre le routeur et le firewall Ipcop cela fonctionne trés bien.

Merci.

par **ccnet** » 27 Déc 2007 17:36

Je regrette de vous dire que vos explications sont assez confuses. Avant tout j'aimerai être certain de comprendre ce que vous souhaitez faire.

En DMZ j'ai un poste en 172.16.1.11 sur le quel j'aimerais pouvoir me connecter en VPN chez mes clients externe "sur le net".

Ce que je comprend : depuis la machine 172.16.1.11, située dans votre dmz, vous voulez vous connecter via vpn chez l'un de vos clients.

En premier lieu je ne comprend pas bien pourquoi vous travaillez depuis la dmz. Ce n'est pas le lieu pour faire cela, mais passons.
Ensuite pourquoi ces adresses 192.1.1.10 et suivantes ? Quel est le comportement de votre routeur vis à vis de ces adresses ? Elles sont vos ip publiques ?

A défaut d'y voir clair chez vous, j'utilise des connexions vpn depuis mes machines du réseau GREEN vers des clients, certains en open vpn, d'autres en cisco ou encore avec MS et je n'ai jamais mis en place la moindre translation dans les règles d'ipcop et encore moins "d'interface virtuelle".

Je vous conseille d'indiquer plus clairement votre configuration (addons ?) et ce que vous souhaitez faire (et de ne pas induire une solution a priori). Dans ce que l'on peut comprendre votre cas de figure est assez banal. En ce cas, en restant dans le cadre défini pour l'usage normale d'ipcop, tout devrait fonctionner facilement sans toutes ces interfaces et transferts de ports.
Je vous rappelle que le traffic provenant de GRENN ou ORANGE ne nécessite aucun transfert de port pour son retour.
Si ce n'est pas cette situation c'est qu'il nous manque des infos.

par **Franck78** » 27 Déc 2007 19:27

Il y a un problème connu depuis très longtemps sur IPCop avec les adresses virtuelles (les alias de leurs vrais nom).
Ils ne servent à presque rien car il n'y a pas moyen d'indiquer à IPCop que telle ou telle machine en GREEN ou DMZ doit utiliser l'alias. Un flux d'origine locale utilisera toujours l'IP de base comme source.

La conséquence est qu'un client extérieur peut avoir l'impression de dialoguer avec deux machines quand il n'en attend qu'une....

par **ccnet** » 27 Déc 2007 19:35

Absolument et la seule solution que je connaisse, trouvée ici, pour contourner le problème consiste à modifier /etc/rc.d/rc.firewall, et à ajouter la ligne suivante pour chaque serveur de la DMZ:

/sbin/iptables -t nat -A REDNAT -s ip_local_dmz -o $IFACE -j SNAT --to-source ip_public

juste avant la ligne:

/sbin/iptables -t nat -A REDNAT -o $IFACE -j MASQUERADE

Mais on sort déjà pratiquement du cadre normal de l'utilisation d'IPCOP. C'est typiquement le genre d'évolution qui serait très bienvenu dans une prochaine version.

par **Franck78** » 27 Déc 2007 20:00

mouais, le request existe depuis belle lurette sur sourceforge. La version suivante apportera une nouvelle interface, un openvpn installé (j'ai pas dis intégré pour ça il faut revoir un gros morceau d'ipcop).
La tendance actuelle va vers un IPCop avec deux/trois addons ajoutés mais pas vraiment d'évolutions significatives (pour la partie firewall je précise bien).

par **pepito_le_biscuit** » 27 Déc 2007 21:49

Bon comme je n'ai pas été assez clair voici exactement ma configuration actuelle.

Imaginons maintenant que j'ai un poste (172.16.1.11) sur mon réseaux DMZ depuis lequel je veux me connecter en VPN à un client externe (une autre société par exemple)
Quand je tente une connexion vers le VPN du client externe j'arrive jusqu'à la phase d'authentification sur leur VPN, mais aprés blocage et la connexion échoue.

Et comme j'en ai déduit que c'était le retour des paquets qui posés problème c'est pour cela que j'ai décidé
de rediriger tous les ports TCP et UDP et aussi le GRE de 192.1.1.11 vers 172.16.1.11 pour permettre un retour sur.
(bien que normalement tous ce qui sort de la DMZ vers l'extérieur est autorisé à entrer)

Mais le problème reste exactement le même.

Je précise à nouveau que si je me place juste après le routeur cisco avec l'ip en 192.1.1.11 la connexion VPN fonctionne bien.

J'espère avoir été plus clair dans mes explications.

* Pour ce qui est de la réflexion de ccnet : "En premier lieu je ne comprend pas bien pourquoi vous travaillez depuis la dmz."
Je suis d'accord avec vous mais si j'arrive à trouver une solution depuis la DMZ, il en sera de même pour les connexions depuis le réseau GREEN

par **ccnet** » 27 Déc 2007 23:16

Beau schéma. Mais ... le routeur Cisco est connecté par deux liaisons au réseau 9C. Nous ne savons toujours pas le pourquoi des adresses 192.1.1.10 et suivantes ... Différence 9C et internet ? 192.1.1.1 est une ip publique, pourquoi translater 86.7.x.y vers une autre ip publique avec le Cisco ?
Qu'est ce qui vous fait dire que le retour des paquets ne se fait pas alors que vous parvenez jusqu'au stade de l'authentification (donc les paquets reviennent bien) ?
Avez vous pris en compte la remarque de Franck :

Un flux d'origine locale utilisera toujours l'IP de base comme source.

?

Je vous suggère un test dans une configuration saine, du moins, une configuration qui convient avec IPCOP:
ip publique sur l'interface RED.
supression de tous les alias.
supression de tous les transferts.
machine cliente dans le lan en GREEN.

Vos connexions vpn devraient fonctionner sans autre modification.
Je sais que cette configuration fonctionne (je l'utilise) avec le client vpn MS, avec un client Cisco, avec un client OpenVPN. La différence que je vois c'est qu'avec une translation votre connexion vpn s'établie et qu'avec deux translations elle ne fonctionne plus. Ma suggestion a pour objectif de lever le doute. Je ne comprend pas la complexité de votre configuration alors qu'il s'agit simplement de connecter une machine cliente à un vpn, ce qui fonctionne avec une configuration de base d'ipcop.
Vous avez besoin d'une dmz ? si oui conserver la, mais mettez vos clients dans le LAN. Ipcop est prévu pour fonctionner ainsi.

par **pepito_le_biscuit** » 28 Déc 2007 00:05

le routeur Cisco est connecté par deux liaisons au réseau 9C

Ceci est une connexion SDSL 4 Méga (2x2méga) avec une agrégation de lien par paquet qui permet d'additionner les flux afin d'obtenir un débit de 3,50Mo/s c'est complètement transparent.

Nous ne savons toujours pas le pourquoi des adresses 192.1.1.10 et suivantes

L'adresse 192.1.1.10 et l'interface RED de IPCOP qui permet la liaison internet avec le routeur CISCO.
Le pourquoi des adresses 192.1.1.x et que nous possédons une plage de 30 IPs public 86.64.x.x que nous redirigons vers les IPs virtuelles en 192.1.1.x
(merci de considérer les IPs en 192.1.1.x comme des adresses IP privés car suite à une migration de FAI ils nous à été impossible de les modifier afin de ne pas bousculer toute la production)

Différence 9C et internet

La différence est que nous avons 2 sites un sur Toulouse et un sur Paris et nous avons une solution VPN chez neuf Cegetel pour interconnecter nos deux sites, les échanges inter-sites passe alors sur le réseau 9C et ne sortent pas sur le NET.

Qu'est ce qui vous fait dire que le retour des paquets ne se fait pas alors que vous parvenez jusqu'au stade de l'authentification (donc les paquets reviennent bien) ?

Voici ce que j'obtiens lorsque je tente une connexion en VPN :

La connexion ne va pas plus loin et échoue au bout d'un certain temp.

La différence que je vois c'est qu'avec une translation votre connexion vpn s'établie et qu'avec deux translations elle ne fonctionne plus

- La 1er translation de l'ip public 86.64.x.x vers l'ip 192.1.1.11 aboutie car 9C a ouvert tous les ports vers cette IP
- La 2nd translation de l'ip virtuelle 192.1.1.11 vers 172.16.1.11 fonctionne correctement pour tout sauf pour établir une connexion vers un VPN externe.

Avant l'installation de IPCOP notre DMZ était juste dérrière le routeur en 192.1.1.x et la machine en 192.1.1.11 était capable de se connecter en VPN chez nos clients externes.

Mais depuis la mise en place de IPCOP et le passage de notre DMZ en 172.16.1.x derrière le firewall IPCOP nous ne somme plus capable de nous connecter en VPN, j'en déduis donc que les translations d'adresse de 192.1.1.x vers 172.16.1.x y sont pour quelque chose.

*Si possible ne pas prendre en compte la partie qui se trouve à gauche du routeur CISCO sur le schéma cela relève plus des services de 9C et après avoir réalisé des tests j'ai bien vu que le VPN fonctionné bien sans la translation de 192.1.1.11 vers 172.16.1.11.

par **Franck78** » 28 Déc 2007 01:53

pepito_le_biscuit a écrit:
- La 2nd translation de l'ip virtuelle 192.1.1.11 vers 172.16.1.11 fonctionne correctement pour tout sauf pour établir une connexion vers un VPN externe.

c'est ce qu'on dit depuis le début. La connexion apparait avec 192.1.1.10 et pas .11 pour le serveur chez 9C.

par **ccnet** » 28 Déc 2007 01:59

Le pourquoi des adresses 192.1.1.x et que nous possédons une plage de 30 IPs public 86.64.x.x que nous redirigons vers les IPs virtuelles en 192.1.1.x
(merci de considérer les IPs en 192.1.1.x comme des adresses IP privés car suite à une migration de FAI ils nous à été impossible de les modifier afin de ne pas bousculer toute la production)

On en revient toujours au même problème. Cette information aurait du être donnée dès le premier post. C'est seulement maintenant que l'on commence à comprendre votre configuration pour le moins inhabituelle. On peut toujours "considérer" ce que l'on veut. Mais la réalité est que votre adressage n'est pas correct dans sa conception. Les adresses 192.1.1.10 et suivantes ne vous appartiennent pas.

Je réitère mon conseil pour une configuration saine (et qui fonctionne) :
Les ip publiques 86.64.x.y devraient être sur l'interface RED d'ipcop. Ne faites plus de NAT sur le routeur. Vous éviteriez bien des soucis comme celui ci et d'autres sans doute plus tard. Toutefois n'oubliez pas ce que Franck a indiqué et gardez éventuellement en mémoire la solution que je n'ai fait que recopier.
Si maintenant vous aviez besoin de configurations plus sophistiquées, IPCOP ne convient probablement plus. Voyez éventuellement Pfsense.

Votre problème n'est pas avec IPCOP. Je ne sais qui a conçu cette solution réseau. Elle ne me semble ni sérieuse, ni conforme aux règles de l'art comme l'on dit. Si c'est vous, tant pis. La bonne solution est beaucoup plus simple, c'est celle que j'indique plus haut. Dans votre configuration actuelle je ne vois qu'une complexité inutile et aucun avantage.

par **Franck78** » 28 Déc 2007 04:47

Je suis pas trop sur d'avoir compris le pourquoi des cette série d' IP 192.1.1.0/x . Mais la n'est le problème.
Il y avait avant IPcop trente+/- machines avec chacune son IP 192.1.1.0/x. Elles ont 'disparus' derrière IPCop mais IPCop gère à moitié les alias IP. Donc
-soit corriger IPCop
-soit installer VMware et un IPCop pour chaque adresse.

par **pepito_le_biscuit** » 28 Déc 2007 10:52

Les ip publiques 86.64.x.y devraient être sur l'interface RED d'ipcop

Dans ce cas considérons que je demande à 9C de rediriger toutes les IPs publics vers l'interface RED uniquement sur l'ip 192.1.1.10

Comment établir les redirections de port vers mes différents serveurs en DMZ.

Exemple:
Pour un serveur ssh le client se connecte depuis internet avec son client SSH qui correspond à une de mes adresses Public sur le port 22.
Il faut donc que neuf me redirige le port 22 de l'IP 86.64.x.x vers l'interface RED 192.1.1.10 port 22.
Ensuite il faut que j'assure moi même la redirection du port 22 de 192.1.1.10 vers l'un de mes serveur de DMZ, seulement je ne peux rediriger le port 22 de l'interface RED que vers une seule machine de DMZ
Comment gérer le problème si j'ai plusieur serveur SSH en DMZ ? De même pour les autres services (ftp,rpc,etc...)

par **ccnet** » 28 Déc 2007 11:07

Dans ce cas considérons que je demande à 9C de rediriger toutes les IPs publics vers l'interface RED uniquement sur l'ip 192.1.1.10

Ce qui ne réglera rien. Désactivez le nat sur votre routeur pour avoir les adresses publiques sur l'interface RED. Vous ferez déjà fonctionner vos connexions vpn.

Comment établir les redirections de port vers mes différents serveurs en DMZ.

IPCOP ne sait pas gérer cela. Nous vous le répétons à chaque post. La solution est celle que j'ai donné plus haut en modifiant etc/rc.d/rc.firewall. Il faudrat une ligne par serveur en dmz. Ce problème n'ayant aucun rapport avec l'objet initial du poste.

par **pepito_le_biscuit** » 28 Déc 2007 11:26

Je vous remercie pour toute vos réponses et pour vos recherches.

Je vais étudier le problème en profondeur et voir ce que propose les solutions basées sur BSD également.

Au pire les connexions VPN seront redirigées vers une connexion de type free.

Connexion VPN depuis DMZ vers NET

Connexion VPN depuis DMZ vers NET

Qui est en ligne ?