3

My home network currently looks like this:

I'd like to restructure it to look like this (get rid of the ISP switch and plug the STBs into mine):

My gateway is a PC with two Ethernet ports (doing NAT and providing DHCP and DNS to my LAN) and is running GNU/Linux.

The obstacle is the ISP's STBs (set-top boxes, like cable boxes but using IPTV over Ethernet). These send a DHCP request which, when received by the ISP gateway, is answered with an internal IP (10.x.y.z) instead of a WAN one. The IPTV portal these devices try to connect to is only accessible from the internal IP.

So, what I need to effectively do is make my gateway behave like a switch (bridge?) for devices with certain MAC addresses.

I'm guessing I would need to do the following:

  • Add iptables rules to directly copy packets with source addresses matching STBs' MACs from the LAN to the WAN interface
  • Add iptables rules to directly copy packets with destination addresses matching STBs' MACs from the WAN to the LAN interface (i.e. the opposite of the above)
  • Make sure the gateway's DHCP server does not reply to the STBs' DHCP requests
  • Exempt packets from STBs' MACs from NAT-ing?
  • Do I need to worry about ARP requests?
  • Are you sure there's not some VLAN tagging going on in the ISP "switch"? That's how TV/internet is often handled by ISP providers. – dirkt Mar 12 '17 at 10:04
  • Yep, you're completely right. I posted an answer below. – Vladimir Panteleev Mar 12 '17 at 15:14
2

To answer the question as stated, I got some advice from a friend network guru to bridge the LAN and WAN interfaces, then use ebtables to filter out what is to get bridged:

lan0: [add LAN IPs and use as LAN interface]
    eth0 (LAN)
    eth1 (WAN) [add WAN IPs and use as WAN interface]

# Forward traffic to/from STBs
ebtables -A FORWARD -i eth0 -o eth1 -s $STB_MAC -j ACCEPT
ebtables -A FORWARD -i eth1 -o eth0 -d $STB_MAC -j ACCEPT

# Allow DHCP responses
ebtables -A FORWARD -i eth0 -o eth0 -d ff:ff:ff:ff:ff:ff -p ipv4 --ip-proto udp --ip-sport 67 --ip-dport 68 -j ACCEPT

# Allow ARP requests
ebtables -A FORWARD -i eth0 -o eth0 -d ff:ff:ff:ff:ff:ff -p arp --arp-ip-dst ! $LAN_SUBNET -j ACCEPT

# The WAN is not really part of the LAN
ebtables -A INPUT -i eth1 -j DROP
ebtables -A FORWARD -i eth1 -j DROP
ebtables -A FORWARD -o eth1 -j DROP
ebtables -A OUTPUT -o eth1 -j DROP

# Allow eth1 to be used to access the WAN
ebtables -t broute -A BROUTING -i eth1 -d $STB_MAC -j ACCEPT
ebtables -t broute -A BROUTING -i eth1 -d $STB_MAC -j ACCEPT
ebtables -t broute -A BROUTING -i eth1 -j DROP

However, in this case it turned out that the ISP switch is doing port-based VLAN tagging (one VLAN for the PC port and another VLAN for the STB ports).

Therefore, to get rid of the ISP router, I needed to:

  1. Set up the two VLANs on the gateway's WAN NIC
  2. Move the WAN IP configuration from the NIC to to the WAN VLAN (incl. the NAT)
  3. Blacklist the STBs' MAC addresses from my gateway's DHCP server
  4. Bridge the ISP's internal VLAN with my LAN
  5. (Optional) Add firewall rules to avoid LAN packets from leaking into the ISP VLAN.

This works because the ISP DHCP server already only replies to STBs' DHCP requests, so blacklisting them on the gateway results in all DHCP replies getting answered by either the gateway, or the ISP DHCP server. If using dnsmasq, blacklisting can be done using e.g. dhcp-host=01:23:45:*:*:*,ignore in /etc/dnsmasq.conf.

Everything else can be done using systemd-networkd configuration files: - Create .netdev files for VLANs - Add them (as VLAN entries) to the .network file matching on the WAN NIC - Create .network files for the VLANs - Create a .netdev file for the LAN/STB bridge - Add the STB VLAN and the LAN NIC to the bridge


Here's a full example set of systemd-networkd configuration files:

  • /etc/systemd/network/isp-link.network - Network configuration for the WAN NIC:

    Here we just set up the VLANs. Make sure to change the VLAN IDs to the one the ISP uses. This example uses 1234 for the WAN VLAN and 56 for the internal (IPTV) one.

    [Match]
    Name=eno1
    
    [Network]
    VLAN=eno1.1234
    VLAN=eno1.56
    
  • /etc/systemd/network/eno1.1234.netdev - WAN VLAN:

    [NetDev]
    Name=eno1.1234
    Kind=vlan
    
    [VLAN]
    Id=1234
    
  • /etc/systemd/network/eno1.56.netdev - ISP internal VLAN for IPTV:

    [NetDev]
    Name=eno1.56
    Kind=vlan
    
    [VLAN]
    Id=56
    
  • /etc/systemd/network/home-bridge.netdev - The ISP-VLAN/home-LAN bridge device:

    [NetDev]
    Name=br0
    Kind=bridge
    
  • /etc/systemd/network/home-bridge.network - The network for said bridge:

    Make sure to not enable the DHCP server here. As systemd-networkd doesn't allow configuring a blacklist of MACs to ignore, you'll need to use another DHCP server (e.g. dnsmasq) instead.

    [Match]
    Name=br0
    
    [Network]
    Address=192.168.0.1/24
    IPForward=yes
    IPMasquerade=yes
    DHCP=no
    DHCPServer=no
    
  • /etc/systemd/network/home-lan.network - Network file for the LAN NIC:

    [Match]
    Name=enp9s0
    
    [Network]
    Bridge=br0
    
  • /etc/systemd/network/isp-vlan-wan.network - Your gateway's WAN configuration:

    This uses DHCP - if you have a static configuration, change this to Address/Gateway/DNS settings.

    [Match]
    Name=eno1.1234
    
    [Network]
    IPForward=yes
    DHCP=yes
    
  • /etc/systemd/network/isp-vlan-internal.network - The network file for the internal VLAN:

    [Match]
    Name=eno1.56
    
    [Network]
    Bridge=br0
    
  • /etc/dnsmasq.conf - DHCP server configuration:

    # Disable DNS server - will be handled by systemd-networkd
    port=0
    
    # Enable and configure DHCP server
    dhcp-range=192.168.0.129,192.168.0.254,12h
    
    # Specify which interfaces to listen on
    listen-address=127.0.0.1
    listen-address=::1
    listen-address=192.168.0.1
    
    # Ignore DHCP requests from the STBs
    dhcp-host=01:23:45:*:*:*,ignore
    
  • So, even with the bridge in place, packets you drop using ebtables go up to routing and get forwarded (and NAT'ed) properly? (The combination of a bridge and a router is of course what you want, I'm just curious that it works.) – ilkkachu Mar 12 '17 at 18:03
  • Yes, I think that was the intent of the solution my friend sent me, but I didn't actually get to try that because I discovered the ISP switch was doing VLAN tagging, which changed the problem (and allowed for a simpler solution). – Vladimir Panteleev Mar 12 '17 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.