[FS#305] firewall3: when OUTPUT policy != ACCEPT, drops SYN-ACK and ICMP responses; locks me out

Thu Nov 24 15:35:43 PST 2016

A new Flyspray task has been opened.  Details are below. 

User who did this - Stephan Güenther (stephg) 

Attached to Project - LEDE Project
Summary - firewall3: when OUTPUT policy != ACCEPT, drops SYN-ACK and ICMP responses; locks me out
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Medium
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - Hi,
some days ago, I refreshed LEDE on both of my WNDR3800 boxes. Both came back online, but I was locked out of my second one. No SSH was available on any interface, no ICMP ping, but forwarding worked as before the upgrade - so I attached to the serial console to have a look what was going on here.

Looks like the latest firewall3 update drops some packets in my configuration, as I had set the default policy of the OUTPUT chain to REJECT. 
This was happening for all zones, that had connection tracking disabled by 'CT notrack' in the RAW table. 
If I set the default OUTPUT policy to ACCEPT and append a LOG rule to the OUTPUT chain via "iptables -t filter -A OUTPUT -j LOG --log-tcp-sequence", kernel log looks like:

...
Thu Nov 24 22:15:14 2016 kern.warn kernel: [ 1818.447357] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=64488 SEQ=2355163424 ACK=3914841157 WINDOW=28960 RES=0x00 ACK SYN URGP=0
Thu Nov 24 22:15:14 2016 kern.warn kernel: [ 1818.470523] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=64489 SEQ=447042451 ACK=4013522446 WINDOW=28960 RES=0x00 ACK SYN URGP=0
Thu Nov 24 22:15:14 2016 kern.warn kernel: [ 1818.471213] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=64490 SEQ=3698739896 ACK=444755840 WINDOW=28960 RES=0x00 ACK SYN URGP=0
Thu Nov 24 22:15:14 2016 kern.warn kernel: [ 1818.471786] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=64491 SEQ=311442839 ACK=1880849946 WINDOW=28960 RES=0x00 ACK SYN URGP=0
Thu Nov 24 22:15:38 2016 kern.warn kernel: [ 1841.825532] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=64494 SEQ=2422750863 ACK=1891902227 WINDOW=28960 RES=0x00 ACK SYN URGP=0
Thu Nov 24 22:16:13 2016 kern.warn kernel: [ 1877.579688] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=64497 SEQ=2511690322 ACK=673872165 WINDOW=28960 RES=0x00 ACK SYN URGP=0
Thu Nov 24 22:16:13 2016 kern.warn kernel: [ 1877.601301] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=64498 SEQ=4262052991 ACK=1319238073 WINDOW=28960 RES=0x00 ACK SYN URGP=0
Thu Nov 24 22:16:13 2016 kern.warn kernel: [ 1877.602277] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=64499 SEQ=879927044 ACK=1056567903 WINDOW=28960 RES=0x00 ACK SYN URGP=0
...
Thu Nov 24 22:51:46 2016 kern.warn kernel: [ 4009.770506] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=14645 PROTO=ICMP TYPE=0 CODE=0 ID=32308 SEQ=0
Thu Nov 24 22:51:47 2016 kern.warn kernel: [ 4010.772715] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=14652 PROTO=ICMP TYPE=0 CODE=0 ID=32308 SEQ=1
Thu Nov 24 22:51:48 2016 kern.warn kernel: [ 4011.774709] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=14711 PROTO=ICMP TYPE=0 CODE=0 ID=32308 SEQ=2
Thu Nov 24 22:51:49 2016 kern.warn kernel: [ 4012.778672] IN= OUT=eth0 SRC=192.168.6.212 DST=192.168.6.222 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=14783 PROTO=ICMP TYPE=0 CODE=0 ID=32308 SEQ=3
....

Now, the zone's accept chain has "-m conntrack --ctstate NEW,UNTRACKED -j ACCEPT", but does not accept all packets if connection tracking is disabled - think this was not intended.

----
Supply the following if possible:
 - Device problem occurs on:
**any** 

 - Software versions of LEDE release, packages, etc.
**master**, probably after 
https://git.lede-project.org/?p=source.git;a=commitdiff;h=113544dccf113a8ed47e0a91ab2f6e02343c3e82 or
https://git.lede-project.org/?p=project/firewall3.git;a=commitdiff;h=6009904eb4dfe91e3d0b5cb96c4095232a303835 

 - Steps to reproduce
* grab x86 VM with LEDE
* make sure default policy for OUTPUT is ACCEPT
* make sure the zone has not forced connection tracking enabled, i.e. not "option conntrack 1" and has no NAT enabled, so it gets the "CT notrack" mark
* append logging rule to OUTPUT
* try SSH or PING to that zone
* watch kernel log for SYN-ACK packets

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