redirection de port après modif rc.red

[rico17]

Après la modification du fichier rc.red suite à une passerelle en 1.1.1.1 en ppoe chez oleane, je n'arrive plus à faire fonctionner la redirection de port depuis l'extérieur.
En effet en interne la redirection de port fonctionne c'est à dire j'ouvre une session putty en ssh sur ip publique plus port 22 réponse du serveur et fenêtre de login.
La même chose de l''exterieur donne une network connection error.
je précise que si je desactive la redirection de port cela ne fonctionne plus en interne, et j'ai la même erreur.
Je pense donc que la redirection de port fonctionne depuis l'ipcop vers mon serveur, mais pas de l'exterieur.
Pour info un scan des ports depuis l'exterieur donne le port 80 ouvert et c'est tout alors que de l'interieur j'ai bien les ports 22, 53, et 445 ouverts.
Si vous avez une idée, une piste je suis preneur.
Merci d'avance.

[Gesp]

Quelle adresse as-tu donné à la place de 1.1.1.1?

Il faut que l'adresse de remplacement ne corresponde pas aux plages des réseaux green et blue.

[rico17]

J'ai donné 3.3.3.3 broadcast 3.3.3.255 mask 255.255.255.0
Que pensez-vous du scan des ports différents depuis l'extérieur, et de l'intérieur ?
Je vois également avec oleane pour savoir ce qui réellement changé dans leur méthode et protocoles.

[rico17]

Je précise que mon vpn quant à lui fonctionne.
Personne n'a une idée ?
j'ai refait une machine entièrement et toujours le même problème, comment faire pour essayer d'identifier le problème?
Oléane ne m'a pour l'instant pas donné de réponse, hormis qu'il n'y a pas de firewall mutualisé ou autre...
help!!!

[rico17]

oleane ne reviendra pas en arrière concernant la passerelle, donc plus de redirection de ports ou plus d'ipcop, ou changer de fournisseur d'accès.
Est ce que quelqu'un qui à le même problème de passerelle en 1.1.1.1 arrive à rediriger les ports ?

[Franck78]

dans ce genre de problème, le symptôme apparent n'a que rarement à voir avec la cause réelle. Il n'y a pas de lien entre transfert de port et adresse IP.
Tu as un sans doute un problème de routage. Aisément traquable avec tcpdump. Ou peut être simplement en publiant les bonnes infos: table de routage, adresses IP,.....

[rico17]

Désolé pour mon absence, j'avais pris l'habitude que l'on ne me réponde plus, je n'y croyais plus vraiment.

Voila pour la config réseau, on voit la modif rc.red, j'ai changé à nouveau pour 2.2.2.2

eth0 Link encap:Ethernet HWaddr 00:0A:5E:xx:xx:xx
inet addr:192.168.0.XXX Bcast:192.168.0.255 Mask:255.255.255.0
eth1 Link encap:Ethernet HWaddr 00:0C:F1:xx:xx:xx
inet addr:2.2.2.2 Bcast:2.2.2.255 Mask:255.255.255.0
ppp0 Link encap:Point-to-Point Protocol
inet addr:62.160.XXX.XXX P-t-P:1.1.1.1 Mask:255.255.255.255

Voila ma table de routage, avec mes deux vpn fonctionnels, Sur mes autres ipcop j'ai strictement les mêmes entrées dans la table de routage, sauf qu'en général j'ai une ip routable au lieu de 1.1.1.1.

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
1.1.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
1.1.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 ipsec0
192.168.3.0 1.1.1.1 255.255.255.0 UG 0 0 0 ipsec0
192.168.1.0 1.1.1.1 255.255.255.0 UG 0 0 0 ipsec0
2.2.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 1.1.1.1 0.0.0.0 UG 0 0 0 ppp0

Sur une connexion ssh depuis l'extérieur tcpdump ne donne absolument rien sur l'ip publique, alors qu'en interne ma redirection de port fonctionne et tcp dump me donne bien les trames qui passent...
Je continue à penser qu'il y a un problème avec l'ip non routable 2.2.2.2

[Franck78]

Sur une connexion ssh depuis l'extérieur tcpdump ne donne absolument rien sur l'ip publique, alors qu'en interne ma redirection de port fonctionne et tcp dump me donne bien les trames qui passent...
Je continue à penser qu'il y a un problème avec l'ip non routable 2.2.2.2

Je veux pas avoir l'air méchant, mais ça veut dire quoi ce texte ?

C'est du précis qu'il faut. Tu affirmes que la redirection de port me marche. Ou marche depuis une machine locale à ton réseau.
Et pourtant on devine que tu te contentes de tester seulement le port 22 depuis l'extérieur.

Et ici on affirme à 100% que IPCop sait le faire.


tcpdump -i ppp0 port 22
et en même temps tu tentes l'accès vraiment depuis l'extérieur.

Et tu essayes avec un port ssh >1024 en second lieu
ssh mon_ip_publique_si_precieuse_que_je_la_masque -p2000


Et ne perds pas ton temps à masquer une mac ou une IP privée. C'est simplement inutilement bête.

[rico17]

Tout d'abord une petite mise au point:
Je ne crois pas que le masquage de l'ip nuise au diagnostic, et que la connaissance de celle ci soit impérative... mais j'ai pas trop envie de polémiquer, c'est assez compliqué comme cela.
j'ai une redirection du port 22 sur un serveur de mon réseau local
j'ai réalisée une écoute de mon ippublique avec tcpdump: tcpdump 62.160.194.xx -vvv, un accès depuis un autre réseau "extérieur" sur l'ippublique :22 ne laissait aucune trace avec ma commande.
j'ai réalisée une écoute de mon ippublique avec tcpdump: tcpdump 62.160.194.xx -vvv, un accès depuis mon réseau local sur lipublique:22 et là cela fonctionne, c'est à dire les trames passent, et j'ai la fenêtre de login de mon serveur linux. C'est pour cela que je dis que le transfert de port marche.
Je sais également qu'ipcop sait le faire puisque je l'utilise depuis 4 ans sur plusieurs sites, et que mes accès par transfert de ports ont toujours fonctionné.
Si je pose ces questions sur ce forum, c'est pour avoir un retour d'expérience de personnes ayant pu avoir un problème équivalent et peut être une solution, ou avoir un avis de personnes plus compétentes que moi.
C'est vrai que je n'ai testé que le port 22 depuis l'extérieur.

Ensuite quand tu me dis "essayes avec un port ssh >1024en second lieu" si je comprends bien defaultip:1024 ipdestination:22 pour éviter les ports "systèmes"
Par contre je ne comprends pas ssh mon_ip_publique -p2000

Résultat de la commande:
root@gw:~ # tcpdump -i ppp0 port 22 -vvv
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 68 bytes
08:12:50.138231 IP (tos 0x0, ttl 51, id 63263, offset 0, flags [DF], proto TCP (6), length 60) lns-bzn-51f-62-147-242-58.adsl.proxad.net.57442 > 62.160.194.xx.ssh: S 1084104345:1084104345(0) win 5840 <mss 1412,sackOK,timestamp 321926[|tcp]>
08:12:53.135249 IP (tos 0x0, ttl 51, id 63264, offset 0, flags [DF], proto TCP (6), length 60) lns-bzn-51f-62-147-242-58.adsl.proxad.net.57442 > 62.160.194.xx.ssh: S 1084104345:1084104345(0) win 5840 <mss 1412,sackOK,timestamp 322676[|tcp]>
08:12:59.134901 IP (tos 0x0, ttl 51, id 63265, offset 0, flags [DF], proto TCP (6), length 60) lns-bzn-51f-62-147-242-58.adsl.proxad.net.57442 > 62.160.194.xxssh: S 1084104345:1084104345(0) win 5840 <mss 1412,sackOK,timestamp 324176[|tcp]>
08:13:11.134389 IP (tos 0x0, ttl 51, id 63266, offset 0, flags [DF], proto TCP (6), length 60) lns-bzn-51f-62-147-242-58.adsl.proxad.net.57442 > 62.160.194.xx.ssh: S 1084104345:1084104345(0) win 5840 <mss 1412,sackOK,timestamp 327176[|tcp]>
08:13:18.067204 IP (tos 0x0, ttl 51, id 40714, offset 0, flags [DF], proto TCP (6), length 60) lns-bzn-51f-62-147-242-58.adsl.proxad.net.57448 > 62.160.194.xx.ssh: S 1510775750:1510775750(0) win 5840 <mss 1412,sackOK,timestamp 328908[|tcp]>
08:13:19.171125 IP (tos 0x0, ttl 51, id 21200, offset 0, flags [DF], proto TCP (6), length 60) lns-bzn-51f-62-147-242-58.adsl.proxad.net.57461 > 62.160.194.xx.ssh: S 1525176112:1525176112(0) win 5840 <mss 1412,sackOK,timestamp 329184[|tcp]>

[Franck78]

root@gw:~ # tcpdump -i ppp0 port 22 -vvv

je préfère -t -n comme options. Plus concis et facile à lire.

Donc le port 22 est bien acheminé sur ton IPCop et s'y perd. Dans les méandres de IPTables.
Par acquis de conscience tu aurais pu vérifier qu'il ne sortait pas sur orange ou vert......
et vérifier que le serveur ssh engendrait (ou non) une réponse....

Imaginons qu'il ne sorte pas, ce fameux SYN sur le port 22:
Tu peux donc demander la liste des règle pertinentes et voir si il y en a qui s'occupent de ce port.

iptables -t nat -n -L (d'abord les changements), pipe éventuellement un grep 22

puis les filres
iptables -L -n

[rico17]

root@gw:~ # iptables -t nat -n -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
CUSTOMPREROUTING all -- 0.0.0.0/0 0.0.0.0/0
SQUID all -- 0.0.0.0/0 0.0.0.0/0
PORTFW all -- 0.0.0.0/0 0.0.0.0/0

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
CUSTOMPOSTROUTING all -- 0.0.0.0/0 0.0.0.0/0
REDNAT all -- 0.0.0.0/0 0.0.0.0/0
SNAT all -- 0.0.0.0/0 0.0.0.0/0 MARK match 0x1 to:192.168.0.254

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain CUSTOMPOSTROUTING (1 references)
target prot opt source destination

Chain CUSTOMPREROUTING (1 references)
target prot opt source destination

Chain PORTFW (1 references)
target prot opt source destination
DNAT tcp -- 0.0.0.0/0 62.160.194.xx tcp dpt:22 to:192.168.0.1:22

Chain REDNAT (1 references)
target prot opt source destination
MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0

Chain SQUID (1 references)
target prot opt source destination
RETURN tcp -- 0.0.0.0/0 192.168.1.0/24 tcp dpt:80
RETURN tcp -- 0.0.0.0/0 192.168.3.0/24 tcp dpt:80
RETURN tcp -- 0.0.0.0/0 62.160.194.xx tcp dpt:80
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 800

root@gw:~ # iptables -L -n
Chain BADTCP (2 references)
target prot opt source destination
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x29
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x01
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x06
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x03/0x03
NEWNOTSYN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW

Chain CUSTOMFORWARD (1 references)
target prot opt source destination

Chain CUSTOMINPUT (1 references)
target prot opt source destination

Chain CUSTOMOUTPUT (1 references)
target prot opt source destination

Chain DHCPBLUEINPUT (1 references)
target prot opt source destination

Chain DMZHOLES (0 references)
target prot opt source destination

Chain GUIINPUT (1 references)
target prot opt source destination
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8

Chain INPUT (policy DROP)
target prot opt source destination
ipac~o all -- 0.0.0.0/0 0.0.0.0/0
BADTCP all -- 0.0.0.0/0 0.0.0.0/0
CUSTOMINPUT all -- 0.0.0.0/0 0.0.0.0/0
GUIINPUT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
IPSECVIRTUAL all -- 0.0.0.0/0 0.0.0.0/0
OPENSSLVIRTUAL all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
DROP all -- 127.0.0.0/8 0.0.0.0/0 state NEW
DROP all -- 0.0.0.0/0 127.0.0.0/8 state NEW
ACCEPT !icmp -- 0.0.0.0/0 0.0.0.0/0 state NEW
DHCPBLUEINPUT all -- 0.0.0.0/0 0.0.0.0/0
IPSECPHYSICAL all -- 0.0.0.0/0 0.0.0.0/0
OPENSSLPHYSICAL all -- 0.0.0.0/0 0.0.0.0/0
WIRELESSINPUT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
REDINPUT all -- 0.0.0.0/0 0.0.0.0/0
XTACCESS all -- 0.0.0.0/0 0.0.0.0/0 state NEW
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `INPUT '

Chain FORWARD (policy DROP)
target prot opt source destination
ipac~fi all -- 0.0.0.0/0 0.0.0.0/0
ipac~fo all -- 0.0.0.0/0 0.0.0.0/0
BADTCP all -- 0.0.0.0/0 0.0.0.0/0
TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
CUSTOMFORWARD all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
IPSECVIRTUAL all -- 0.0.0.0/0 0.0.0.0/0
OPENSSLVIRTUAL all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
DROP all -- 127.0.0.0/8 0.0.0.0/0 state NEW
DROP all -- 0.0.0.0/0 127.0.0.0/8 state NEW
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
WIRELESSFORWARD all -- 0.0.0.0/0 0.0.0.0/0 state NEW
REDFORWARD all -- 0.0.0.0/0 0.0.0.0/0
PORTFWACCESS all -- 0.0.0.0/0 0.0.0.0/0 state NEW
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `OUTPUT '

Chain IPSECPHYSICAL (1 references)
target prot opt source destination
ACCEPT 47 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:500 dpt:500
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:4500

Chain IPSECVIRTUAL (2 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain LOG_DROP (0 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain LOG_REJECT (0 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain NEWNOTSYN (1 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `NEW not SYN? '
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain OPENSSLPHYSICAL (1 references)
target prot opt source destination

Chain OPENSSLVIRTUAL (2 references)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ipac~i all -- 0.0.0.0/0 0.0.0.0/0
CUSTOMOUTPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain PORTFWACCESS (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 192.168.0.1 tcp dpt:22

Chain PSCAN (5 references)
target prot opt source destination
LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `TCP Scan? '
LOG udp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `UDP Scan? '
LOG icmp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `ICMP Scan? '
LOG all -f 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `FRAG Scan? '
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain REDFORWARD (1 references)
target prot opt source destination

Chain REDINPUT (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain WIRELESSFORWARD (1 references)
target prot opt source destination

Chain WIRELESSINPUT (1 references)
target prot opt source destination

Chain XTACCESS (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 62.160.194.xx tcp dpt:113

Chain ipac~fi (1 references)
target prot opt source destination
all -- 0.0.0.0/0 0.0.0.0/0
all -- 0.0.0.0/0 0.0.0.0/0

Chain ipac~fo (1 references)
target prot opt source destination
all -- 0.0.0.0/0 0.0.0.0/0
all -- 0.0.0.0/0 0.0.0.0/0

Chain ipac~i (1 references)
target prot opt source destination
all -- 0.0.0.0/0 0.0.0.0/0
all -- 0.0.0.0/0 0.0.0.0/0

Chain ipac~o (1 references)
target prot opt source destination
all -- 0.0.0.0/0 0.0.0.0/0
all -- 0.0.0.0/0 0.0.0.0/0

Je ne comprends pas tout, mais cela me semble correct, je n'ai pas d'orange sur cet IpCop.
Pour info, j'ai fait un test hier de rediriger le port 8080 vers un serveur web sur le 80, et cela a fonctionné, j'ai également essayé le 8888 vers le 22 du serveur linux et cela n'a pas marché. je refait un test avec les options -t -n des que je suis à "l'extérieur", et si utile je poste.
En tous cas, je te remercie de t'intéresser à mes problèmes.

[jdh]

Chain PORTFWACCESS (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 192.168.0.1 tcp dpt:22

En lisant cela, je me dit qu'il doit être possible d'accéder sur le port tcp/22 = ssh de l'intérieur (192.168.0.1).


(D'ailleurs, la source aurait de plus du être 192.168.0.0/24 mais ...)

[rico17]

Oui c'est possible depuis le réseau local, en direct sur 192.168.0.1:22 et même en passant par l'ippublique:22 . C'est depuis l'extérieur que cela pose un problème.

[jdh]

Comprendre "j'accède à l'ip publique depuis l'intérieur" demande un petit peu de réflexion !

- l'ipcop a 2 adresses (en Red+Green). Donc une en privée (Lan=Green) et une en publique (Wan=Red).
- si les règles issue de la chaîne INPUT ne sont pas conditionné D'ABORD par l'interface, on peut accéder de l'intérieur indifféremment à l'adresse interne ou publique.

Quand on regarde le filtrage créé par Shorewall, on observe que, dès la chaine INPUT, on ajoute directement l'interface pour aboutir à des chaines du genre "eth0_in" ou "eth2_fwd" qui ont le mérite d'être expressive.

Je pense qu'il s'agit d'une mauvaise habitude de tester de l'intérieur avec l'adresse ip publique.
Cela fonctionne quand il s'agit d'un service du firewall. Mais cela ne fonctionnera pas pour un transfert de ports vers un serveur en DMZ ! A abandonner !

[rico17]

Le serveur n'est pas en dmz, il est dans le réseau local.
Je ne dis pas que j'accède à l'ippublique depuis l'intérieur, je dis que si j'ouvre une session ssh port 22 sur l'ippublique depuis mon réseau local il me redirige vers mon serveur, si je désactive la redirection de ports, cela ne fonctionne pas.
C'est vrai que ce n'est pas un vrai test, mais je ne suis un expert et j'essaie de comprendre avec mes moyens.