Problems with bridge+router setup

Problems with bridge+router setup

[Kurt Haenen]

Dear all,

I'm trying to setup a Raspberry Pi2 as a special kind of bridge+router, 
but am getting stuck (basically way before the difficult stuff starts) 
with just basic bridging already.  I've tried figuring this out on my 
own and with searching through all stuff on the Internet, but still am 
no step closer to understanding the cause of my problems (even though I 
don't thing I'm an idiot), so this is basically a cry for help ...


So, the basics of my setup:

Client <----> RPI2 <----> LAN

The RPI2 has an extra eth1 via USB to which the Windows-7 client is 
connected, while the rest of the network is connected through eth0 of 
the RPI2.  The LAN contains a server that hands out DHCP addresses.

The RPI2 is running the latest Raspbian Jessie (Linux raspberrypi 
4.1.13-v7+ #826 SMP PREEMPT Fri Nov 13 20:19:03 GMT 2015 armv7l 
GNU/Linux).
I created the bridge through the /etc/network/interfaces config file:
     auto lo eth1 br0
     iface lo inet loopback
     iface eth0 inet manual
     iface eth1 inet manual
     iface br0 inet dhcp
         bridge_fd 0
         bridge_maxwait 0
         bridge_stp off
         bridge_ports eth0 eth1

The fd, maxwait and stp bridge settings were actually added after 
checking the Internet for the problems I was hitting.  I've also tried 
executing explicit brctl commands for the same, but that didn't change 
anything ...  No ebtables or iptables rules applied yet, since I first 
wanted to test basic bridging.

With this setup, when I attach my Windows-7 client to eth1 of the RPI 
and ensure the client has a static IP in the same range as the LAN, then 
everything seems to work fine.  I can ping hosts on the LAN from the 
client and vice-versa, BUT ...

If I tell the client to use DHCP, then it (most of the time) doesn't 
get an IP address.  I added a rule to just log events in the FORWARD 
chain of ebtables' filter table, which (filtered on ports 67 and 68) 
shows:

Dec 27 10:35:54 raspberrypi kernel: [73804.793870] LOG_FORWARD IN=eth1 
OUT=eth0 MAC source = 00:26:2d:c6:df:50 MAC dest = ff:ff:ff:ff:ff:ff 
proto = 0x0800 IP SRC=0.0.0.0 IP DST=255.255.255.255, IP tos=0x00, IP 
proto=17 SPT=68 DPT=67
Dec 27 10:35:54 raspberrypi kernel: [73804.794508] LOG_FORWARD IN=eth0 
OUT=eth1 MAC source = 00:e0:4c:e8:42:30 MAC dest = ff:ff:ff:ff:ff:ff 
proto = 0x0800 IP SRC=192.168.21.1 IP DST=255.255.255.255, IP tos=0x10, 
IP proto=17 SPT=67 DPT=68
Dec 27 10:35:54 raspberrypi kernel: [73804.799762] LOG_FORWARD IN=eth0 
OUT=eth1 MAC source = 00:e0:4c:e8:42:30 MAC dest = ff:ff:ff:ff:ff:ff 
proto = 0x0800 IP SRC=192.168.21.1 IP DST=255.255.255.255, IP tos=0x10, 
IP proto=17 SPT=67 DPT=68
Dec 27 10:35:54 raspberrypi kernel: [73804.801009] LOG_FORWARD IN=eth1 
OUT=eth0 MAC source = 00:26:2d:c6:df:50 MAC dest = ff:ff:ff:ff:ff:ff 
proto = 0x0800 IP SRC=0.0.0.0 IP DST=255.255.255.255, IP tos=0x00, IP 
proto=17 SPT=68 DPT=67
Dec 27 10:35:54 raspberrypi kernel: [73804.809660] LOG_FORWARD IN=eth0 
OUT=eth1 MAC source = 00:e0:4c:e8:42:30 MAC dest = ff:ff:ff:ff:ff:ff 
proto = 0x0800 IP SRC=192.168.21.1 IP DST=255.255.255.255, IP tos=0x10, 
IP proto=17 SPT=67 DPT=68
Dec 27 10:35:55 raspberrypi kernel: [73805.917988] LOG_FORWARD IN=eth1 
OUT=eth0 MAC source = 00:26:2d:c6:df:50 MAC dest = ff:ff:ff:ff:ff:ff 
proto = 0x0800 IP SRC=0.0.0.0 IP DST=255.255.255.255, IP tos=0x00, IP 
proto=17 SPT=68 DPT=67
Dec 27 10:35:55 raspberrypi kernel: [73805.924720] LOG_FORWARD IN=eth0 
OUT=eth1 MAC source = 00:e0:4c:e8:42:3
0 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP SRC=192.168.21.1 IP 
DST=255.255.255.255, IP tos=0x10, IP proto=17 SPT=67 DPT=68

So, I would conclude from this (correct me if I'm wrong) that the 
server (192.168.21.1) is receiving the request for a DHCP address and 
even responds back, but for some reason this response either never 
reaches the Windows 7 machine or it refuses to use it.

Now, yesterday, for an extensive period, the problem was gone: I could 
attach the client, get an IP, detach it, attach it again and get the 
same IP again.  Then this morning, with nothing changed, not even the 
power taken off from any of the involved devices (apart from the client 
which was put to sleep while detached from the network), it came back to 
not getting an IP at all ...

So, any clue, tips or whatever that could help me in figuring out the 
root cause here?

Much thanks in advance and happy hollidays to all!

K.

Re: Problems with bridge+router setup

[Neal P. Murphy]

On Sun, 27 Dec 2015 12:00:57 +0100
Kurt Haenen <Kurt.Haenen@quintux.com> wrote:

> Dear all,
> 
> I'm trying to setup a Raspberry Pi2 as a special kind of bridge+router, 
> but am getting stuck (basically way before the difficult stuff starts) 
> with just basic bridging already.  I've tried figuring this out on my 
> own and with searching through all stuff on the Internet, but still am 
> no step closer to understanding the cause of my problems (even though I 
> don't thing I'm an idiot), so this is basically a cry for help ...
> 
> 
> So, the basics of my setup:
> 
> Client <----> RPI2 <----> LAN
> 
> The RPI2 has an extra eth1 via USB to which the Windows-7 client is 
> connected, while the rest of the network is connected through eth0 of 
> the RPI2.  The LAN contains a server that hands out DHCP addresses.
> 
> The RPI2 is running the latest Raspbian Jessie (Linux raspberrypi 
> 4.1.13-v7+ #826 SMP PREEMPT Fri Nov 13 20:19:03 GMT 2015 armv7l 
> GNU/Linux).
> I created the bridge through the /etc/network/interfaces config file:
>      auto lo eth1 br0
>      iface lo inet loopback
>      iface eth0 inet manual
>      iface eth1 inet manual
>      iface br0 inet dhcp
>          bridge_fd 0
>          bridge_maxwait 0
>          bridge_stp off
>          bridge_ports eth0 eth1

I think you need STP (Spanning Tree Protocol); it's how devices on a LAN find out where bridges (switches) are and what's on the other side of them.

Also, remove eth1 from the 'auto' statement. Only br0 should be handled automatically.

You've largely done what I do for my home-brew KVM controller, except that I also add "post-up brctl setfd br0 0". It's been years since I set it up and I don't remember why I added it. (It may've been needed for an older version of Debian that didn't do bridges right: DHCP would often fail because it would come up long before the bridge would time out and start processing traffic.)

To debug, you might add a script that periodically pings something on the LAN. When the pings start to fail, bounce the link. It's rare, but not unheard of, for NICs to go to sleep.

> 
> The fd, maxwait and stp bridge settings were actually added after 
> checking the Internet for the problems I was hitting.  I've also tried 
> executing explicit brctl commands for the same, but that didn't change 
> anything ...  No ebtables or iptables rules applied yet, since I first 
> wanted to test basic bridging.
> 
> With this setup, when I attach my Windows-7 client to eth1 of the RPI 
> and ensure the client has a static IP in the same range as the LAN, then 
> everything seems to work fine.  I can ping hosts on the LAN from the 
> client and vice-versa, BUT ...
> 
> If I tell the client to use DHCP, then it (most of the time) doesn't 
> get an IP address.  I added a rule to just log events in the FORWARD 
> chain of ebtables' filter table, which (filtered on ports 67 and 68) 
> shows:
> 
> Dec 27 10:35:54 raspberrypi kernel: [73804.793870] LOG_FORWARD IN=eth1 
> OUT=eth0 MAC source = 00:26:2d:c6:df:50 MAC dest = ff:ff:ff:ff:ff:ff 
> proto = 0x0800 IP SRC=0.0.0.0 IP DST=255.255.255.255, IP tos=0x00, IP 
> proto=17 SPT=68 DPT=67
> Dec 27 10:35:54 raspberrypi kernel: [73804.794508] LOG_FORWARD IN=eth0 
> OUT=eth1 MAC source = 00:e0:4c:e8:42:30 MAC dest = ff:ff:ff:ff:ff:ff 
> proto = 0x0800 IP SRC=192.168.21.1 IP DST=255.255.255.255, IP tos=0x10, 
> IP proto=17 SPT=67 DPT=68
> Dec 27 10:35:54 raspberrypi kernel: [73804.799762] LOG_FORWARD IN=eth0 
> OUT=eth1 MAC source = 00:e0:4c:e8:42:30 MAC dest = ff:ff:ff:ff:ff:ff 
> proto = 0x0800 IP SRC=192.168.21.1 IP DST=255.255.255.255, IP tos=0x10, 
> IP proto=17 SPT=67 DPT=68
> Dec 27 10:35:54 raspberrypi kernel: [73804.801009] LOG_FORWARD IN=eth1 
> OUT=eth0 MAC source = 00:26:2d:c6:df:50 MAC dest = ff:ff:ff:ff:ff:ff 
> proto = 0x0800 IP SRC=0.0.0.0 IP DST=255.255.255.255, IP tos=0x00, IP 
> proto=17 SPT=68 DPT=67
> Dec 27 10:35:54 raspberrypi kernel: [73804.809660] LOG_FORWARD IN=eth0 
> OUT=eth1 MAC source = 00:e0:4c:e8:42:30 MAC dest = ff:ff:ff:ff:ff:ff 
> proto = 0x0800 IP SRC=192.168.21.1 IP DST=255.255.255.255, IP tos=0x10, 
> IP proto=17 SPT=67 DPT=68
> Dec 27 10:35:55 raspberrypi kernel: [73805.917988] LOG_FORWARD IN=eth1 
> OUT=eth0 MAC source = 00:26:2d:c6:df:50 MAC dest = ff:ff:ff:ff:ff:ff 
> proto = 0x0800 IP SRC=0.0.0.0 IP DST=255.255.255.255, IP tos=0x00, IP 
> proto=17 SPT=68 DPT=67
> Dec 27 10:35:55 raspberrypi kernel: [73805.924720] LOG_FORWARD IN=eth0 
> OUT=eth1 MAC source = 00:e0:4c:e8:42:3
> 0 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP SRC=192.168.21.1 IP 
> DST=255.255.255.255, IP tos=0x10, IP proto=17 SPT=67 DPT=68
> 
> So, I would conclude from this (correct me if I'm wrong) that the 
> server (192.168.21.1) is receiving the request for a DHCP address and 
> even responds back, but for some reason this response either never 
> reaches the Windows 7 machine or it refuses to use it.
> 
> Now, yesterday, for an extensive period, the problem was gone: I could 
> attach the client, get an IP, detach it, attach it again and get the 
> same IP again.  Then this morning, with nothing changed, not even the 
> power taken off from any of the involved devices (apart from the client 
> which was put to sleep while detached from the network), it came back to 
> not getting an IP at all ...
> 
> So, any clue, tips or whatever that could help me in figuring out the 
> root cause here?
> 
> Much thanks in advance and happy hollidays to all!
> 
> K.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problems with bridge+router setup

[Misterke]

Thanks Neal!

I removed eth1 from the auto line and changed stp to on instead of off. 
However, in parallel to that I also noticed a stupid DHCP config 
mistake: both the WIFI and the wired MAC of my client notebook were 
getting the same (hard configured) IP address assigned.  Normally this 
notebook operates via WIFI, but for the test here I would hook it wired 
to the RPi2 ... I guess then getting the same IP for the wired as the 
WIFI already had can totally screw up things.

Anyway, with all this modified, basic bridging seems to work fine, so 
time to move on to the more complex things I need, but also have 
numerous questions on how to get them done ...

Reduced to the minimal, the needed setup would look something like 
this:

         +------+
   A ----|      |   single IP link   +------+       +-----------+
         |Switch|--------------------| RPi2 |-------|Cable modem|
   B ----|      |                eth1+------+eth0   +-----------+
         +------+

Here client A is a normal network device for which the network it is 
connected to should look like a normal LAN and the RPi2 should act as 
firewall, DHCP & DNS server, etc.  In short: for client A the RPi2 
should look like a typical router/firewall.

Client B however is a Digital TV box and my triple-play provider 
unfortunately requires those to be directly connected to the cable 
modem, which will hand them actually a DHCP address in a particular 
range and probably do other special stuff.  In short: for client B the 
entire network between itself and the cable modem should consist solely 
of hubs/switches/bridges and hence for it to work the RPi2 should behave 
as a simple bridge.

In reality there will be more clients of both A and B type and there 
will be additional switches between the RPi2 and the clients, but in 
most locations I only have a single lead arriving (can't be changed 
without major costs) whereas I need to attach both clients of type A and 
B.

So, what I would like the RPi2 to do is:
  - For ethernet frames TO or FROM specific MAC adresses (those of 
clients of type B) on its eth1 side, just pass them on from/to eth0
  - For anything else, behave like a router and have iptables rules 
dictate what is allowed and when outputting to the eth0-side do 
NAT/masquerading

I was thinking this would mean (but have to try this still):
  - with ebtables (where xx indicates the mac of client B):
      * -t broute -A BROUTING -i eth0 -d 
xx:xx:xx:xx:xx:xx/01:00:00:00:00:00 -j ACCEPT
      * -t broute -A BROUTING -i eth1 -s 
xx:xx:xx:xx:xx:xx/01:00:00:00:00:00 -j ACCEPT
      * -t broute -P BROUTING DROP
  - with iptables:
      * -t nat -A POSTROUTING -m physdev --physdev-out eth0 -j 
MASQUERADE
      * -P INPUT DROP
      * -P FORWARD DROP
      * -A FORWARD -m physdev --physdev-in eth1 -j ACCEPT
      * -A FORWARD -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
      * -A FORWARD -m state --state ESTABLISHED -j ACCEPT
      * -A FORWARD -m state --state RELATED -j ACCEPT
      * -A INPUT -m physdev --physdev-in eth1 -j ACCEPT
      * -A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
      * -A INPUT -m state --state ESTABLISHED -j ACCEPT
      * -A INPUT -m state --state RELATED -j ACCEPT
      * -A INPUT -p udp -m udp --dport 1024:65535 --sport 53 -j ACCEPT
      * -A INPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT
      * -A INPUT -p icmp -m icmp --icmp-type destination-unreachable -j 
ACCEPT
      * -A INPUT -p icmp -m icmp --icmp-type source-quench -j ACCEPT
      * -A INPUT -p icmp -m icmp --icmp-type time-exceeded -j ACCEPT
      * -A INPUT -p icmp -m icmp --icmp-type parameter-problem -j ACCEPT
      * -A INPUT -p tcp -m tcp --dport auth -j ACCEPT
      * -A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 22,443

So, first question of course would be whether this seems sensible and 
whether any of you can give some
input on mistakes or possible improvements.

But I also have additional questions:
   - To act as a router, I need IP addresses at both sides of the 
bridge.  At the eth0 side, that should
     be a DHCP address coming from the cable modem, but at the other end 
it should be a static address.
     Now, in the previous simple bridge setup, I already had the bridge 
get a DHCP address and I could
     even add a second static address to br0, but then those addresses 
would exist at both ends of the
     bridge, right?  So, should I then create ebtables/iptables rules 
somehow to avoid that someone
     would notice the internal IP address on the internet and vice 
versa?
   - Next to that, when running dnsmasq to hand out DHCP addresses, I of 
course don't want it to start
     offering addresses to the Internet side of the bridge.  So, either 
I somehow need to tell dnsmasq
     to only work on the LAN side (eth1) or perhaps I would again have 
to somehow limit this with
     ebtables/iptables.

Any advice from anyone on all this?

Again thanks to anyone who can offer tips, hints, ideas ...

Kind regards,
K

Re: Problems with bridge+router setup

[Pascal Hambourg]

Misterke a écrit :
> 
> Client B however is a Digital TV box and my triple-play provider 
> unfortunately requires those to be directly connected to the cable 
> modem, which will hand them actually a DHCP address in a particular 
> range and probably do other special stuff.

Does it use VLAN tagging (IEEE 802.1q) or plain ethernet ?

> So, what I would like the RPi2 to do is:
>   - For ethernet frames TO or FROM specific MAC adresses (those of 
> clients of type B) on its eth1 side, just pass them on from/to eth0
>   - For anything else, behave like a router and have iptables rules 
> dictate what is allowed and when outputting to the eth0-side do 
> NAT/masquerading

What about broadcast packets such as ARP requests or DHCP replies sent
by the cable modem ? How do you decide if they should be bridged ?

>       * -A INPUT -p icmp -m icmp --icmp-type source-quench -j ACCEPT

ICMP source quench is deprecated and considered harmful.

> But I also have additional questions:
>    - To act as a router, I need IP addresses at both sides of the 
> bridge.  At the eth0 side, that should
>      be a DHCP address coming from the cable modem, but at the other end 
> it should be a static address.
>      Now, in the previous simple bridge setup, I already had the bridge 
> get a DHCP address and I could
>      even add a second static address to br0, but then those addresses 
> would exist at both ends of the
>      bridge, right?  So, should I then create ebtables/iptables rules 
> somehow to avoid that someone
>      would notice the internal IP address on the internet and vice 
> versa?
>    - Next to that, when running dnsmasq to hand out DHCP addresses, I of 
> course don't want it to start
>      offering addresses to the Internet side of the bridge.  So, either 
> I somehow need to tell dnsmasq
>      to only work on the LAN side (eth1) or perhaps I would again have 
> to somehow limit this with
>      ebtables/iptables.
> 
> Any advice from anyone on all this?

My advice is to not use br0 but only eth0 and eth1 for IP setup, DHCP,
routing and so on.

Re: Problems with bridge+router setup

[Misterke]

Thanks for the feedback Pascal,

On 2015-12-28 11:44, Pascal Hambourg wrote:
> Does it use VLAN tagging (IEEE 802.1q) or plain ethernet ?

I don't think I can use VLAN tagging.  I would prefer not to install 
anything
special near the clients, just a plain and simple switch (well, 
actually in
some cases an old WIFI-router used simply as switch+AP with the routing 
part
disabled).

> What about broadcast packets such as ARP requests or DHCP replies 
> sent
> by the cable modem ? How do you decide if they should be bridged ?

Good question.  This is the sort of stuff I'm struggling with and 
basically
looking for people that can indicate how to sort this out.  Would 
passing
all ARP requests and broadcast frames be dangerous from a security
point-of-view?  Could I have an ebtables rule that would only let DHCP
replies for the client B MAC-addresses pass?  What would happen if I 
don't
allow other broadcast packets and/or ARP frames to be bridged?

> ICMP source quench is deprecated and considered...

I'll remove that rule then ...

> My advice is to not use br0 but only eth0 and eth1 for IP setup, 
> DHCP,
> routing and so on.

But then how to combine this with the need to bridge stuff for client 
B?
Can I have eth0 and eth1 part of a bridge but still each having their 
own
IP address?  I guess that would then mean making the address part of 
br0
manual instead of dhcp, for eth1 making it static and for eth0 making 
it
dhcp.  But then what interface would be used in the different chains 
for
ebtables/iptables?  Ex. if a packet comes into eth1 but doesn't have an
IP address in the range of the IP address assigned to eth1, will it 
then
be considered being for br0?  Or will everything still be considered to
be for br0 even if the target IP address is that of eth1?

So, I really appreciate the feedback, but would even more appreciate 
some
more tips on how to still fill in the required stuff.

Thanks,
K

Re: Problems with bridge+router setup

[Pascal Hambourg]

Misterke a écrit :
> 
> On 2015-12-28 11:44, Pascal Hambourg wrote:
>> Does it use VLAN tagging (IEEE 802.1q) or plain ethernet ?
> 
> I don't think I can use VLAN tagging.

I am not saying to use VLAN tagging. I am asking whether the
communication between the cable modem and the TV box over the LAN uses
VLAN tagging, because I have seen it with a triple-play provider, and in
that case it is easy to identify which packets must be bridged : those
with a VLAN tag.

>> What about broadcast packets such as ARP requests or DHCP replies sent
>> by the cable modem ? How do you decide if they should be bridged ?
> 
> Good question. This is the sort of stuff I'm struggling with and basically
> looking for people that can indicate how to sort this out. Would passing
> all ARP requests and broadcast frames be dangerous from a security
> point-of-view?

It depends what your security requirements are. Beyond security, it
could disrupt normal operations of the hosts on the network.

> Could I have an ebtables rule that would only let DHCP
> replies for the client B MAC-addresses pass?

We can see in your kernel log that DHCP replies have the broadcast MAC
and IP destination addresses, so it requires to look into the DHCP
payload, not only the MAC/IP/UDP headers. I do not see how to do this
with ebtables. It may be done with iptables and the u32 match through
the bridge-nf feature.

> What would happen if I don't
> allow other broadcast packets and/or ARP frames to be bridged?

It depends on the the type of traffic used by communications between the
cable modem and the TV box.

>> My advice is to not use br0 but only eth0 and eth1 for IP setup, 
>> DHCP, routing and so on.
> 
> But then how to combine this with the need to bridge stuff for client B?

By carefully identifying which packets must be bridged.

> Can I have eth0 and eth1 part of a bridge but still each having their 
> own IP address?

Yes, ebtables' broute table allows it. When DROP is applied to a packet
in the broute table, it does not appear to be related with the bridge to
iptables and the IP layer.

For example, I have used it on a box which acts as an IP router for IPv4
traffic and as an ethernet bridge for IPv6 traffic. Each ethernet
interface has an IPv4 address, and the bridge interface has an IPv6 address.

But in your specific situation, you may need to use br0 as the logical
interface facing the cable modem, and only force routing of packets
received by the interface eth1 not sent by the TV box. So br0 would have
the internal LAN IP address, eth1 the external LAN IP address and DHCP
server, and eth0 no IP address.

One caveat about DHCP software (client and server) : they usually attach
directly to the interface and by-pass filtering rules. So you may need
to set up the DHCP server to ignore requests from the TV box.

> I guess that would then mean making the address part of br0
> manual instead of dhcp, for eth1 making it static and for eth0 making it
> dhcp.  But then what interface would be used in the different chains for
> ebtables/iptables?  Ex. if a packet comes into eth1 but doesn't have an
> IP address in the range of the IP address assigned to eth1, will it then
> be considered being for br0?  Or will everything still be considered to
> be for br0 even if the target IP address is that of eth1?

It depends whether DROP or ACCEPT is applied to the packet by ebtables
in the broute table.

Re: Problems with bridge+router setup

[Misterke]

On 2015-12-28 19:46, Pascal Hambourg wrote:

> I am not saying to use VLAN tagging. I am asking whether the
> communication between the cable modem and the TV box over the LAN 
> uses
> VLAN tagging, because I have seen it with a triple-play provider, and 
> in
> that case it is easy to identify which packets must be bridged : 
> those
> with a VLAN tag.

Ah, sorry for the misunderstanding.  Is there any way I could find out?
The supplier (Telenet) isn't communicating much on what it is doing 
between
its Set-Top_Boxes and the cable-modem, but putting them behind a router
does break the interactive functions (and hence also video-on-demand).

>> Would passing all ARP requests and broadcast frames be dangerous 
>> from a
>> security point-of-view?
>
> It depends what your security requirements are. Beyond security, it
> could disrupt normal operations of the hosts on the network.

Well, my security needs are pretty simple: nothing from the Internet 
(so
the cable-modem) should be able to get to anything on a host of type A
(unless being forwarded through iptables of course).  But I'm pretty
paranoia ...

When I now think about it, I guess this will never be 100% safe: 
possibly
the cable-modem could be hacked and since the B client (digital STB) is
directly reachable from the cable-modem, that one could also be 
compromised
and then just giving it an extra IP address within my LAN range, would
allow access to the LAN ...  Perhaps I need to rethink the original 
idea
completely ...  I assume setting up a VLAN for the B clients could
address this, but then I would need something more complex than a 
simple
switch near the clients, correct?

Thanks,
K

Re: Problems with bridge+router setup

[Neal P. Murphy]

On Mon, 28 Dec 2015 10:57:11 +0100
Misterke <netfilter@quintux.com> wrote:

> Reduced to the minimal, the needed setup would look something like 
> this:
> 
>          +------+
>    A ----|      |   single IP link   +------+       +-----------+
>          |Switch|--------------------| RPi2 |-------|Cable modem|
>    B ----|      |                eth1+------+eth0   +-----------+
>          +------+
> 
> Here client A is a normal network device for which the network it is 
> connected to should look like a normal LAN and the RPi2 should act as 
> firewall, DHCP & DNS server, etc.  In short: for client A the RPi2 
> should look like a typical router/firewall.
> 
> Client B however is a Digital TV box and my triple-play provider 
> unfortunately requires those to be directly connected to the cable 
> modem, which will hand them actually a DHCP address in a particular 
> range and probably do other special stuff.  In short: for client B the 
> entire network between itself and the cable modem should consist solely 
> of hubs/switches/bridges and hence for it to work the RPi2 should behave 
> as a simple bridge.

Hmmm. Since you have the RPi set up, connect the TV box directly to it and 'tcpdump -i br0 -vvv -X' so you can see the traffic that passes between the TV box and the CM. As Pascal said, TV traffic can be (or is usually) VLAN-tagged.

With the bridge in place, you should see traffic flow between B and the CM through the switch and RPi. If the traffic is VLAN-tagged, you might have to add that VLAN to eth0. At least once you *see* the traffic, you should be able to figure out how to make it work.

*However*, if the TV box and/or CM do not speak STP (which nodes need to learn where things reside behind switches and bridges) you might not be able to make it work.

You might end up having to use two RPis as forwarding/tunneling routers, one at the TV box and on at the CM, and run a GRE/IPSEC/OpenVPN tunnel between the two RPis, probably bridging (encapsulating) layer 2 through the tunnel. Done right, the tunnel should allow the TV box and the CM to think they are talking directly to each other.

          +------+
    A ----|      |   single IP link                  +-----------+
          |Switch|-----------------------------------|Cable modem|
       ---|      |----------                        -|           |
      /   +------+          \                      / +-----------+
     |                       |                     |
      \   (tunnel)           |                     |
       ------------          |                     |
                   \         | (tunnel)            |
                    |        |                     |
          +------+  |        |                     |
          |      | /         \        +------+     /
          | RPi3 |-           --------| RPi2 |-----
    B ----|      |                eth1+------+eth0   
          +------+

Note that "Switch" in the diagram could be any configuration of switches and routers.

RPi2 should allow multiple RPis to connect tunnels into it so you could have multiple TV boxes connected to the CM.

If the TV box's MAC address is important to the CM (I don't know if CM mfrs have gone this far), you may have to be creative and figure out how to make RPi2's eth0 use difference MAC addresses based on which TV box a packet belongs to.

My twerk of your idea costs more (additional RPis), but should do a better job keeping the internet and TV traffic separate.

N

Re: Problems with bridge+router setup

[Pascal Hambourg]

Misterke a écrit :
> On 2015-12-28 19:46, Pascal Hambourg wrote:
> 
>> I am not saying to use VLAN tagging. I am asking whether the
>> communication between the cable modem and the TV box over the LAN uses
>> VLAN tagging, because I have seen it with a triple-play provider, and 
>> in that case it is easy to identify which packets must be bridged : 
>> those with a VLAN tag.
> 
> Ah, sorry for the misunderstanding.  Is there any way I could find out?

Yes, with a packet sniffer such as tcpdump (-e to print the link layer
header) on a bridge port (not the bridge interface itself) while the TV
box and the cable modem are communicating with each other.

Re: Problems with bridge+router setup

[Misterke]

First of all: Happy New Year and Best Wishes to all.

I especially want to thank those who made the effort to reply to my 
questions - especially the setup indicated by Neal indeed reflects what 
I would need, but I'm afraid I've taken a bit of the "easy way out".  
Instead of making the effort to create a setup with Raspberry Pi's, I've 
added a second PowerLAN adapter at the client side and at the server 
side.  I hadn't mentioned before that the single IP link I was having 
was PowerLAN and I guess adding a second PowerLAN adapter with a 
different network isn't the best in terms of performance, but it was 
very low effort and so far seems to get the job done.

So, again many thanks for all the feedback and sorry that I chickened 
out and went for the "buy" instead of "make" solution.

Thanks,
K