Port Forwarding ne fonctionne pas

[agautier]

Bonjour,
Ça devrait être facile, juste du Port Forwarding, mais ça ne fonctionne pas.
Interface rouge sur l'Internet, la verte en interne, je ping sans problème sur les deux interfaces.
Je configure mon port forwarding et vérifie la table sur IPcop

Code: Tout sélectionner

root@iflvpn1:~ # iptables -L PORTFWACCESS
Chain PORTFWACCESS (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             192.168.0.136       tcp dpt:http


C'est bon.
http://58.xxx.xxx.xxx:80 (je force le port 80, je suis un peu parano), résultat: connection timeout

Je vérifie les ports ouverts sur le serveur. Normalement 80 doit être ouvert, sinon impossible d’établir la moindre session http. Je vérifie sur Ipcop

Code: Tout sélectionner

root@iflvpn1:~ # netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:81              0.0.0.0:*               LISTEN      378/httpd
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1940/dnsmasq
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      378/httpd
tcp        0      0 0.0.0.0:222             0.0.0.0:*               LISTEN      549/sshd
tcp        0    300 192.168.0.35:222        192.168.0.131:47141     ESTABLISHED 6706/0
udp        0      0 0.0.0.0:53              0.0.0.0:*                           1940/dnsmasq

Pas de port 80 a l'horizon. Un petit tcpdump pour confirmer. J'utilise telnet sur le port 113 (toujours ouvert sur IPcop) et sur le port 80 pour comparer

Code: Tout sélectionner

$>tcpdump -i eth1 host 58.xxx.xxx.xx7
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
--->Telnet port 113
02:31:23.693068 IP 58.xxx.xxx.xx0.47787 > 58.xxx.xxx.xx7.ident: S 3152535418:3152535418(0) win 8192 <mss 1460,nop,nop,sackOK>
02:31:23.693139 arp who-has 58.xxx.xxx.xx0 tell 58.xxx.xxx.xx7
02:31:23.694401 arp reply 58.xxx.xxx.xx0 is-at 00:25:9c:48:a2:dd (oui Unknown)
02:31:23.694408 IP 58.xxx.xxx.xx7.ident > 58.xxx.xxx.xx0.47787: R 0:0(0) ack 3152535419 win 0
02:31:24.192906 IP 58.xxx.xxx.xx0.47787 > 58.xxx.xxx.xx7.ident: S 3152535418:3152535418(0) win 8192 <mss 1460,nop,nop,sackOK>
02:31:24.192944 IP 58.xxx.xxx.xx7.ident > 58.xxx.xxx.xx0.47787: R 0:0(0) ack 1 win 0
02:31:24.697814 IP 58.xxx.xxx.xx0.47787 > 58.xxx.xxx.xx7.ident: S 3152535418:3152535418(0) win 8192 <mss 1460,nop,nop,sackOK>
02:31:24.697865 IP 58.xxx.xxx.xx7.ident > 58.xxx.xxx.xx0.47787: R 0:0(0) ack 1 win 0
---> Telnet Port 80
02:31:43.745161 IP 58.xxx.xxx.xx0.47788 > 58.xxx.xxx.xx7.http: S 2262929086:2262929086(0) win 8192 <mss 1460,nop,nop,sackOK>
02:31:46.750930 IP 58.xxx.xxx.xx0.47788 > 58.xxx.xxx.xx7.http: S 2262929086:2262929086(0) win 8192 <mss 1460,nop,nop,sackOK>
02:31:52.751xx7 IP 58.xxx.xxx.xx0.47788 > 58.xxx.xxx.xx7.http: S 2262929086:2262929086(0) win 8192 <mss 1460,nop,nop,sackOK>


Silence sur le port 80... Je fais quoi maintenant? Pourquoi IPcop n'ouvre pas le port? J'ai du louper quelque chose de débile, c'est normalement si simple
Merci

[jdh]

Que de confusions !

Ipcop n'ouvre pas le port 80 lui-même : s'il reçoit un paquet sur 80/tcp, il le transfère à la machine cible.
Donc netstat sur Ipcop ne peut évidemment rien donner.

Je ne vois pas ce que vient faire là le port 113 (ident). Il m'étonne d'ailleurs que ce service (inutile) soit ouvert sur Ipcop.

Ensuite, un telnet sur le port 80 à partir de l'ipcop ne peut pas fonctionner, puisque le port 80 n'est pas ouvert ! Cela peut servir seulement à tester si le serveur fonctionne (avec l'ip du serveur interne).

Je ne connais pas l'usage de la chaine PORTFWACCESS (spécifique Ipcop que je connais mal) mais ce n'est surement pas la chaine à tester : un portforward se traduit par un PREROUTING (DNAT) plus une règle FORWARD (cf http://irp.nain-t.net/doku.php/130netfilter:040_nat = Christian CALECA : toujours la référence !).


Pour tester un port forward, il faut
- vérifier que le serveur cible offre bien le service : par exemple avec une machine dans le même réseau,
- vérifier qu'il y a une règle PREROUTING et une règle FORWARD,
- tester DEPUIS l'extérieur et non sur Ipcop !
- utiliser tcpdump sur Ipcop lors des tests : sur l'interface Red avec le port 80 ou sur l'interface Orange avec l'adresse du serveur.

[agautier]

Merci pour la réponse
tcpdump sur le port 80 donne le même chose: Trois packets syn, mais pas de réponse du firewall.

Code: Tout sélectionner

root@iflvpn1: # tcpdump -i eth1 "tcp port 80"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
05:46:59.808725 IP 58.xxx.xxx.xx0.50175 > 58.xxx.xxx.xx7.http: S 1768577894:1768577894(0) win 8192 <mss 1460,nop,nop,sackOK>
05:47:02.807322 IP 58.xxx.xxx.xx0.50175 > 58.xxx.xxx.xx7.http: S 1768577894:1768577894(0) win 8192 <mss 1460,nop,nop,sackOK>
05:47:08.807572 IP 58.xxx.xxx.xx0.50175 > 58.xxx.xxx.xx7.http: S 1768577894:1768577894(0) win 8192 <mss 1460,nop,nop,sackOK>

3 packets captured
3 packets received by filter
0 packets dropped by kernel

Je n'ai utilisé Telnet que par comparaison entre le port 113 et le 80. Je voulais surtout savoir si les packets atteignaient l'interface externe et quel était la réponse du firewall.

Il n'a pas de règle PREROUTING et la règle FORWARD n'existe que pour DROP
Bien sur je peux manipuler IPTABLE manuellement. Mais dans ce cas a quoi sert le Port Forwarding de IPcop?

Code: Tout sélectionner

root@iflvpn1:/ # iptables -L FORWARD
Chain FORWARD (policy DROP)
target     prot opt source               destination
ipac~fi    all  --  anywhere             anywhere
ipac~fo    all  --  anywhere             anywhere
BADTCP     all  --  anywhere             anywhere
TCPMSS     tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
CUSTOMFORWARD  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
IPSECVIRTUAL  all  --  anywhere             anywhere
OPENSSLVIRTUAL  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            state NEW
DROP       all  --  127.0.0.0/8          anywhere            state NEW
DROP       all  --  anywhere             127.0.0.0/8         state NEW
ACCEPT     all  --  anywhere             anywhere            state NEW
WIRELESSFORWARD  all  --  anywhere             anywhere            state NEW
REDFORWARD  all  --  anywhere             anywhere
PORTFWACCESS  all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
LOG        all  --  anywhere             anywhere            limit: avg 10/min burst 5 LOG level warning prefix `OUTPUT '

[jdh]

Christian CALECA, dont je cite une page, fournit une mine d'information qui a, de plus, la qualité d'être facile à lire.

La règle de PREROUTING est dans la table "nat" donc , il faut faire "iptables -t nat" pour visualiser cette chaine.

Comme je ne connais pas Ipcop, j'ignore la dénomination et le rôle des chaines non standards (INPUT, FORWARD, OUTPUT).


Le tcpdump n'est là que pour visualiser ce qui se passe sur l'interface : je ne peux dire s'il est normal qu'il y ait des SYN sans ACK.

Le premier point est d'abord de vérifier si le serveur web est correctement configuré :
- fonctionne-t-il pour un micro dans le même réseau ?
- fonctionne-t-il pour des micros en Green, s'il est en Orange ?

Le deuxième point est de faire d'abord confiance à Ipcop qui existe depuis longtemps.
Cela implique de ne pas avoir bricolé quoi que ce soit dessus.
A ce titre, s'il y a une chose à faire après avoir installé un Ipcop, c'est d'installer BOT : ceci est une (quasi-)obligation que beaucoup ici recommande !

Le troisième point est de tester par écoute avec tcpdump.
Mais en situation réelle, c'est à dire avec un PC en Red et serveur web en Orange.



Vous avez des connaissances, il vous manque de faire des étapes progressives ... On ne peut pas comprendre si on mélange un peu toute la situation : step by step, comme disent les anglophones !


NB : Si on dit "étape 2", on doit dire "étape n° 1" sous peine de propositions indécentes !

[Franck78]

J'ai du louper quelque chose de débile, c'est normalement si simple
Merci

On ne peut être que d'accord avec cette affirmation. Le transfert de port fonctionne sous IPCop. C'est complètement illusoire de chercher un dysfonctionnement de ou sur IPCop.
Le tcp/SYN arrive sur RED et poursuit son chemin sur GREEN. Et la réponse SYN/ACK fait le chemin inverse.

[xandre75]

Je confirme avoir le meme problème sur une machine de test ET aussi sur ma machine en production.
Explication à propos de la machine en production (chipset SIS. cartes réseau : intégrée SIS et Realtek 8139 x2):

Au départ configuré GREEN + RED, Ipcop me redirige bien les ports sur mon serveur web et mon serveur tunneel SSH. Seulement des serveurs accessibles depuis le web dans le LAN c'est mal.
Donc je profite d'une non utilisation de l'accès web pour reconfigurer Ipcop en GREEN + RED + ORANGE. Cela active la 2e carte reseau Realtek.
J'installe le serveur web dans la dmz (1 switch bien séparé du reste), modification de l'IP.
Je modifie mes règles NAT en conséquence pour le serveur web.
Et là, la redirection ne fonctionne plus.
Si je reviens à la configuration précédente, la redirection fonctionne.

(Remarque : il n'y a pas de chaine preroute ni nat mais une chaine Portfwaccess dans iptables).

Je tendrais plutôt à penser que le problème n'est pas logiciel mais matériel. Ipcop ne serait pas copain avec certaines cartes réseau et / ou chipsets de carte mère (emplacement port PCI).

[mab]

salut,

le renvoi de port fonctionne très bien sous ipcop, à condition de l'utiliser par l'interface.

"FONCTIONNE TRES BIEN ! C'est certain."

[Franck78]

Je modifie mes règles NAT en conséquence pour le serveur web.

Pourquoi utiliser une terminologie inexistante dans le GUI de IPCop? Tu changes l'IP destination du transfert de ports, point barre

L'écueil habituel avec ORANGE est de choisir l'IP orange pour le service dns des machines installées dans la dmz.