Auteur Sujet: LEDE (fork d'OpenWrt): Pare-feu défaillant ? (Lu 2235 fois)

renaud07 · « **le:** 01 septembre 2019 à 17:11:53 »

Bonjour,

Après le downgrade de mon routeur je me suis occupé du second sur mon autre site (qui est identique). Et j'ai l'impression que quelque chose ne va pas. Je les ai repassé à LEDE 17.04.1, car la session PPPoE sautait sans se reconnecter avec la 18.06 cf ce post

Je venais de fignoler la configuration et il me manquait une règle de FW pour rétablir mon tunnel wireguard pour le SIP. Hors, j'ai remarqué, que dès que j'ai remonté mon tunnel IPv6 tout refonctionnait sans intervention de ma part, alors que l'interface est bien dans la zone WAN et non à nu. Donc en théorie WG ne devrait pas pouvoir se reconnecter sans fowarder le port. (Je précise qu'on est du côté serveur).

Voici les règles en place (EDIT : mise à jour avec le paramétrage après reset) (j'ai omis la partie v4 car j'ai pas mal de ports natés, mais celle-ci semble fonctionner correctement) :

Code: [Sélectionner]

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option network 'wan wan6 HENET'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include
	option path '/etc/firewall.user'

À priori là je n'ai que les règles par défaut. Et il ne me semble pas que ça faisait ça avant (ou alors je ne m'en suis pas rendu compte).

EDIT : j'ai reset le parefeu en recopiant le fichier original, puis reboot : ça passe toujours !

vivien · « **Réponse #1 le:** 01 septembre 2019 à 18:16:28 »

Je me suis permis de rajouter "LEDE (fork d'OpenWrt)" a ton titre car sinon beaucoup vont être perdus.

renaud07 · « **Réponse #2 le:** 01 septembre 2019 à 19:50:38 »

Merci, tu as bien fait.

renaud07 · « **Réponse #3 le:** 02 septembre 2019 à 01:43:44 »

Après avoir fait un test avec socat, il ressort que quelque soit le port UDP utilisé, j'obtiens une réponse. Par contre le TCP est bien bloqué.

Code: [Sélectionner]

root@raspberrypi:~# socat -6 -v - UDP:[2001:470:xxx:xxx::x]:51821

> 2019/09/02 00:38:18.018778  length=1 from=0 to=0

^Croot@raspberrypi:~# socat -6 -v - UDP:[2001:470:xxx:xxx::xxx]:51820

> 2019/09/02 00:38:39.650875  length=1 from=0 to=0

^Croot@raspberrypi:~# socat -6 -v - UDP:[2001:470:xxx:xxx::xxx]:5178

> 2019/09/02 00:39:18.546463  length=1 from=0 to=0

^Croot@raspberrypi:~# socat -6 -v - TCP:[2001:470:xxx:xxx::xxx]:5178
2019/09/02 00:39:25 socat[15240] E connect(5, AF=10 [2001:0470:xxx:xxx::xxx]:5178, 28): Connection refused
root@raspberrypi:~# socat -6 -v - UDP:[2001:470:xxx:xxx::xxx]:22

> 2019/09/02 00:39:45.882364  length=1 from=0 to=0

^Croot@raspberrypi:~# socat -6 -v - TCP:[2001:470:xxx:xxx::xxx]:22
2019/09/02 00:41:28 socat[15244] E connect(5, AF=10 [2001:0470:xxx:xxx::xxx]:22, 28): Connection refused

Toute la partie UDP est à poil, donc ? Pas très rassurant...

EDIT : Et c'est pareil sur mon routeur... (je sais donc maintenant que ce n'est pas la peine de faire un reset complet, car j'avais tout reconfiguré à la main pour le mien alors que j'ai réinjecté la config côté serveur)

renaud07 · « **Réponse #4 le:** 02 septembre 2019 à 04:02:53 »

Je n'ai pas compris ce qu'il s'est passé :

J'ai voulu mettre un port d'écoute statique sur WG côté client pour pouvoir gérer le pare-feu sur la machine (si jamais on ne trouvait pas la cause). Après cette modif, j'ai relancé des 2 côtés et surprise, la connexion ne voulait plus du tout se faire alors que ça fonctionnait parfaitement 5 min plus tôt. J'ai donc remis comme à l'origine et ça ne se connectait toujours pas.

Intrigué, j'ai à tout hasard mis la règle de forward pour le port (sachant que je pensais que ça ne servirait à rien vu que tout passait) et pouf, la connexion est revenue instantanèment.

Dois-je en conclure que socat diagnostique mal l'ouverture des ports ? Car si je lance un tcpdump sur le serveur, je ne vois aucun paquet passer. Du coup la réponse vient d'où ? C'est le routeur qui intercepte et revoie à la place du serveur ? Car pour les ping, je les vois bien par exemple.

renaud07 · « **Réponse #5 le:** 02 septembre 2019 à 04:19:42 »

Pour en revenir à l'histoire de non re-connexion, je viens d'avoir une théorie : je n'avais pas arrêté WG pendant la MAJ du routeur, se peut-il que le serveur ai malgré la coupure continué de renvoyer des paquets (en réponse au keepalive) qui a donc ouvert la "voie retour" une fois internet revenu, comme si j'avais explicitent forwardé le port ? Et que le fait d’arrêter le service côté client a fait cesser l'envoie de keepalive et donc refermé la connexion ?

Ça expliquerait pourquoi ça a fonctionné pendant plusieurs heures sans règles particulières. À priori, le pare-feu n'a donc rien, ouf.