Modify

Opened 2 years ago

Last modified 2 years ago

#20380 new defect

firewall zone name length of 12 characters or more breaks all networking

Reported by: tim@… Owned by: developers
Priority: high Milestone:
Component: base system Version: Barrier Breaker 14.07
Keywords: Cc:

Description

Hi, I'm testing with OpenWrt 14.07 BB.

If one creates a firewall zone name that is 12 characters in
length or more, this results in non-working iptables rules that
breaks networking entirely on the device.

Booting in safe mode and shortening the name is the fix.

The issue is that iptables allows rules that are a maximum of 28
characters. The zone name is part of the iptables rules so if
the name is too long, the rule name has truncation at the end
and the whole table doesn't work as expected.

A simple fix is to limit the zone name length in LuCi to
a maximum of 11 characters.

Regards,
Tim Miller Dyck

==

Testing data:

using BARRIER BREAKER (14.07, r42625)

Check the generated rule names:

forwarding_ZONENAME_rule (1 references)
input_ZONENAME_rule (1 references)
output_ZONENAME_rule (1 references)
zone_ZONENAME_dest_ACCEPT (1 references) this is the longest one
zone_ZONENAME_dest_REJECT (1 references) this is the longest one
zone_ZONENAME_forward (0 references)
zone_ZONENAME_input (0 references)
zone_ZONENAME_output (0 references)
zone_ZONENAME_src_ACCEPT (1 references)

root@OpenWrt:~# iptables --version
iptables v1.4.21

Find the maximum iptables chain name length:

root@OpenWrt:~# iptables -N testchain01
root@OpenWrt:~# iptables -N testchain012
root@OpenWrt:~# iptables -N testchain0123
root@OpenWrt:~# iptables -N testchain01234
root@OpenWrt:~# iptables -N testchain012345
root@OpenWrt:~# iptables -N testchain0123456
root@OpenWrt:~# iptables -N testchain01234567
root@OpenWrt:~# iptables -N testchain012345678
root@OpenWrt:~# iptables -N testchain0123456789
root@OpenWrt:~# iptables -N testchain01234567890
root@OpenWrt:~# iptables -N testchain012345678901
root@OpenWrt:~# iptables -N testchain0123456789012
root@OpenWrt:~# iptables -N testchain01234567890123
root@OpenWrt:~# iptables -N testchain012345678901234
root@OpenWrt:~# iptables -N testchain0123456789012345
root@OpenWrt:~# iptables -N testchain01234567890123456
root@OpenWrt:~# iptables -N testchain012345678901234567
root@OpenWrt:~# iptables -N testchain0123456789012345678

so a 28 character length is OK

root@OpenWrt:~# iptables -N testchain01234567890123456789
iptables v1.4.21: chain name `testchain01234567890123456789' too long (must be under 29 chars)
Try `iptables -h' or 'iptables --help' for more information.

but 29 characters is too long

So, considering the longest generated rule name:
zone_ZONENAME_dest_ACCEPT

There are 17 characters not including the zone name.

So 11 characters is the maximum working firewall zone name length.

Attachments (0)

Change History (11)

comment:1 Changed 2 years ago by hnyman

It seems to me that the limit set in firewall3 sources (zones.h) is probably wrongly using XT_TABLE_MAXNAMELEN (=32) instead of XT_EXTENSION_MAXNAMELEN (=29) as the basis when defining the limit as 14:

http://nbd.name/gitweb.cgi?p=firewall3.git;a=blob;f=zones.h;h=4205196268f75061280ac13da656ab4362245a06;hb=18a503d0125aebc3a8d62dad1c02e6bb1da92eb6#l25

    /* 32 - sizeof("postrouting_") - sizeof("_rule") - sizeof("\0") */
      #define FW3_ZONE_MAXNAMELEN 14

Reference to iptables:
http://git.netfilter.org/iptables/tree/iptables/iptables.c?id=482c6d3731e2681cb4baae835c294840300197e6#n381

XT_EXTENSION_MAXNAMELEN as 29:
http://lxr.free-electrons.com/source/include/uapi/linux/netfilter/x_tables.h

Repeating the same calculation, but starting from 29 would lead to 11 as the allowed max. length for a zone name.

comment:2 Changed 2 years ago by tim@…

This is solved in Luci for 15.05 and master as per the commit in https://github.com/openwrt/luci/issues/507

-Tim Miller Dyck

comment:3 follow-up: Changed 2 years ago by Damian Kaczkowski

There is also a problem with the length of interface name in uci config. Length >13 causes troubles with firewall reloads - problably the same issue as OP describes. Length >12 causes problems with dnsmasq. Seems that max length of iface for dnsmasq is 12 - you can see it on logread when host requests for an ip.

comment:4 in reply to: ↑ 3 Changed 2 years ago by hnyman

Replying to Damian Kaczkowski:

There is also a problem with the length of interface name in uci config. Length >13 causes troubles with firewall reloads - problably the same issue as OP describes. Length >12 causes problems with dnsmasq. Seems that max length of iface for dnsmasq is 12 - you can see it on logread when host requests for an ip.

It might be something similar, but maybe from some other reason? I can't see any firewall rule containing the interface name, so I wonder about the source of the problem. Max length of some argument?

If you have them available, could you provide an example of the errors in the system log. Especially the dnsmasq one interests, as that is the shorter one.

Adding a limit to Luci is relatively easy.

comment:5 follow-up: Changed 2 years ago by Damian Kaczkowski

Try such config:

network:

config interface 'lan_protected'
        list ifname 'eth0.1'
        option type 'bridge'
        (...)

dnsmasq.conf

dhcp-range=tag:br-lan_protected,192.168.0.2,192.168.0.249,255.255.255.0,12h

firewall

config zone
        option name 'lan_protected'
        list network 'lan_protected'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option family 'ipv4'

Then check dnsmasq logs on logread. You will see that interface name on dhcp logs is truncated. Also the firewall zone won't be created when issueing fw3 reload. "lan_protecte" causes that one of firewall or dnsmasq works. "lan_protect" or shorter makes both firewall and dnsmasq to work.

Btw. dnsmasq generation script (/etc/config/dhcp) generates wrong dhcp-range sections, eg:

dhcp-range=lan_protected,192.168.0.2,192.168.0.249,255.255.255.0,12h

DNS man page says:

The optional set:<tag> sets an alphanumeric label which marks this network so that dhcp options may be specified on a per-network basis. When it is prefixed with 'tag:' instead, then its meaning changes from setting a tag to matching it.
 This system evolved from an earlier, more limited one and for backward compatibility "net:" may be used instead of "tag:" and "set:" may be omitted. (Except in dhcp-host, where "net:" may be used instead of "set:".)

So "tag" should be used to match the dhcp-range to interface but dhcp config auto generates dhcp-range directives (in /var/etc/dnsmasq.conf) as "set:" (casue man page says that "set:" may be ommited).

comment:6 Changed 2 years ago by Damian Kaczkowski

Also dhcp config script creates "lan" as tag, but it should create "br-lan" as tag, as dnsmasq sees and match to real linux interfaces, not uci interface names. So current dhcp generetion script logic is wrong for bridge interfaces.

comment:7 in reply to: ↑ 5 Changed 2 years ago by hnyman

Replying to Damian Kaczkowski:

firewall

config zone
        option name 'lan_protected'
        list network 'lan_protected'

...Also the firewall zone won't be created when issueing fw3 reload.

That is again due to the long zone name, if I understand it right. It exceeds 11 chars and triggers the error.

I tried earlier with a long interface name, but could not see the problem at firewall reload (as long as the zone name was short).

comment:8 follow-up: Changed 2 years ago by Damian Kaczkowski

config interface 'lan_protected'
        list ifname 'eth0.3'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        list ipaddr '10.111.111.1/24'
config zone
        option name 'lan_p'
        list network 'lan_protected'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option family 'ipv4'

fw3 reload

 * Populating IPv4 filter table
   * Zone 'lan'
   * Zone 'wan'
   * Zone 'lan_p'
   * Rule 'Allow-DHCP-Renew'
   * Rule 'Allow-Ping'
   * Rule 'Allow_DNS_from_IPSec'
   * Rule '500_udp_wan_INPUT_ACCEPT'
   * Rule '4500_udp_wan_INPUT_ACCEPT'
   * Rule 'esp_wan_INPUT_ACCEPT'
   * Forward 'lan' -> 'wan'
(null) v4: interface name `br-lan_protected' must be shorter than IFNAMSIZ (15)

ifconfig - notice "br-lan_protecte"

br-lan_protecte Link encap:Ethernet  HWaddr 4C:5E:0C:E1:8A:95
          inet addr:10.111.111.1  Bcast:10.111.111.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:808 (808.0 B)

ip addr

8: br-lan_protecte: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 4c:5e:0c:e1:8a:95 brd ff:ff:ff:ff:ff:ff
    inet 10.111.111.1/24 brd 10.111.111.255 scope global br-lan_protecte
       valid_lft forever preferred_lft forever
    inet6 fe80::4e5e:cff:fee1:8a95/64 scope link
       valid_lft forever preferred_lft forever

dnsmasq will follow real interface name (br-lan_protecte) and config such as

config dhcp 'lan_protected'
        option interface 'lan_protected'
        (...)

won't work too.

r45314

comment:9 in reply to: ↑ 8 Changed 2 years ago by hnyman

Replying to Damian Kaczkowski:

config interface 'lan_protected'
...
        option type 'bridge'
config zone
        option name 'lan_p'
        list network 'lan_protected'

fw3 reload

 * Populating IPv4 filter table
...
   * Forward 'lan' -> 'wan'
(null) v4: interface name `br-lan_protected' must be shorter than IFNAMSIZ (15)

Thanks for a clear example.

I tested yesterday with a normal non-bridged interface with a 14 characters long name and it worked ok. But your lan_protected is bridged and that makes it then prefixed with "br-" making the name to be 16 chars in total. Your error message hints that the limit is actually 15 chars.

interface name `br-lan_protected' must be shorter than IFNAMSIZ (15)

Your example clearly shows that name length needs to be limited to 15 characters.

IFNAMSIZ is defined as 16, and the name need to be shorter:
http://lxr.free-electrons.com/source/include/uapi/linux/if.h#L26

#define IFNAMSIZ 16

So 15 would be the maximum length at the first glance.

But there can be a possible prefix, like your "br-", but also "6in4-" etc.

root@OpenWrt:~# ifconfig
6in4-sixxs Link encap:IPv6-in-IPv4

That makes me wonder if the actual longest always working interface name regardless of the possible type would be just 10 characters taking into account the possibly 5 chars long prefix.

comment:10 Changed 2 years ago by hnyman

And actually "pppoe-" is even longer. :-(

comment:11 Changed 2 years ago by Damian Kaczkowski

Hmm. True. Imo openwrt should not auto add any prefix to ifnames. It should just use the name given by user config. But that is the other topic...

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.