Problème DNAT Shorewall

Support Debian
#1

Bonjour à tout le monde !

Je possède un serveur Debian comprenant un Shorewall en frontal et derrière celui-ci une autre machine linux sur laquelle je voudrai accéder en SSH.

Voici ma règle se trouvant dans le fichier “rules” :

DNAT ord loc:192.168.110.235 tcp 2222

L’adresse 192.168.110.235 correspondant à mon serveur linux sur lequel je veux accéder avec l’interface loc correspondant à mon réseaux local.

Dans le fichier “interface”, loc correspond bien à eth0 lui-même connecté à mon réseau local.

Le fichier “hosts” à bien ord d’enregistré qui correspond à mes adresses IP publique d’acceptées.

Sur mon serveur, le port 2222 à bien été configuré pour le ssh. En local, j’arrive bien à y accéder.

Ma règle me semble bonne, je ne comprends pas pourquoi je ne peux pas y accéder.

Dans le doute, j’ai essayé aussi d’autoriser toutes les connexions sur le port 2222 en plus de ma règle DNAT mais cela n’a pas fonctionné pour autant.

ACCEPT ord loc:192.168.110.235 tcp 2222

J’ai déjà une règle me permettant d’accéder mon serveur frontal celle-ci marche et je ne pense que ce soit elle qui crée le soucie.

ACCEPT ord $FW tcp 2221

Si quelqu’un a une idée pour mon petit soucis cela m’arrangerai bien ^^

Merci d’avance pour votre aide :slight_smile:

#2

Je ne connais pas la syntaxe de shorewall, mais je ne suis pas sûr que l’interface de sortie soit pertinente pour une règle DNAT traitant des paquets entrants. En tout cas elle ne l’est pas pour une règle iptables DNAT ; s’il faut spécifier une interface, c’est celle d’entrée.

Je pense qu’il faut le faire car la cible DNAT n’autorise rien par elle-même, elle ne fait que la translation d’adresse. Par contre l’adresse de destination originelle (ord ?) n’apparaît plus dans les paquets après l’application de la règle DNAT, donc je ne vois pas ce qu’elle vient faire dans la règle ACCEPT.

Tu peux afficher les règles iptables créées par shorewall avec iptables-save. Tu peux filtrer la sortie sur l’adresse du serveur avec grep dans un premier temps pour ne voir que les règles contenant cette adresse.

#3

J’ai repris les fichiers de conf déjà présents et actifs sur ce serveur, en prenant exemple j’ai fais ces règles.
Après des recherches sur les doc de Shorewall ça avait l’air d’être comme ça.
il y a de grandes chances que je me trompe vu que ça ne marche pas ^^

Oui c’est pas faux, j’ai donc remis la règle pour accepter le port 2222.
ACCEPT ord $FW tcp 2222

ord est la variable dans Shorewall contenant les adresses publiques que le serveur accepte.

Voici donc ce que me sort le iptables-save après un grep:
-A ord_dnat -p tcp -m tcp --dport 2222 -j DNAT --to-destination 192.168.110.235:2222 -A ord2loc -d 192.168.110.235/32 -p tcp -m tcp --dport 2222 -m conntrack --ctorigdstport 2222 -j ACCEPT
Merci :smiley:

#4

Que signifie $FW ?

Apparemment j’avais tort, shorewall a créé une règle ACCEPT lié à la règle DNAT (ce qu’on peut déduire de la présence de --ctorigdstport).

Maintenant il faut voir les règles qui appellent ces chaînes ord_dnat et ord2loc, donc grep sur ces noms.

Question bête : la machine cible a bien une route par défaut avec l’adresse de la machine shorewall comme passerelle, et pas de règle iptables qui bloque les connexions depuis l’extérieur ?

#5

D’après ce que je vois dans la doc la variable $FW fait référence au pare-feu lui même…
De ce que je vois, Shorewall fonctionne avec des zones :

#ZONE   TYPE
fw      firewall
net     ipv4
ord:net ipv4
loc     ipv4

Ces zones, elles sont après déclaré aussi dans un fichier interface :

#ZONE      INTERFACE     BROADCAST
net        eth2          detect
loc        eth0          detect

Et ord, lui dans un autre fichier avec les adresses publiques autorisées.

Ok, je ne connaissais pas ces options dans iptables -m conntrack --ctorigdstport 2222.
Je vais me renseigner un peu à ce sujet ^^

Dans un premier temps j’ai la déclaration :
:ord_dnat - [0:0]

Ensuite, d’autres règles déjà créées

-A dnat -s 192.168.33.0/24 -i eth2 -j ord_dnat

Plusieurs fois, celle-ci avec les adresses publiques
Et divers règles, qui fonctionne comme pour le 3389 qui me permet d’accéder au bureau à distance d’autre serveur.

-A ord_dnat -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.110.2:3389
-A ord_dnat -p tcp -m tcp --dport 3390 -j DNAT --to-destination 192.168.110.240:3389
-A ord_dnat -p tcp -m tcp --dport 3392 -j DNAT --to-destination 192.168.110.112:3389
-A ord_dnat -p tcp -m tcp --dport 3391 -j DNAT --to-destination 192.168.110.111:3389
-A ord_dnat -p tcp -m tcp --dport 3393 -j DNAT --to-destination 192.168.110.133:3389
-A ord_dnat -p tcp -m tcp --dport 2222 -j DNAT --to-destination 192.168.110.235:2222
-A ord_dnat -p tcp -m tcp --dport 23 -j DNAT --to-destination 192.168.110.1:23
-A ord_dnat -p tcp -m tcp --dport 449 -j DNAT --to-destination 192.168.110.1:449
-A ord_dnat -p tcp -m tcp --dport 8470:8480 -j DNAT --to-destination 192.168.110.1
-A ord_dnat -p tcp -m tcp --dport 24 -j DNAT --to-destination 192.168.110.131:23
-A ord_dnat -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.110.112
-A ord_dnat -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.110.112

Voici pour le ord2loc

    :ord2loc - [0:0]
-A ord2loc -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ord2loc -d 192.168.110.2/32 -p tcp -m tcp --dport 3389 -m conntrack --ctorigdstport 3389 -j ACCEPT
-A ord2loc -d 192.168.110.240/32 -p tcp -m tcp --dport 3389 -m conntrack --ctorigdstport 3390 -j ACCEPT
-A ord2loc -d 192.168.110.112/32 -p tcp -m tcp --dport 3389 -m conntrack --ctorigdstport 3392 -j ACCEPT
-A ord2loc -d 192.168.110.111/32 -p tcp -m tcp --dport 3389 -m conntrack --ctorigdstport 3391 -j ACCEPT
-A ord2loc -d 192.168.110.133/32 -p tcp -m tcp --dport 3389 -m conntrack --ctorigdstport 3393 -j ACCEPT
-A ord2loc -d 192.168.110.235/32 -p tcp -m tcp --dport 2222 -m conntrack --ctorigdstport 2222 -j ACCEPT
-A ord2loc -d 192.168.110.1/32 -p tcp -m tcp --dport 23 -m conntrack --ctorigdstport 23 -j ACCEPT
-A ord2loc -d 192.168.110.1/32 -p tcp -m tcp --dport 449 -m conntrack --ctorigdstport 449 -j ACCEPT
-A ord2loc -d 192.168.110.1/32 -p tcp -m tcp --dport 8470:8480 -j ACCEPT
-A ord2loc -d 192.168.110.131/32 -p tcp -m tcp --dport 23 -m conntrack --ctorigdstport 24 -j ACCEPT
-A ord2loc -d 192.168.110.112/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A ord2loc -d 192.168.110.112/32 -p tcp -m tcp --dport 443 -j ACCEPT
-A ord2loc -j ACCEPT
-A ord_frwd -o eth0 -j ord2loc

La machine cible a bien comme passerelle la machine Shorewall et aucune règle iptables.

#6

Quelles adresses publiques ? Avec -s ou -d ?
La règle ci-dessus ne contient acune adresse publique mais un préfixe d’adresses source (-s) privé. A quoi correspond ce préfixe ?

Quoi qu’il en soit, si les règles de DNAT pour le port 3389 fonctionnent, celles pour le port 2222 le devrait également. La machine cible peut-elle communiquer avec l’extérieur ? L’adresse IP cible est-elle correcte ? Que donne un tcptraceroute sur le port 2222 d’une adresse publique du pare-feu depuis l’extérieur ?

#7

Désolé, je n’étais pas clair j’avais plusieurs règles de ce type mais avec des adresses publiques

-A dnat -s X.X.X.X/24 -i eth2 -j ord_dnat

L’adresse privée citée est un autre sous réseau qui n’est pas forcement important dans l’exemple.
Les adresses publiques sont celles dont je dispose cher moi, celle de ord en l’occurrence avec des -s.
C’est depuis ces adresses que j’accède au Shorewall distant.

Oui, c’est bien ce que je me dis et c’est pour cela que je ne comprend pas ^^’

Oui, pas de soucis pour la communication depuis l’extérieur pour la machine cible. L’adresse IP est correcte.
Le tcptraceroute sur le port 2222 lui n’atteint pas l’adresse publique du pare feu elle s’arrête juste avant. Alors que sur le port 3389, on l’atteint bien :ok_hand:

#8

Ah d’accord, je croyais que c’étaient les adresses publiques de la machine shorewall.

Depuis ou vers l’extérieur ?

N’y aurait-t-il pas un autre équipement qui bloque avant ?

#9

Oula, c’est compliqué pour moi le lundi :confused:
Je voulais dire, pas de soucis pour joindre l’extérieur depuis la machine cible…

Sa me paraîtrais logique que non, pour moi il doit y avoir seulement la box pro avant.
Je vais me renseigner avec le site distant.

#10

Si le tcptraceroute sort à l’extérieur du site source distant, peut de chance que ça vienne de là.

La box locale fait du NAT ou pare-feu, ou est transparente au niveau IP et le pare-feu shorewall a une adresse IP publique ?

#11

C’est ce que je veux vérifier, j’aurai les logins / mdp que demain …
Logiquement, de ce que j’ai pu comprendre cela devrait être transparent.
Le pare-feu shorewall n’a pas d’adresse publique. Il a une autre interface connecté directement à la box.

#12

Si le pare-feu shorewall n’a pas d’adresse IP publique côté internet, alors la box fait forcément du NAT. Donc soit elle a l’adresse privée du pare-feu shorewall définie en “DMZ” (dénomination inappropriée mais usuelle) et toutes les connexions entrantes sont redirigées vers celle-ci, soit il y a des redirections vers l’adresse du pare-feu shorewall pour chaque port concerné, et dans ce cas il faudra en ajouter une pour le port 2222.

#13

Bon, ce matin j’ai enfin pu avoir accès à la box en question… et elle fait bien du NAT ! Il y a bien des redirections de chaque port concerné!
J’ai rajouté une redirection pour le port 2222 et maintenant ça roule !

Je suis un peu déçu que ce soit ça le problème vu la tronche de l’archi, j’était persuadé que le Shorewall était en frontal et que la box était transparente !

Désolé du dérangement pour si peu en tout cas merci pour ton aide ! c’est bien sympathique :smiley:

#14

Si la box était transparente, le pare-feu shorewall aurait une adresse IP publique en frontal côté internet.

192.168.33.0/24 est le sous-réseau de la box ? Il y a d’autres machines dedans ?

#15

Oui, j’avais pas fait attention, je ferai gaffe la prochaine fois.

Non, c’est un autre sous-réseau, dans le sous réseau de la box il n’y a que le Shorewall.

Maintenant, je vais pouvoir commencer à mettre en place un satellite sur ce site distant pour mon Centreon central ^^

#16

S’il n’y a que le pare-feu connecté à la box, il est envisageable de passer celle-ci en mode transparent si elle le supporte (comme les freebox) ou en mode DMZ pour tout rediriger vers le pare-feu, ce qui évite de créer des redirections pour chaque port entrant dans la box.