Autoload / autstart of custom firewall rules (script?) does not work

Hi,

I have problems getting custom firewall rules (or a script) automatically executed.

Background:
The Turris Omnia is deployed in an office and starts automatically a Wireguard connection at startup. This works flawlessly.
But some services must be excluded from the vpn route and therefor I have the following script:

#!/bin/sh
logger "ReRouting VPN exceptions start"
wan_gw=$(ip route | awk '/dev eth2.102 proto static/ { print $3 }' | awk NR==1)
ip rule add from 192.168.1.192/27 table novpn
ip rule add from 49.190.2.82 table novpn
ip route add default via "$wan_gw" dev eth2.102 table novpn
ip route add 192.168.1.192/27 dev eth2.102 table novpn
ip route flush cache
logger "ReRouting VPN exceptions end"

(There is a corresponding script restoring the default route in case the VPN is shut down.)

This script works, but I am not able to autostart or autoload this as custom firewall rules.
I tried:

  1. The script in /etc/rc.d/ (which I might have done wrong)
  2. a call to the script (not the commands themselves) in /etc/rc.local
  3. the commands as custom firewall rules in the “command window” under Firewall - Custom rules

None of this worked! I can never find the logger output in any log. And every time the router restarts, I have to run the script “by hand”.

I therefore hope someone can help me to fix this.
My ideas / questions:

  1. Maybe all the script does can be done in configuration and does not need a script at all? <— Preferable, as I see it.
  2. What is the “proper” way to autostart this script? Init.d? cron @boot?
  3. As far as I can see the Wireguard implementation does not support on-startup / on-shutdown scripts as OpenVPN does. Do I understand this wrong?

Any help would be appreciated!

You need to create init.d script with correct format, at least with start function, see other scripts at /etc/init.d/
They have standard format with such functions: start stop status restart etc,.
And add to /etc/rc.d/ as well with proper filename, should have bigger value, such as S99.

And what /etc/rc.local?

Thanks, then I will try first rc.local again.

But my questions remain:

  1. I cannot do the same in a configuration instead of a script
  2. Can I “link” the script to the Wireguard up/down state instead of calling it at boot time?

Possibly the following information helps …

I have custom firewall rules defined in /etc/firewall.user which are (for whatever reason) not automatically applied when the firewall service starts along a reboot.

In /etc/cron.d I therefore created an addition file firewall-restart-reboot containing

MAILTO=""
@reboot root sleep 60 && /etc/init.d/firewall restart

to restart the firewall service 60 seconds after reboot. That solved the issue for me.

In a similar way you should be able to call your script.

if you want to add/remove additional rules by up/down state of the intefaces then you need to write a small application(c lang) where it will listen for certain network events. Btw wg interface already is brought up during boot, you need to find another event for wg state change.

For Debian like systems /etc/network is the custom scripting place for such network events, don’t know if similar with OpenWrt.

But that looks then like a bug?

I’m using the /etc/rc.local file for this. I have discovered I need to put sleep 10 as a first command and then as the second command the path to the script.

Nope, just a lack of information, I guess. You need to have in /etc/config/firewall something like this

config include
	option path	'/etc/firewall.user'

@hagrid Those two line do exist in /etc/config/firewall.

@hal2100 I don’t know, whether that’s a bug or not. The topic was discussed here [SOLVED] Apply Custom Firewall Rules Upon Reboot .

But this should be set by the UI, because you would use the UI to put in the script, no?

I agree about the additonal rules, of course, but not the one entered via the UI.

I tried this and it works, although I have no idea why this works now. Maybe the sleep command "fixes it.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.