Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • Status Nouveau
  • Percent Complete
    0%
  • Task Type Anomalie
  • Category LAN → NAT (redirections, DMZ)
  • Assigned To No-one
  • Operating System Freebox Server Mini 4K
  • Severity High
  • Priority Very Low
  • Reported Version 4.2.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private

FS#32921 - Redirection de port non affecté à la bonne IP si deux carte réseaux sont connectés à la freebox

Bonjour,

Je suis nouvel abonné et possède une freebox mini 4k.

Sur son réseau, j’ai branché un serveur avec deux interfaces réseaux:

kopax@master-letort-01:[~]: ip -color a | grep 192

  inet 192.168.1.101/24 brd 192.168.1.255 scope global dynamic enp2s0
  inet 192.168.1.102/24 brd 192.168.1.255 scope global dynamic wlp1s0

Je précise que ces IPS sont fixé sur la freebox.

Coté freebox server, j’ai configuré ces deux redirections de ports:

10023 → 192.168.1.101
10024 → 192.168.1.102

J’ai eu un soucis de montage NFS depuis un NAS synology sur le réseau freebox avec l’erreur suivante :

2020-10-25T22:39:05+01:00 nas mountd[15563]: refused mount request from 192.168.1.102 for /volume4/DKA_MEDIA (/volume4/DKA_MEDIA): unmatched host

Effectivement, l’host en question doit pointé vers 192.168.1.101 , pour cette raison, je décide de couper l’interface wifi 192.168.1.102.

La connection sur le port SSH vers le port SSH 10024 fonctionne plus comme je l’attendais, mais je perd ensuite ma connection SSH sur le port 10023.

Heureusement via UN SSH sur le NAS, je peu récuperer l’accès a mon serveur en faisant un SSH local.

Il s’avère que la redirection de port 10023 pointais vers la mauvaise interface. Je viens de vérifier les réglages saisies dans l’interface freebox serveur, c’est bien un bug, la freebox me redirigeait vers la mauvaise interface pour le port 10023.

Je n’explique toujours pas pourquoi le NAS à reçu l’IP 192.168.1.102 lors du montage, comme l’indique la commande `ip -color a`, les addresses IP de l’interface vers laquel je monte aurait du être 192.168.1.101 et non 192.168.1.102, mais cela n’a rien à voir avec la redirection de port de la freebox serveur qui était mauvaise. Après redémarrage du serveur sans l’interface wifi 192.168.1.102, la connection SSH à été mapper correctement.

Mon fix: désactiver le WIFI en attendant que free corrige ce bug.

Cordialement,

PS: quand vous aurez validé le bug, je veux bien un geste commercial pour le temps passé.

Bien à vous,

DK

absolument rien compris à votre message qui n'est pas clair... (que vient faire votre histoire de montage NFS là dedans ?)

La question est surtout: comment avez vous mis en place votre redirection de port ? Via la console free (sur free.fr) ou via freeboxOS ?

Bonjour loggoi,

Merci pour votre effort de lecture et le temps passé à répondre.

La redirection de port à été faites via freebox OS, voici les captures:

!

Interface ethernet:

Interface wifi:

Avec une tel configuration, sauriez vous m'expliquer comment en coupant l'interface wifi, et bien la connexion SSH via le port 10023 tombe ? Comment la redirection sur le port 10023 peux elle attérir sur l'interface Wi-Fi ?

J'ai pu effectuer ma connection SSH à distance mais en utilisant un autre port SSH exposé par la freebox d'un autre serveur sur le même intranet, la connexion ethernet à toujours été up.

Concernant votre remarque sur le NFS, c'est le symptome qui m'a mené au problème. Le montage NFS necessite l'utilisation d'une interface spécifique à moins de le démonter, hors la redirection de port redirigais vers une interface spécifique qui n'était pas la bonne. Si ça ne vous intéresse pas de parler des conséquences, vous pouvez trouveer plus de détail ici : https://askubuntu.com/questions/632262/nfs-client-reconnect-after-interface-change

Cordialement,

DK

et comment affectez vous l'adresse IP à chaque interface du serveur ? En dur sur le serveur, ou via DHCP ? Et la configuration DHCP est correcte ?

Bonjour, j'affecte des IP static via le serveur DHCP de la freebox, voici la configuration

Pour compléter, voici le fichier `/etc/network/interfaces` du server (Debian Buster)

kopax@master-letort-01:[~]: cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp2s0
iface enp2s0 inet dhcp

ethernet-wol g
post-up /sbin/ethtool -s enp2s0 wol g
post-down /sbin/ethtool -s enp2s0 wol g
post-up /etc/rc.local

# The wifi network interface
# allow-hotplug wlp1s0
# iface wlp1s0 inet dhcp
# wpa-ssid KOPAX_LETORT
# wpa-psk something

Noter que si l'interface wifi est maintenant commenté, c'est à cause de ce problème.

Je viens de constater quelque chose de très étrange :

kopax@master-letort-01:[~]: ip -color a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
     valid_lft forever preferred_lft forever

2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

  link/ether 70:8b:cd:a4:96:ec brd ff:ff:ff:ff:ff:ff
  inet 192.168.1.101/24 brd 192.168.1.255 scope global dynamic enp2s0
     valid_lft 39840sec preferred_lft 39840sec
  inet6 2a01:e35:39fe:4e40:728b:cdff:fea4:96ec/64 scope global dynamic mngtmpaddr 
     valid_lft 86047sec preferred_lft 86047sec
  inet6 fe80::728b:cdff:fea4:96ec/64 scope link 
     valid_lft forever preferred_lft forever

3: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000

  link/ether 5e:db:ae:0d:c8:cc brd ff:ff:ff:ff:ff:ff

L'adresse MAC de l'interface Wifi ne correspond pas à celle saisi dans le serveur DHCP.

VRAI: 5e:db:ae:0d:c8:cc
FAUX: 50:3E:AA:DC:EA:73

Pourtant, cela n'explique pas le problème de redirection du port 10023 attérissant sur cette interface, d'autant plus que le serveur DHCP à bien résérvé l'IP et attribuer à l'interface wifi (voir le premier `ip a` tout en haut).

Il n'y a pas d'autres interface physique sur ce serveur que ces deux la.

@BigDong : J'ai déjà eu un bug similaire à plusieurs reprises, je viens de faire un ticket : https://dev.freebox.fr/bugs/task/32934.

J'avais oublié de le faire, merci de m'y avoir fait penser.


Lorsque l’on fait une redirection de ports vers une machine qui a une IPv4 automatique via le serveur DHCP de la Freebox, puis que l’on ajoute un bail IPv4 statique à cette même machine, puis que l’on fasse le reboot de la machine ou la désactivation puis réactivation de la carte réseau (pour prise en compte), la redirection de port ne fonctionne pas.

Il faut supprimer la redirection de ports que nous venons de créer puis la refaire pour qu’elle fonctionne.

Par contre, je n’ai pas refait le test avec un nouveau changement du bail IPv4 statique de la dite machine.

@Neustradamus, merci également pour ton commentaire, bien que je ne crois pas que ça soit le même problème.

Mon problème est un mauvais routage NAT puisque la redirection ne devrait en aucun cas pointer vers le mauvaise IP du même hostname, je suspecte que le script NAT utilise le hostname pour determiner l'IP alors qu'il ne devrait pas.

J'attends l'expertise de @loggoi,

PS : je ne suis pas de chez free, je ne suis que simple abonné.

@loggoi: Oui oui, nous attendons le retour de @mbizon et @Thibaut Freebox.
Ainsi que pour le bug: https://dev.freebox.fr/bugs/task/32934

@BigDong, @loggoi : Si vous avez quelques minutes pour faire l'essai du bug précédemment cité et de le confirmer, ça serait cool aussi :)

@loggoi: Avez-vous des nouvelles ?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing