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.

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#3520 - Firewall rules not applied on boot #8568

Closed
openwrt-bot opened this issue Dec 18, 2020 · 4 comments
Closed

FS#3520 - Firewall rules not applied on boot #8568

openwrt-bot opened this issue Dec 18, 2020 · 4 comments
Labels
flyspray

Comments

@openwrt-bot
Copy link

rascalDan:

Generally speaking everything works absolutely fine (loving openwrt so far!) except for the small detail that after the system has booted, there are no firewall rules, at all.

The LAN link comes, the PPPOE connection to my ISP comes, and openwrt can talk out to the internet, but nothing else on the network can (no NAT, masqurading etc gets configured)

If I log into the LuCI interface, go the firewall status page, it's empty apart from the headings. Click restart firewall, everything appears and all the expected networking functionality across the network words just fine. It continues to work just fine until it's rebooted... same problem... same solution.

I've tried restarting the firewall service over SSH using
/etc/init.d/firewall restart

But this oddly had no effect... might be a timing thing as I believe this is exactly what the LuCI interface does, but that takes me slightly longer to achieve.

Supply the following if possible:

  • Device problem occurs on:
  • systemd 247 on Linux 5.4.80
  • nspawn container running openwrt-x86_64
  • Software versions of OpenWrt/LEDE release, packages, etc.
  • LuCI openwrt-19.07 branch (git-20.348.38488-caae7ad) / OpenWrt 19.07.5 r11257-5090152ae3
  • Steps to reproduce
  • machinectl import-tar openwrt-19.07.5-x86-64-generic-rootfs.tar.gz openwrt
  • Configure some network (in my case, changed the lan interface name from eth0 to host0 as provided by nspawn and add PPPOE connection)
  • View firewall status

It may be that some firewall rules should be present without any non-default configuration, I'm new to openwrt, so I didn't realise the problem until I got this far and networking wasn't working as I expected.

A copy of the firewall configuration and network configuration (username/password for ISP redacted) are attached.

A copy of the system log is attached, although I don't see anything jumping out as problematic. kernel log is empty, which I presume is expected as this is a container. Happy to provide more logs/configurations to anyone who can make use of them.
@openwrt-bot
Copy link
Author

rascalDan:

Update: restarting the service via SSH does appear to work (sometimes?)

After adjusting the quiet settings for the service, on boot the following is logged:

notice procd: /etc/rc.d/S19firewall: Warning: Failed to connect to ubus
notice procd: /etc/rc.d/S19firewall: Warning: Unable to locate ipset utility, disabling ipset support
notice procd: /etc/rc.d/S19firewall: Warning: Section @zone[0] (lan) cannot resolve device of network 'lan'
notice procd: /etc/rc.d/S19firewall: Warning: Section @zone[1] (wan) cannot resolve device of network 'wan'
notice procd: /etc/rc.d/S19firewall: Warning: Section @zone[1] (wan) cannot resolve device of network 'wan6'
notice procd: /etc/rc.d/S19firewall: Warning: Section @zone[1] (wan) cannot resolve device of network 'plusnet'
notice procd: /etc/rc.d/S19firewall: * Set tcp_ecn to off
notice procd: /etc/rc.d/S19firewall: * Set tcp_syncookies to on
notice procd: /etc/rc.d/S19firewall: ! Unable to write value: No such file or directory
notice procd: /etc/rc.d/S19firewall: * Set tcp_window_scaling to on
notice procd: /etc/rc.d/S19firewall: * Running script '/etc/firewall.user'

Restarting the service over SSH logs (to the console):

root@openwrt:~# /etc/init.d/firewall restart
Warning: Unable to locate ipset utility, disabling ipset support
Warning: Section @zone[1] (wan) cannot resolve device of network 'wan'
Warning: Section @zone[1] (wan) cannot resolve device of network 'wan6'

  • Flushing IPv4 filter table
  • Flushing IPv4 nat table
  • Flushing IPv4 mangle table
  • Populating IPv4 filter table
    • Rule 'Allow-DHCP-Renew'
    • Rule 'Allow-Ping'
    • Rule 'Allow-IGMP'
    • Rule 'Allow-IPSec-ESP'
    • Rule 'Allow-ISAKMP'
    • Redirect 'HTTP'
    • Redirect 'HTTPS'
    • Redirect 'SMTP'
    • Redirect 'IMAPS'
    • Forward 'lan' -> 'wan'
    • Zone 'lan'
    • Zone 'wan'
  • Populating IPv4 nat table
    • Redirect 'HTTP'
    • Redirect 'HTTPS'
    • Redirect 'SMTP'
    • Redirect 'IMAPS'
    • Zone 'lan'
    • Zone 'wan'
  • Populating IPv4 mangle table
    • Zone 'lan'
    • Zone 'wan'
  • Set tcp_ecn to off
  • Set tcp_syncookies to on
    ! Unable to write value: No such file or directory
  • Set tcp_window_scaling to on
  • Running script '/etc/firewall.user'

@openwrt-bot
Copy link
Author

rascalDan:

Continued to dig around with various bits of tweaks and logging etc.

I think I finally bottomed the issue, but I'm not sure of the cause.

I've worked around it by adding

iptables -L iptables -t nat -L

to /etc/init.d/firewall's boot() function before it calls start().

On the face of it, it made no sense. But then I figure this is what was I witnessing with the issue where sometimes restarting the firewall service worked and sometimes it didn't. If I've visited the firewall status page (which presumably invokes iptables or otherwise queries the iptable status for display purposes) that's enough to provide the same poke as calling iptables from the init script.

I think this is a variation of [[https://forum.openwrt.org/t/iptables-are-empty-at-boot-or-on-reload/47421/2]] but that was supposably fixed in v19... maybe it isn't.

@openwrt-bot
Copy link
Author

jow-:

Most likely the both iptables commands trigger kernel module loading in the host kernel and/or trigger the availability of netfilter tables within your container which allows firewall3 to function as expected.

The fw3 executable itself will check if a given table is available through /proc/net/ip_tables_names and /proc/net/ip6_tables_names. If the table is not found in there, it is skipped - which likely leads to the issue you see.

Marking this bug as duplicate of FS#2575 since it appears to be essentially the same issue.

So the underlying problem appears to be that the various container/virtualization environments do not properly populate proc/net/ip{,6}_tables_names until after iptables has been run which somehow directly or indirectly triggers a refresh of these files.

@openwrt-bot
Copy link
Author

jow-:

See also https://lists.debian.org/debian-user/2019/10/msg01019.html for a potential host-side solution.

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