Firewall perso pour contourner numericable

Support Debian
#21

Merci pour toutes vos réponses, retour des testes,

[quote=“PascalHambourg”]

  • Sur le firewall côté client :

iptables -t nat -A OUTPUT -o $if_ext -p tcp --dport 445 -j DNAT --to :1445 iptables -t nat -A POSTROUTING -o $if_ext -p tcp --sport 445 -j SNAT --to $ip_ext:1445
où if_ext est l’interface du firewall connectée à la box et ip_ext son adresse IP.

  • Sur le firewall côté serveur :

iptables -t nat -A PREROUTING -i $if_ext -d $ip_ext -p tcp --dport 1445 -j DNAT --to $ip_serveur:445
où if_ext est l’interface extérieure du firewall, ip_ext son adresse IP et ip_serveur l’adresse IP interne du serveur SMB.[/quote]

Ne fonctionne pas sur une box numericable, du coup, j’ai testé le firewall avec une box free et la ça fonctionne, j’en conclu que avec numericable on ne sais pas dérouter smb. :119

Je suis donc bien coincé, la solution VPN n’est pas viable pour déployer sur plusieurs sites. :013

Seul solution, déménager dans une zone ou il y à free avec un bon débit. :confused:

#22

Hein ?
Bien sur que si …

#23

[quote=“CreatAddict”]Merci pour toutes vos réponses, retour des testes,
[…]

Ne fonctionne pas sur une box numericable, du coup, j’ai testé le firewall avec une box free et la ça fonctionne, j’en conclu que avec numericable on ne sais pas dérouter smb. :119
[/quote]Ou peut être tu crois que ça marche et que tu adresses directement le serveur sans utiliser les règles.
As tu testé tes règles bêtement avec tcpdump et des telnet sur les ports concernés? Tu devrais voir là où ça coince.

Je vais jsute le faire Vendredi :slightly_smiling:

#24

Quand je dit “pas viable…” c’est pas quelque personne à connecter sur une VM, mais plusieurs personnes sur plusieurs VM…

Une VM est une machine virtuel ou il y à samaba installé

#25

Cela ne pose strictement aucun problème. Un VPN peut se comporter comme un réseau physique.

Pour tes règles, il te faut faire du DNAT et non SNAT dans ton parefeu. Le POSTROUTING ne peut que modifier la source. Il est doncnécessaire de faire la translation sur les chaines entrantes. Ce serait donc

iptables -t nat -A OUTPUT -o $if_ext -p tcp --dport 445 -j DNAT --to :1445 iptables -t nat -A PREROUTING -i $if_int -p tcp --dport 445 -j DNAT --to $ip_ext:1445

et

iptables -t nat -A PREROUTING -i $if_ext -d $ip_ext -p tcp --dport 1445 -j DNAT --to $ip_serveur:445

Fonctionne parfaitement chez moi en bloquant le port 445

#26

Et avec la box Free sans les règles de NAT, ça fonctionne aussi ?

Attention : j’ai écrit “par exemple pour le port 445”, mais si ton client SMB utilise d’autres ports et/ou protocoles (137, 139…, en TCP et UDP) il faut aussi des règles pour chaque combinaison de port/protocole.

Si tous les ports Netbios/SMB/CIFS sont modifiés avant de partir à l’extérieur, le firewall de Numericable ne peut identifier ce type de trafic que s’il analyse le contenu des paquets par DPI (Deep Packet Inspection) indépendamment des ports. Dans ce cas le VPN chiffré risque d’être la seule solution.

Côté client, il faut aussi faire du SNAT dans POSTROUTING au cas où le poste client utilise un port source identique au port destination (déjà constaté sur des machines Windows). Ta règle DNAT dans PREROUTING qui redirige vers l’adresse externe du firewall n’a pas de sens, il ne faut pas modifier l’adresse destination des connexions sortantes mais seulement le port. En revanche j’ai mis la règle DNAT dans la mauvaise chaîne (OUTPUT) qui serait valable pour des connexions émises par le firewall lui-même. Il faut la mettre dans la chaîne PREROUTING :

où if_int est l’interface du firewall connectée au poste client et ip_int son adresse IP.

#27

[quote=“PascalHambourg”]
Côté client, il faut aussi faire du SNAT dans POSTROUTING au cas où le poste client utilise un port source identique au port destination (déjà constaté sur des machines Windows). Ta règle DNAT dans PREROUTING qui redirige vers l’adresse externe du firewall n’a pas de sens, il ne faut pas modifier l’adresse destination des connexions sortantes mais seulement le port. [/quote]

J’ai fait les lignes et les tests avec ip_ext = IP de la machine distante (tests à coup de telnet et tcpdump pour vérifier), je précise effectivement tout à chaque fois dans les règles pour avoir une vision claire, là du cela n’avait pas de sens effectivement.

Par contre pour le SNAT, je n’ai pas compris ta remarque, puisque coté client il voit un serveur avec le port 445 donc dans ce cas il utilisera le port 445, et le serveur lui recevra une connexion arrivant sur le port 445 donc s’attendant dans ce cas à une connexion venant du port 445 ce qui ne sera jamais le cas vu de toute façon la translation d’adresse à la sortie de la box numericable

#28

Là c’est moi qui ne comprends pas ta remarque.
Il arrive que le client se connecte au serveur SMB depuis un port source identique au port destination (bloqué par le FAI). Si on se contente de modifier le port destination, les paquets sortants risquent d’être bloqués par le FAI à cause du port source (ou les paquets de réponse entrants à cause du port destination). Le NAT de la box ne modifie pas forcément le port source des connexions sortantes ; les cibles SNAT ou MASQUERADE d’iptables ne le modifient que si c’est nécessaire pour éviter une collision avec une autre connexion. Exemple : deux postes internes font une connexion au même port du même serveur externe depuis le même port source.

En y repensant, cette situation pourrait se produire dans le cas présent et une règle SNAT imposant un port unique pourrait empêcher plus d’une connexion. Il serait plus sage de prévoir une plage de ports de taille supérieure ou égale au nombre de postes plutôt qu’un port unique.

#29

[quote=“PascalHambourg”]Là c’est moi qui ne comprends pas ta remarque.
Il arrive que le client se connecte au serveur SMB depuis un port source identique au port destination (bloqué par le FAI). Si on se contente de modifier le port destination, les paquets sortants risquent d’être bloqués par le FAI à cause du port source (ou les paquets de réponse entrants à cause du port destination).[/quote]Exact je n’avais pas pensé au blocage dans ce cas, je pensais que tu faisais référence à une attente supposée du serveur que la connexion vienne du même port ce que je trouvais hasardeux.[quote] Le NAT de la box ne modifie pas forcément le port source des connexions sortantes ; les cibles SNAT ou MASQUERADE d’iptables ne le modifient que si c’est nécessaire pour éviter une collision avec une autre connexion. Exemple : deux postes internes font une connexion au même port du même serveur externe depuis le même port source.[/quote]Je pensais que c’était quasi systématique, mais effectivement je viens de vérifier que dans la pratique, il n’est pas modifié. En fait c’est en regardant les logs de mes trois serveurs NTP (qui sont dans le pool), j’ai constaté que sur 500 connexions, seules 200 (en gros) venaient du port 123, du coup je me disais qu’en gros 60% des connexions se faisaient via du masquerading et y voyais une confirmation que le port de sortie était modifié quasi systématiquement. Du coup, en réflechissant (ça aide en fait…) ça signifie plutôt que 60% des gens utilisent des clients simples genre ntpdate sans port de sortie dédié.

[quote]
En y repensant, cette situation pourrait se produire dans le cas présent et une règle SNAT imposant un port unique pourrait empêcher plus d’une connexion. Il serait plus sage de prévoir une plage de ports de taille supérieure ou égale au nombre de postes plutôt qu’un port unique.[/quote]
Ça se fait par --to-ports 1445-1555(par exemple) si ma mémoire est bonne.

#30

Presque. L’option [mono]–to-ports[/mono] est pour les cibles [mono]MASQUERADE[/mono] et [mono]REDIRECT[/mono]. Pour [mono]SNAT[/mono] (et [mono]DNAT[/mono]), on spécifie une plage de ports sous la forme [mono]–to :1445-1555[/mono]. On peut aussi utiliser l’option [mono]–random[/mono] qui sélectionne un port aléatoire.

#31

pour en revenir à la question de départ, il aurait du faire ça alors:

iptables -t nat -A PREROUTING -d 192.168.1.1 -p tcp -m multiport --dports 1135 -j DNAT --to-destination 192.168.0.132 iptables -t nat -A POSTROUTING -d 192.168.0.132 -p tcp -m multiport --dports 1135 -j MASQUERADE

sans oublier echo 1 > /proc/sys/net/ipv4/ip_forward

#32

Nykoos, je ne comprends pas la pertinence de tes règles iptables. Peux-tu les expliquer ?
La première redirige les paquets envoyés à l’adresse externe du firewall vers le poste client. Mais le NAT fait déjà automatiquement ça avec les paquets de réponse, pas besoin de règle supplémentaire. Les deux ne modifient pas les ports source ni destination, donc je ne vois pas comment cela va aider à passer le filtrage du FAI.

#33

[quote=“PascalHambourg”]Nykoos, je ne comprends pas la pertinence de tes règles iptables. Peux-tu les expliquer ?
La première redirige les paquets envoyés à l’adresse externe du firewall vers le poste client. Mais le NAT fait déjà automatiquement ça avec les paquets de réponse, pas besoin de règle supplémentaire. Les deux ne modifient pas les ports source ni destination, donc je ne vois pas comment cela va aider à passer le filtrage du FAI.[/quote]

quelques notions seulement mais je ne possède pas tes compétences professionnelles pour décortiquer et expliquer le fonctionnement technique interne

je vois comme ceci:

on change l’adresse de destination

on change l’adresse source et lorsque le paquet “revient”, on le renvois au client.

oui c’est vrai cela ne filtre pas, il faudrait pour cela changer le port d’écoute 445 et que le client spécifie adresse:port
j’avais déjà fais ça, et je sais que la première ligne n’était pas suffisante d’oû la deuxième avec MASQUERADE.
bon, l’explication est plus pragmatique que technique, j’en conviens .

edit: je n’avais pas vu que fran.b avait donné la solution avec filtrage sur la page précédente