Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
openwrt-bot opened this issue Nov 24, 2016 · 2 comments
Closed

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

openwrt-bot opened this issue Nov 24, 2016 · 2 comments
Labels
flyspray

Comments

@openwrt-bot
Copy link

stephg:

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:

  • 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
@openwrt-bot
Copy link
Author

stephg:

Looks like this is resolved as with (I have not tested it yet):
https://git.lede-project.org/?p=project/firewall3.git;a=commitdiff;h=13698aafb52c45817ee7815da3405e620657c8d0

@openwrt-bot
Copy link
Author

stephg:

Solved with recent commit:
https://git.lede-project.org/?p=source.git;a=commit;h=2daab45cae3cfc09bae96f4326a3963a7504e86d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@openwrt-bot