ALLOW_SUBNETS

The next step is to allow explicitly our subnets to talk to the router only. Let’s assume the router’s IP is configured to a class C private subnet like 192.168.1.1/16 and all hosts on the eth0 link should be allowed to send and receive traffic.

1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.1/16 brd 192.168.255.255 scope global eth0
 valid_lft forever preferred_lft forever

Usally configuring a firewall by hand all the micro management stuff begins now by adding them to the USER-IN or USER-OUT chains but there’s an easier way. In a common network setup there’s often some kind of internal interface on which private subnets reside. The ALLOW_SUBNETS call just expects an interface name and all subnets configured on that interface will be allowed to talk to the router host by placing appropriate rules in:

Chain USER-IN (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  ...   ... ACCEPT     all  --  eth0   *       192.168.0.0/16       0.0.0.0/0            /* ALLOW_SUBNETS_0x50e549399da8 */

Chain USER-OUT (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  ...   ... ACCEPT     all  --  *      eth0    192.168.1.1          192.168.0.0/16       /* ALLOW_SUBNETS_0x50e549399da8 */

Notice the comments to the right which are used to identify these rules as rules created by an ALLOW_SUBNET call. This is a good example of a logical ruleset spanning over multiple chains.

Although these rules allow primary traffic among the router and hosts of the 192.168.0.0/16 subnet additional traffic is still not allowed like link-local, service discovery or UPNP which needs to be explicitly allowed by using ALLOW_LINK_LOCAL or ALLOW_SERVICE_DISCOVERY which in turn opens up traffic originating from 169.254.0.0/16 or fe80::/10 subnets to allow use of ZeroConf address assignment like IPv4ll or Netbios|DNS based service discovery via multicast or UPNP features like available DLNA or AirPlay servers in your subnet. All these comfort features eases life on an internal link in a private subnet but these shouldn’t be available on a WAN device as they expose attack surface but since we’re on an internal link in our scenario we can safely allow them as ipturntables.sh in it’s default configuration doesn’t allow any forwarding of such traffic. Usally a router shouldn’t be allowed to use service discovery but there can be useful situations eg. when the router offers DNS multicast for hostname resolution on auto-configured subnets to specific interfaces only especially when a DHCP server isn’t available there.