[Résolu] Multiples connexions VPN (PPTP) à travers IPTABLES!

Support Debian
#1

Bonjour,
j’ai un firewall IPTABLES sous Debian.
Je dois effectuer une connexion VPN de mon réseau local vers un serveur VPN windows à l’extérieur.

Tout cela fonctionne pour un client VPN (=1 connexion VPN)

Ensuite, j’essaie d’établir 2 connexions VPN simultanément avec 2 PC :

- Sans les IPTABLES, ça marche sans problème ! j'établis mes 2 connexions VPN avec une seule adresse publique.

- Avec les IPTABLES, par contre, la connexion VPN ne marche que chacun son tour...

Je ne vois pas du tout pourquoi ?
Si chacun peut faire sa connexion VPN alors pourquoi ne peuvent-ils pas en créer une chacun en même temps ?
Bonne soirée et merci d’avance !
ccc29

#2

hello,

Met nous tes règles iptables pour voir.

#3

Salut !!!

Voici les règles qui concernent mes deux clients VPN :

#Déclaration de variables

lan="tr0"
wan=“eth0”

#Client VPN 1 (51.200.100.101) :

iptables -A FORWARD -i $lan -o $wan -p tcp --dport 1723 -s 51.200.100.101 -d 194.250.185.235 -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -p udp --dport 1723 -s 51.200.100.101 -d 194.250.185.235 -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -p gre -s 51.200.100.101 -d 194.250.185.235 -j ACCEPT

#Client VPN 2 (51.200.100.102) :

iptables -A FORWARD -i $lan -o $wan -p tcp --dport 1723 -s 51.200.100.102 -d 194.250.185.235 -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -p udp --dport 1723 -s 51.200.100.102 -d 194.250.185.235 -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -p gre -s 51.200.100.102 -d 194.250.185.235 -j ACCEPT

#Autoriser connexions établies ou en relation avec un connexion établie en #entrée

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

#NAT

iptables -t nat -A POSTROUTING -o $wan -j MASQUERADE

Je n’ai pas mis toutes les règles car c’est super long mais si tu préfères, je peux les mettre…
J’ai mis ce qui me semblait le plus important.
Merci pour ta réponse.
ccc29.

#4

Alors… Pas de nouvelles ???
Je ne trouve rien sur internet !
J’ai quand même du nouveau :
Celà fonctionne sur une liaison ADSL sans Firewall !
Alors pourquoi est-ce que IPTABLES bloque ça ?
Aidez-moi svp, je uis en galère là !
Bonne journée et merci d’avance à celui qui daigne me répondre…
A+.
ccc29.

#5

Hello,

Je n’ai pas trop le times openvpn.net/howto.html

#6

Salut Stonfi !

Merci pour le lien mais il concerne OpenVPN alors qu’il s’agit d’un serveur VPN Windows 2003 Server natif (IIS).
De plus, je pense vraiment que le problème vient d’IPTABLES, peut-être de mon NAT… Mais je n’arrive pas à comprendre pourquoi ?
D’ailleurs, est-ce qu’une autre personne que Stonfi aurait une idée ?!
Merci de t’intéresser à ce topic !
En espérant que d’autres personnes m’aident…
Bonne journée à tous !

ccc29.

#7

hello,

Sur le serveur en question essai de dumper le traffic avec etheral pour analyser ce qu’il ce passe.

#8

Salut !
Le problème, c’est que c’est un serveur distant où je n’ai aucun accès…
Vous ne pensez pas que c’est un problème de NAT ?!
Je suis Paumé…
Merci !
Bonne soirée !
ccc29.

#9

Si ça peux aider, experts-exchange.com/Network … 94051.html

#10

as tu le module ip_gre de chargé ?
quand tu dis que tu supprimmes iptables, tu supprimes justes les lignes correspondant au vpn et tu gardes le masquerading ou tu enlèves carrément tout ?
pourquoi mets tu du masquerading avec des adresses publiques ? pas moyen de faire un routage plutot ?

#11

Quand je fais un “lsmod”, je n’ai pas de ip_gre…

Non, j’ai fait le test sur une ligne ADSL sans firewall.

Ce ne sont pas des adresses publiques, ce sont les adresses de mon réseau local (je sais bien qu’elles ne font pas partie des “192.168.0.0” ou “10.0.0.0” ou “172.???” de tête mais c’est important que je garde ces adresses IP). De toute façon, je ne crois pas que ça change grand chose…

Merci à vous !
A+.
ccc29.

#12

[quote=“ccc29”][quote=“mattotop”]as tu le module ip_gre de chargé ?[/quote]Quand je fais un “lsmod”, je n’ai pas de ip_gre…(…)[/quote]Et donc, comme tu n’es pas de ces amorphes sans esprit d’initiative qui attendent qu’on leur dise ce qu’ils doivent faire, tu as bien sûr essayé de l’activer ?
Bien sûr… :wink:
alors qu’est ce que ça donne ?

#13

[quote=“mattotop”]Et donc, comme tu n’es pas de ces amorphes sans esprit d’initiative qui attendent qu’on leur dise ce qu’ils doivent faire, tu as bien sûr essayé de l’activer ?
Bien sûr… :wink:
alors qu’est ce que ça donne ?[/quote]

Je n’ai pas répondu car ça ne donne tout simplement rien et qu’un “amorphe” continue de chercher pour essayer de faire avancer le “Schmilblick”…
Ceci dit, je pense bien que c’est un début et que ça n’aurait jamais marché sans…
Merci !
ccc29.

P.S : Merci stonfi pour le lien mais il faut payer pour voir la réponse…

#14

bon, désolé, mais ça m’interresse de savoir ce que donnent mes suggestions : je suis les personnes que j’aide, moi. Je ne m’amuse pas à lancer des liens non vérifiés pour toute réponse.
Bon, mets ip_gre dans /etc/modules pour qu’il se charge parceque même si ça ne résout pas le pb, je suis à peu prés sûr de mêmoire que c’est obligatoire pour le pptp en nat.
Ensuite, mets ton pare feu en enlevant juste -i $lan -o $wan et -s 51.200.100.102 -d 194.250.185.235 les 6 lignes de vpn: ça marche ? alors rajoutes une à une les restrictions.

Tu peux au contraire remonter règle par règle tout ton parefeu, et ainsi determiner à quel moment ça ne passe plus=kel règle est fautive.

#15

je suis aussi…

#16

Salut !

C’est fait !

Non, ça ne marche pas. Ca ne change rien à mon problème sauf que maintenant on peut se connecter au VPN de n’importe quelle machine…[Logique !]

Ce n’est pas possible car le firewall est en production et je ne peux pas supprimer toutes les sécurités comme ça…

Merci de vous intéresser, c’est super sympa.
Juste comme ça, j’avais vraiment l’impression que c’était un problème de NAT, je ne suis donc pas du tout dans la bonne direction ?!
A+.
ccc29.

#17

tu dois avoir raison.
essayes un truc, puisque tu ne peux pas remonter ton pare feu par morceau pour tous les clients, mets en tête de chaque chaine (et dans chaque table) une règle ACCEPT pour les deux machines qui te servent au test, de manière à ce que pour elles, le passage par le routeur soit transparent comme s’il etait vide.
Ensuite, remontes une à une les règles actuelles au dessus de cette règle d’exception pour que les deux machines redeviennent comme le reste des clients (tu remonte le parefeu juste pour elles sans troubler les autres du coup).
Je pense que tu va tomber sur une exception au masquerading.
Question, tu as des règles stateful du genre
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $lan -m state --state NEW -j ACCEPT
:question:

#18

Tu veux dire que je fasse ça :

iptables -j ACCEPT -s “@IP_du_client” -d "@IP_du_serveur_VPN"
et ça pour les deux clients ?!
C’est ça mettre en tête de chaque chaîne ? Et que veux tu dire par dans chaque table ?

[quote=“mattotop”]
Question, tu as des règles stateful du genre
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $lan -m state --state NEW -j ACCEPT
:question:[/quote]

Oui, c’est ce qui permet d’accepter tous les retours sur ce qui a déjà été établi…

Merci.
ccc29.

#19

Tu veux dire que je fasse ça :

iptables -j ACCEPT -s “@IP_du_client” -d "@IP_du_serveur_VPN"
et ça pour les deux clients ?!
C’est ça mettre en tête de chaque chaîne ? Et que veux tu dire par dans chaque table ? (…)[/quote]Oui, sauf que je veux dire dans les deux sens et quand je parle de chaque table, je veux dire en nat, en mangle, et en raw, si tu as changé la policy par défaut ou si il y a des règles.
L’idée est que pour tous ce traffic là, tu fasse en sorte qu’aucun filtrage ne s’applique. Ensuite, tu fais s’appliquer unes à unes toutes les règles qui s’appliquent aux autres machines, pour déterminer à quel moment ça ne passe plus.
Ceci etant dit, PPTP etant cassable en 5 minutes, et pas vraiment performant, tu ferais mieux d’utiliser openvpn, c’est salement mieux et plus simple à mettre en oeuvre niveau parefeu (c’est uniquement de l’ip, tcp+udp).
En plus, c’est encore plus transparent que pptp sous win (une interface par tuyau que tu peux activer/desactiver quand tu veux), et salement plus robuste en plus d’être secure…
fin bon, c’est indépendant de la resolution de ton pb mais si tu es pressé et si tu n’as pas de contrainte, c’est tout benef pour toi:
forum.debian-fr.org/viewtopic.php?t=4376

#20

Ouh laaaa, je comprends bien le principe de faire en sorte qu’aucun filtrage ne s’applique sur le traffic mais “en nat, en mangle et en raw” ??? je ne vois pas bien comment je vais faire ça sachant que je ne sais pas ce qu’est “raw” et “mangle” (j’ai vu ça en cours, faut que je resorte mes vieux classeurs…)
Je regarde et je te tiens au courant si je trouve un jour la solution…

[quote=“mattotop”]Ceci etant dit, PPTP etant cassable en 5 minutes, et pas vraiment performant, tu ferais mieux d’utiliser openvpn, c’est salement mieux et plus simple à mettre en oeuvre niveau parefeu (c’est uniquement de l’ip, tcp+udp).
En plus, c’est encore plus transparent que pptp sous win (une interface par tuyau que tu peux activer/desactiver quand tu veux), et salement plus robuste en plus d’être secure…[/quote]

Je comprends bien mais je ne suis que client ici et je dois essayer de me débrouiller avec ce que j’ai… Je n’ai aucun moyen d’avoir d’infos sur le serveur à part l’@IP et le fait que ce soit en pptp avec le protocole gre !

[quote=“mattotop”]fin bon, c’est indépendant de la resolution de ton pb mais si tu es pressé et si tu n’as pas de contrainte, c’est tout benef pour toi:
forum.debian-fr.org/viewtopic.php?t=4376[/quote]

Je garde ça pour moi si je dois mettre en place un VPN, j’utiliserai surement OpenVpn sous Linux…

A+ et merci.
ccc29.