[FS#920] Final (default) rule in user defined zones wrong

[LEDE Bugs]

The following task has a new comment added:

FS#920 - Final (default) rule in user defined zones wrong
User who did this - Jo-Philipp Wich (jow-)

----------
> Although I still don't understand how a packet can end up in an iptables FORWARD chain with both input and output interfaces the same, I thank you for your time explaining the reasons why this was changed.

Thats easy. Consider two wireless clients in the same network, PC (10.11.12.7) and laptop (10.11.12.20) with the access point having 10.11.12.13 as br-lan address.

Install a test rule:

    # iptables -I FORWARD -i br-lan -o br-lan -j LOG


Install a host route to laptop on PC:

    $ sudo ip route add 10.11.12.20/32 via 10.11.12.13 dev eth0


Perform a ping test:

    $ ping 10.11.12.20
    PING 10.11.12.20 (10.11.12.20) 56(84) bytes of data.
    64 bytes from 10.11.12.20: icmp_seq=1 ttl=64 time=22.5 ms
    From 10.11.12.13: icmp_seq=2 Redirect Host(New nexthop: 10.11.12.20)
    64 bytes from 10.11.12.20: icmp_seq=2 ttl=64 time=21.4 ms


Review dmesg on the router:

    [1616624.233923] IN=br-lan OUT=br-lan MAC=00:0d:b9:35:88:4a:64:66:b3:47:e1:b9:08:00 SRC=10.11.12.7 DST=10.11.12.20 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=40557 DF PROTO=ICMP TYPE=8 CODE=0 ID=1709 SEQ=1


Usually the router is bypassed due to direct ARP resolution and nexthop redirection via ICMP but to actually enforce non-forwarding policy, an iptables rule has to be emitted.

Depending on the overall network structure and policies, the ability to misuse an unrelated router as nexthop might be a problem as it would allow hosts to steer their traffic differently to how it was intended by the network operator.

Another possible case is wireless with client isolation where local subnet traffic is forced via the router in order to enforce traffic isolation or filtering. In such a case you too will see forward traffic entering and leaving on the same network device.
----------

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=920#comment3039