OpenWrt/LEDE Project

Welcome to the OpenWrt/LEDE Project bug reporting and issue tracking system

Problems to be reported here are for the OpenWrt/LEDE Project targets, sources, toolchain, core packages, build procedures, distribution and infrastructure. Guidelines for submitting a good bug report can be found at the OpenWrt/LEDE Project website. Problems related to LuCI or OpenWrt packages need to be reported in their repositories:

Notifications of all submissions and task changes are sent to lede-bugs@infradead.org.

OpenedIDCategoryTask TypePrioritySeveritySummaryReported InStatus
16.08.20192446Base systemBug ReportVery LowLowbooting with qemu, firewall fails to protect router ser...TrunkWaiting on reporter Task Description

Started latest malta snapshot with qemu, did not change any configuration.
IPv6 wan interface gets its link-local address.
Firewall allows connections to this address from wan.
Firewall restart helps.

 
tunctl
brctl addbr testbr
brctl addif testbr tap0
ip link set dev tap0 up
ip link set dev testbr up

qemu-system-mips -kernel  openwrt-malta-be-vmlinux.elf 
-hda openwrt-malta-be-rootfs-ext4.img 
-append "root=/dev/sda console=ttyS0" 
-nographic -m 64 
-net nic,model=pcnet 
-net tap,ifname=tap0,script=no,downscript=no
root@OpenWrt:/# ip6tables -nvL INPUT
Chain INPUT (policy ACCEPT 4 packets, 208 bytes)
 pkts bytes target     prot opt in     out     source               destination         
	0     0 ACCEPT     all      lo     *       ::/0                 ::/0                 /* !fw3 */
	4   208 input_rule  all      *      *       ::/0                 ::/0                 /* !fw3: Custom input rule chain */
	0     0 ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED /* !fw3 */
	0     0 syn_flood  tcp      *      *       ::/0                 ::/0                 tcp flags:0x17/0x02 /* !fw3 */
 

After firewall restart (counters are different due to different runs)

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
	0     0 ACCEPT     all      lo     *       ::/0                 ::/0                 /* !fw3 */
	1    80 input_rule  all      *      *       ::/0                 ::/0                 /* !fw3: Custom input rule chain */
	0     0 ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED /* !fw3 */
	1    80 syn_flood  tcp      *      *       ::/0                 ::/0                 tcp flags:0x17/0x02 /* !fw3 */
	1    80 zone_wan_input  all      eth0   *       ::/0                 ::/0                 /* !fw3 */
14.03.20192184Base systemBug ReportVery LowLowWhen interface is deleted from LuCI, it's name isn't de...openwrt-18.06Unconfirmed Task Description

If an interface is created and assigned a firewall zone, then this interface is deleted form LuCI, its name remains in /etc/config/firewall

11.02.20192118OtherFeature RequestVery LowHighRenaming pre-configured firewall-zone names...AllUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
This is a suggestion and is not a model-specific bug report.

- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 18.06.1, r7258-5eb055306f

- Steps to reproduce
Description below:

This is a decade-old suggestion I’ve held within and I really hope the words will gather enough attention and momentum of the dev team. Streight to the conclusion, two pre-configured firewall-zones IMHO should be renamed from “lan” to “internal” and “wan” to “external” respectively. There are a few reasons for which I confidently feel this should be done. I’d like to argue that this is important if not essential because;
a.)Those who prefer making changes to current configurations by editing /etc/config/*, using stuff like “sed -i ‘s/before/after/g’ ${file}” (and then proceeding to reboot) is powerful and is almost mistake-free. checking for config-mistakes using grep is also powerful (and this applies to folks using uci CUI tool as well). What I do now is rename these two zones from GUI and then proceed to these steps, and it works great but having to take this extra step is rather inconvenient if not annoying.
b.)Current presets for interfaces have IPv4-WAN named as “wan” and IPv6-WAN named as “wan6” where the IPv4-WAN‘s label “wan” is no different from the firewalled-zone labeled as “wan”. This is simply comfusing. In early days when I I had just heard about the OpenWrt and had started messing with releases like Kamikaze,I had hard times understanding which string corresponded to which (sure you may argue this is documented in details but things don’t work like that for newbies).
c.)If needs for either firewall-zones or the interface-labels to be renamed are understood, I’d then have to say I’m against renaming interface-labels because those who’d decide to use VLANs would most likely name the interfaces as “config interface ‘vlan_ID’” and the string lan would stay in there.

I hope the above proposal is powerful enough...

11.02.20192117Base systemBug ReportVery LowMediumFirewall - Custom Rules ingonred in some casesAllUnconfirmed Task Description

- Device problem occurs on
linkys WRT3500
- Software versions of OpenWrt/LEDE release, packages, etc.
all lede versions
- Steps to reproduce
Configure iptables custom rules in LUCI luci/admin/network/firewall/custom
the commands goes to /etc/firewall.user file

part of /etc/config/firewall:


config include

      option path '/etc/firewall.user'

———–

Note there is no “option reload ‘1’” added into config file, thus “fw3 reload” used in /etc/init.d/firewall and /etc/hotplug.d/iface/20-firewall (maybe somewhere else) does not reload user rules.

adding manually option “reaload 1” into /etc/config/firewall solve this issue.

06.02.20192106KernelBug ReportVery LowMediumnew storage and match method required in firewall3/ipse...AllUnconfirmed Task Description

The new version of ipset now incoporates new set type: “hash:mac”.

But in openwrt project firewall3/ipset.c this new set type is not supported (line 68-87).

The result is that while refreshing firewall error message “Section @ipset has an invalid combination of storage method and matches” would appear, and no set type is created.

Please made some revision.

Thank you!

09.10.20181889Base systemBug ReportVery LowLowsysupgrade should try and preserve running states of th...TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

everything

- Software versions of OpenWrt/LEDE release, packages, etc.

- Steps to reproduce

do a sysupgrade on a remote box somewhere. The firewall and web server
are started by default. In some cases (like in an interior router) these
have been disabled explicitly so you can manage them from the outside. So preserving
the running state somehow of the essential services across an upgrade would help.

(bug report filed after I had to climb a building to re-re-re-flash a router after
foolishly thinking all I had to do was a sysupgrade)

 


30.05.20181569Base systemBug ReportVery LowLowWhy comment out firewall rules when we can disable them...TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

1U Xeon D-1518 server

- Software versions of OpenWrt/LEDE release, packages, etc.

x86_64, master, r5968, firewall

- Steps to reproduce

Looking at /etc/config/firewall I see:

# port redirect of remapped ssh port (22001) on wan
#config redirect
#      option src              wan
#      option src_dport        22001
#      option dest             lan
#      option dest_port        22
#      option proto            tcp

but would like to see:

# port redirect of remapped ssh port (22001) on wan
config redirect
      option src              wan
      option src_dport        22001
      option dest             lan
      option dest_port        22
      option proto            tcp
      option enabled          false

instead. Note the “option enabled false” line.

12.05.20181545Base systemBug ReportVery LowLowFirewall unnecessarily logging connection closesTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

x86_64, generic (in this case, Supermicro SYS-5018D-FN8T)

- Software versions of OpenWrt/LEDE release, packages, etc.

OpenWrt master

- Steps to reproduce

 

This is fairly easy. A while back (around 1997) Sun (which then was the go-to manufacturer for Web servers) decided that a clean 2-way close of a socket (including quiet-time) was too time consuming and that in an effort to be able to cycle through the 5-tuple space more quickly (i.e. in under 250 seconds... keep in mind we were still using HTTP 1.0 back then which didn’t allow connection reuse) they’d do a RESET on the connection to circumvent the clean shutdown and quiet-time.

Well, it worked, and now lots of servers tend to do a RESET on the connection. Some still do a 2-way close...

The problem is that this confuses NAT state on firewalls, which drop the connection information as soon as they see the outbound (since it’s closer it’s usually seen first) RESET packet, but then they see the inbound reset and they’re confused because they’ve already dropped the state associated with the connection. Or else the firewall sees the outbound FIN, ACK but doesn’t bother to wait for the FIN at this point before deleting NAT state, since it’s the server’s problem if he doesn’t get it...

If they held onto it (connection state) for a couple of seconds, then it would make more sense... but it would also interfere with cycling through the 5-tuple space quickly. So they can’t.

As a result (you were wondering when I was going to get to the point, right? I know I was...), you end up seeing a lot of these harmless but annoying messages in your logs:

May 12 10:54:09 OpenWrt3 kernel: [481026.650247] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=117 TOS=0×00 PREC=0×00 TTL=54 ID=30282 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0×00 ACK PSH URGP=0
May 12 10:54:09 OpenWrt3 kernel: [481026.700207] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=64 TOS=0×00 PREC=0×00 TTL=54 ID=30283 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0×00 ACK FIN URGP=0
May 12 10:54:09 OpenWrt3 kernel: [481026.984519] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=64 TOS=0×00 PREC=0×00 TTL=54 ID=30284 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0×00 ACK FIN URGP=0
May 12 10:54:10 OpenWrt3 kernel: [481027.855512] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=117 TOS=0×00 PREC=0×00 TTL=54 ID=30285 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0×00 ACK PSH FIN URGP=0

For UDP, there’s so connection state so messages related to packets which can’t get admitted will always be logged. That’s fine, and most traffic isn’t UDP anyway, so that’s not a problem.

But for TCP, logging incoming connection attempts or obviously wrong connection state makes sense... but do we need to log sloppy connection closes?

Can we filter out FIN packets? I guess that would leave us unaware of stealth scans, but I can’t think of a better solution... especially on boxes with limited persistent logging resources.

11.04.20181483Base systemBug ReportVery LowLowFirewall - firewall rules with time+date don't seem to ...TrunkUnconfirmed Task Description

I am running openwrt_cc, and having trouble with time+date based firewall rules. Time based rules (without date) work fine, but as soon as I add the date, the time no longer works. I expect such rules to take effect at the specified times within the specified dates. The resulting iptables do not look right. See below.

PKG_NAME:=firewall
PKG_VERSION:=2015-07-27
PKG_SOURCE_URL:=git://nbd.name/firewall3.git
PKG_SOURCE_VERSION:=980b7859bbd1db1e5e46422fccccbce38f9809ab

firewall uci:

config rule

      option name 'lan-00:16:3e:d2:96:cf'
      option src 'lan'
      option dest 'wan'
      option proto 'any'
      option target 'REJECT'
      option src_mac '00:16:3e:d2:96:cf'
      option start_date '2018-04-10'
      option stop_date '2018-04-11'
      option start_time '20:30:00'
      option stop_time '20:40:00'

iptables entry:

  0     0 zone_wan_dest_REJECT  all  --  any    any     anywhere             anywhere             MAC 00:16:3E:D2:96:CF TIME from 20:30:00 to 20:40:00 starting from 2018-04-10 01:00:00 until date 2018-04-11 01:00:00 UTC /* lan-00:16:3e:d2:96:cf */

Notice the date values are followed by “01:00:00” which doesn’t seem right. I can’t seem to control these values in any way from the uci.

01.08.2017944PackagesBug ReportVery LowLowfirewall3 isn't holding iptables lockTrunkUnconfirmed Task Description

I was first thinking that my missing iptables rules are related to the bug  FS#943 . But it looks like firewall3 is not holding the iptables lock via the option “-w”. This is unsafe because multiple iptables process may try to change a table at the same time and thus overwrite the final results of another iptables process.

The -w functionality for iptables-restore can be found in https://git.netfilter.org/iptables/commit/?id=999eaa241212d3952ddff39a99d0d55a74e3639e

12.02.2017500Base systemBug ReportVery LowLowfirewall3: missing targets with IPv6 NATopenwrt-18.06Unconfirmed Task Description

When the kmod-ipt-nat6 package is installed, running /etc/init.d/firewall reload or /etc/init.d/firewall restart produces warnings that targets are missing:

 * Populating IPv6 nat table
   * Zone 'lan'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_lan_rule'
   * Zone 'wan'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_rule'

I tested this on an Archer C7 v2 running LEDE 17.01.0rc2.

15.01.2017389Base systemBug ReportVery LowLowodhcpd relay mode is blocked by firewall by defaultTrunkUnconfirmed Task Description

odhcpd currently won’t work when put in relay mode if followed the manual naively. Turns out this is because firewall blocks incoming traffic to DHCPv6 server (port 547) from external DHCPv6 servers (port 547) from WAN zone by default. It may be a good idea to allow this out of the box, though I’m unsure if there are any security complications from this – I’m a newcomer to IPv6. Replies come with the source global IPv6 address of DHCPv6 server to the global IPv6 address of the router, so it’s difficult to make a more constrained rule without hardcoding them or at least the prefix.

Example rule which fixes relay mode:

config rule
	option enabled '1'
	option target 'ACCEPT'
	option src 'wan'
	option proto 'udp'
	option dest_port '547'
	option name 'Allow DHCPv6 Relay'
	option family 'ipv6'
	option src_port '547'

LEDE revision: 3e7b894ac08b56343e6e449a38fdb2be7b02a127

Showing tasks 1 - 12 of 12 Page 1 of 1

Available keyboard shortcuts

Tasklist

Task Details

Task Editing