firewall3: when OUTPUT policy != ACCEPT, drops SYN-ACK and ICMP responses; locks me out
Username: Stephan Günther
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=305
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
- 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