Ponter le flux TV (VLAN100) entre 2 Freebox [Résolu]

Avoir un véritable pare-feu / routeur (totalement configurable, plus fonctionnalités non prises en charge pas la Freebox, tel que les vlan) entre le LAN et Internet, je suppose.

Je réflécjissait à ce genre de config depuis quelque temps, mais je ne pensait pas qu’il y avait de solution! J’étais mois aussi persuadé que la communication entre les boites de free était uniquement wifi (on ne lit jamais assez la doc!)
!Le seul problème chez moi, c’est que ce n’est pas une debian qui sert de routeur mais un routeur / modem (pas de freebox). Je vais me plonger dans la doc du routeur et potasser les vlan.
et si en plus je peux détourner le flux video vers un tuner virtuel de ma mythbox …
Quel dommage que pascal ne fasse pas de tuto, il y a la une belle matière à mettre sur le wiki!
Si personne ne le fais, je m’y collerai (pas pas de suite, pas le temps).

J’aurais bien du mal à écrire un tuto sur ce sujet de toute façon, n’ayant pas d’abonnement ADSL chez Free et encore moins de Freebox. Je peux juste donner des éléments techniques ponctuels, mais je pense que l’auteur d’un tuto doit pouvoir le valider globalement par lui-même.

Bonjour,

Je me permets de remonter ce sujet car j’essaye de faire la même chose presque, mais cela ne marche pas.

Ma config est la suivante :
Internet–>freebox ADSL–> notebook(passerelle debian)–> CPL–>CPL–> Freebox HD.
ou
Internet -->freebox ADSL–> eth1(82.XXX)-eth0(192.168.1.2)–> CPL–>CPL–> Freebox HD.
ipforward=1
La liaison du boitier freebox ADSL vers le notebook se fait en wifi. La question que je me pose est est-ce que le flux télé se transmet aussi par le port wifi de la freebox 5 (version 2) ?
J’ai activé le vlan 100 et ponté le bridge bien entendu.
Wireshark me montre que le boitier freebox HD fait des requettes DHCP IPV4 et quelques ICMP IPV6 sur eth0.100. Je vois ces requettes apparaître aussi sur eth1.100, donc on passe bien le bridge br0. Par contre la freebox ADSL ne renvoi pas de DHCPOFFER. (le DHCP est activé dans la freebox et shorewall est pour l’instant désactivé sur la passerelle).

Par ailleurs, les postes sur le réseau privé/24 accèdent à Internet, la passerelle debian fonctionne donc.(dessus, il y a shorewall, squid3/squidGuard et privoxy + socks5 en cas de besoin :wink: ).

Pouvez vous me donner un coup de main, svp ?

Merci,
Franck

Bonjour

J’ai réussi à rendre actif mon vlan entre les 2 freebox ( serveur et player car freebox v6 ) … Grace a ce post principalement donc merci beaucoup !!!

J’ai juste une petite question, avez vous une idée pour éviter le spam des logs ? ( je joint un exemple )

En gros j’ai des lignes de ce style par paquets de 5-6 assez régulièrement dans syslog.

Supprimer la règle iptables LOG qui les produit, tout simplement ?

Justement je n’avais pas l’impression d’avoir une rêgle iptables qui intervenait la dessus, sauf si j’ai franchement mal compris une des rêgles, vu que j’ai honteusement trouvé le “script firewall” sur le net.

Voici ma config “interfaces”

[code]# This file describes the network interfaces available on your system

and how to activate them. For more information, see interfaces(5).

The loopback network interface

auto lo
iface lo inet loopback

The primary network interface

auto eth0
iface eth0 inet dhcp

auto br0
iface br0 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
bridge-ports wlan0 eth2

#interface VLAN

auto eth0.100
iface eth0.100 inet manual

auto eth2.100
iface eth2.100 inet manual

Pont inter-freebox

auto br1
iface br1 inet manual
bridge_ports eth0.100 eth2.100
bridge_stp off
bridge_maxwait 0
post-up sysctl -w net.bridge.bridge-nf-call-iptables=0[/code]

Voici mon script de “firewall” …

[code]#!/bin/sh

INTIF="br0"
EXTIF=“eth0”

Enter the NETWORK address the Internal Interface is on

INTNET=“192.168.1.0/24”

Enter the IP address of the Internal Interface

INTIP=“192.168.1.1/24”

EXTIP="/sbin/ifconfig eth1 | grep 'inet ' | awk '{print $2}' | sed -e 's/.*://'"

Define our universe (all the internet)

UNIVERSE=“0.0.0.0/0”

-------- No more variable setting beyond this point --------

/sbin/depmod -a
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_conntrack_irc
/sbin/modprobe iptable_nat
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc

echo “1” > /proc/sys/net/ipv4/ip_forward
echo “1” > /proc/sys/net/ipv4/ip_dynaddr

iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -t nat -F

if [ “iptables -L | grep drop-and-log-it” ]; then
iptables -F drop-and-log-it
fi

iptables -X

iptables -Z

iptables -N drop-and-log-it
iptables -A drop-and-log-it -j LOG --log-level info
iptables -A drop-and-log-it -j REJECT

iptables -A INPUT -i lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT
iptables -A INPUT -i $INTIF -s $INTNET -d $UNIVERSE -j ACCEPT
iptables -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j drop-and-log-it
iptables -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -j ACCEPT
iptables -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $EXTIF -m state --state NEW,ESTABLISHED,RELATED -p tcp -s $UNIVERSE -d $EXTIP --dport 666 -j ACCEPT

iptables -A INPUT -s $UNIVERSE -d $UNIVERSE -j drop-and-log-it

iptables -A OUTPUT -o lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT
iptables -A OUTPUT -o $INTIF -s $EXTIP -d $INTNET -j ACCEPT
iptables -A OUTPUT -o $INTIF -s $INTIP -d $INTNET -j ACCEPT
iptables -A OUTPUT -o $EXTIF -s $UNIVERSE -d $INTNET -j drop-and-log-it
iptables -A OUTPUT -o $EXTIF -s $EXTIP -d $UNIVERSE -j ACCEPT
iptables -A OUTPUT -s $UNIVERSE -d $UNIVERSE -j drop-and-log-it
iptables -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
[/code]

Et ça, qu’est-ce que c’est ?

iptables -N drop-and-log-it iptables -A drop-and-log-it -j LOG --log-level info iptables -A drop-and-log-it -j REJECT
Accessoirement, cette chaîne devrait s’appeler log-and-reject plutôt que drop-and-log.

Je pensais que cette partie était juste l’équivalent d’une macro qui n’était appelé que par les autres rêgles.

Je regarderai a “virer” la partie log ce soir en rentrant.

Merci de la remarque

C’est une chaîne utilisateur. Rien à voir avec une macro, mais plutôt avec une fonction ou un sous-programme. On voit qu’elle est appelée (-j drop-and-log-it) par plusieurs règles du script.

Justement dans le script elle n’est appelée, il me semble, que sur br0 ( INTIF ) ou eth0 ( EXTIF )

Donc le “spam” sur br1 qui n’est pas touché “normalement” par ce script me laisse un peu interrogateur.

Je crois que je vais tout reprendre proprement à tête reposé ce soir, j’ai eu le malheur d’installer des paquets qui m’ont explosé la config wifi et le partage netatalk.

Je pense que je vais essayer de lire la doc d’iptables histoire de me faire un script de firewall plus adapté a mes besoins ( Netatalk, DLNA, samba, ssh, vpn, iPXE ), ce sera mieux que de prendre un truc tout fait sur le net qui au final semble un poil foireux.

Faudra que je vois pour extraire dnsmasq, hostapd et éventuellement iptables de syslog histoire que ce soit un poil plus clair.

edit: supprimé, hors-sujet

La chaîne est appelée dans la règle suivante qui se déclenche quelles que soient l’interface d’entrée, l’adresse source et l’adresse destination.

Bonjour,
Vieux post, mais toujours d’actualité !
Un peu newbie sur Ubuntu (mes connaissances Linux remontent à une RedHat 6 en mode “KGraphique”)

Ma topo est la suivante :

[FreeBox Server{Bridge}]<---->eth1°[Ubuntu Server]°eth0 {192.168.1.1}<---->[switch]<--->FreePlayer {192.168.1.50}
                                                                                   <--->PC1 {192.168.1.51}
                                                                                   <--->PC2 {192.168.1.52}
                                                                                   <--->PC3 {DHCP}
                                                                                   <--->PC4 {DHCP}

Le but du jeu étant à terme d’avoir sur ce serveur (virtualisé VM-WAre)

  • un serveur ICS : faisant office de de Firewall, DHCP, DNS, Contrôle parental (Squid), … bref la porte “controlée” Internet 8)
  • un NAS (Xpenology), histoire d’avoir un accès centralisé aux données @home
  • Plus tard d’autres VM selon les besoins…

j’ai fini par réussir à monter la VM ICS proprement, et çà commence à bien tourner :wink:

Par contre j’ai un problème du côté du FreePlayer qui ne veux plus recevoir le réseau :confused: (icône défaut réseau affiché)
En surfant un peu, j’ai fini par comprendre qu’il y avait un VLAN 100 la dessous, mais VLAN est une notion nouvelle pour moi :shifty:
Je n’ai pas la possibilité de tirer un câble réseau entre les deux Freebox, et je ne vois pas pourquoi les paquets ne pourraient pas passer par ce serveur Ubuntu.

Je suis donc tombé sur plusieurs forums dont celui-ci ou j’ai bêtement tenté la config suivante dans /etc/network/interfaces/, mais sans succès pour la liaison Server/Player :neutral_face: :

# WAN FreeBox Server Bridge
auto eth1
iface eth1 inet dhcp
# LAN 
auto eth0
iface eth0 inet static
   address 192.168.1.1
   netmask 255.255.255.0
   post-up iptable-restore < /etc/monscript

#Bridge Pour le VLAN Free
auto eth0.100 
iface eth0.100 inet manual
auto eth1.100 
iface eth1.100 inet manual
auto br0
iface br0 inet manual
bridge_ports eth0.100 eth1.100
bridge_stp off
bridge_maxwait 0
post-up sysctl -w net.bridge.bridge-nf-call-iptables = 0

Si une âme charitable pourvait donc m’aider à mettre en place cette configuration d’une manière simple, élégante et sans faille de sécurité je lui en serait très reconnaissant.

Merci d’avance pour votre aide !

Pascal qui perd de sa splendeur en utilisant un smiley :mrgreen: :mrgreen: :mrgreen:

Ne me dites pas qu’il suffit de supprimer ces quelques lignes pour que cela fonctionne :open_mouth:

auto eth0.100 
iface eth0.100 inet manual
auto eth1.100 
iface eth1.100 inet manual

Qu’il suffit simplement de laisser çà :

auto br0
iface br0 inet manual
bridge_ports eth0.100 eth1.100
bridge_stp off
bridge_maxwait 0
post-up sysctl -w net.bridge.bridge-nf-call-iptables = 0

Je fais l’essai dès ce soir…

Essai non concluant :confused:
On constate effectivement qu’il est inutile de configurer les vlan au préalable.
un brctl show le montre bien

bridge name   bridge id             STP Enabled   Interfaces
br0           8000.000abcdefxxx     no            eth0.100
                                                  eth1.100

en ifconfig, toutes les interfaces sont montées.

Le trafic internet passe bien depuis les PC, mais le FreePlayer reste toujours en erreur réseau (deux icones réseau qui clignotent en bas à droite de la mire) :imp:

Le “post-up sysctl -w net.bridge.bridge-nf-call-iptables = 0” est bien censé ne par faire passer le pont par iptables ?
Est-il nécessaire de créer une règle ebtables, ou le pont se charge par défaut de router le traffic.

Que dois-je vérifier pour être sur de ne pas être passé à côté d’un truc ?

Merci d’avance pour votre aide !

Deux remarques :

  1. Méfiance avec les VLAN et les machines virtuelles. En effet on est tributaire de la gestion des paquets taggés IEEE 802.1Q par la machine hôte et par le système de virtualisation. Il faudrait vérifier s’il y a du trafic taggé sur les différentes interfaces : physiques, virtuelles, ponts…
  2. Si le freeplayer est dans un VLAN séparé du reste du LAN, ne devrait-il pas avoir une adresse IP dans un réseau IP distinct ?

Merci PascalHambourg pour ces remarques très pertinentes :023

N’étant pas un as ubuntu, je ne sais pas trop comment vérifier qu’il y a du trafic vlan 100, mais quelques commandes simples (tirées du fond de ma mémoire) du genre tcpdump sur toutes les interfaces ne me montre rien du genre :question:
Je vais donc aller jeter un œil du côté de la configuration VMWare pour voir s’il n’y a pas quelque chose à faire pour faire passer ces paquets taggués directement entre les deux cartes réseau physiques ou pour que Esxi le fasse vis à des interfaces réseau de la VM “ICS”…
Si qqun à des astuces avant que je ne passe des heures à la google-isation :open_mouth:

Pour le 2), vis à vis de l’IP je ne sais pas ce qui est prévu côté protocole Free.
Je comptais donc sur une automatisation des opérations physiques réseaux entre machines :083
Je pensais que leur communication directe entre VLAN était suffisante, vu que n’importe quel périphérique “habituel” CPL, Wifi, Switch semblait faire le relais.

Mais c’est trop se reposer sur la simplicité à laquelle nous avons trop tendance à nous habituer de nos jours… Merci “Pomme” et “Fenêtres” :stuck_out_tongue:
Je vais donc me ressortir les doigts… pardonnez-moi l’expression :blush: après tant d’années de souris…
et essayer de trouver une solution à ce problème qui parait trivial mais qui ne l’est pas :013

[quote=“PascalHambourg”]Deux remarques :

  1. Méfiance avec les VLAN et les machines virtuelles. En effet on est tributaire de la gestion des paquets taggés IEEE 802.1Q par la machine hôte et par le système de virtualisation. Il faudrait vérifier s’il y a du trafic taggé sur les différentes interfaces : physiques, virtuelles, ponts…
    [/quote]
    Bingo !
    Aucun trafic sorti de Esxi (testé avec tcpdump) sur les VLAN 100.
    En me penchant un peu sur WMWare (newbie too), on voit que par défaut il ne se préoccupe pas des VLAN.
    Deux possibilités, soit ajouter des NIC spécifiques pour les les VLAN taggés, soit faire passer tous les VLAN à la VM (ID VLAN tous = 4095).

J’ai testé les deux avec soit eth2 et eth3 avec des NIC dédiées sur le VLAN100, ou bien avec eth0.100 et eth1.100 dans le cas ou je laisse passer tous les VLAN à la VM.
Et là magie avec tcpdump on voit du traffic sur br0, eth0.100, et eth1.100 :dance:

Je suis donc resté avec mon br0 entre eth0.100 et eth1.100, mais le FreePlayer ne veut toujours rien savoir :013

Avec tcpdump je vois des requêtes passer du genre :

ARP, Request who-has 192.168.27.1 tell 192.168.27.14 {mac-address}(oui unknwown) > Broadcast, ethertype Unknown (0x0802)
Il semble donc y avoir des IP d’un autre sous réseau que mon 192.168.1.X

Cà progresse donc :wink: , prochaine étape pour essayer de solutionner ce problème ?