Policy Based Routing service not starting

Installing and Using OpenWrt Network and Wireless Configuration
1

I am trying to install an implement policy based routing, but the PBR service does not start. I have installed dnsmasq-full and I have set procd_boot_trigger_delay to 50000. There is no file /var/run/pbr.nft. The referenced documentation does not provide insight.

I am using a Gl.inet MT3000 and am using a wireless wan. The following messages are in the system log when starting the service manually:

Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: Using uplink interface (on_start): wan [✓]
Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: Processing environment (on_start) ERROR: Uplink/WAN interface is still down, increase value of 'procd_boot_trigger_delay' option!
Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: Setting interface trigger for wan [✓]
Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: Setting interface trigger for wan6 [✓]
Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: Setting interface trigger for wwan6 [✓]
Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: Setting interface trigger for wwan [✓]
Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: Setting interface trigger for tun0 [✓]
Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: Setting interface trigger for home_wg [✓]
Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: pbr 1.2.0-r6 FAILED TO START in fw4 nft file mode!!!Check the output of nft -c -f /var/run/pbr.nftERROR: The pbr 1.2.0-r6 service failed to discover WAN gateway!
Sun Jan 11 15:44:13 2026 user.notice pbr [5051]: ERROR: Errors encountered, please check https://docs.openwrt.melmac.ca/pbr/1.2.0/#ErrorMessagesDetails!
2

The error is self explanatory.

You either did not specify the correct wan interface or it is still down.

You mentioning wwan it is probably the first.

See the manual

3

I wish it were that straightforward. The wwan interface is up, and I am using this router with the wwan to send this reply! The service fails to start. Here is the latest sequence of messages from the log.

Mon Jan 12 13:25:33 2026 user.notice pbr [16573]: Using uplink interface (on_start): wan [✓]
Mon Jan 12 13:25:33 2026 user.notice pbr [16573]: Processing environment (on_start) ERROR: Uplink/WAN interface is still down, increase value of 'procd_boot_trigger_delay' option!
Mon Jan 12 13:25:34 2026 user.notice pbr [16573]: Setting interface trigger for wan [✓]
Mon Jan 12 13:25:34 2026 user.notice pbr [16573]: Setting interface trigger for wan6 [✓]
Mon Jan 12 13:25:34 2026 user.notice pbr [16573]: Setting interface trigger for wwan6 [✓]
Mon Jan 12 13:25:34 2026 user.notice pbr [16573]: Setting interface trigger for wwan [✓]
Mon Jan 12 13:25:34 2026 user.notice pbr [16573]: Setting interface trigger for tun0 [✓]
Mon Jan 12 13:25:34 2026 user.notice pbr [16573]: Setting interface trigger for home_wg [✓]
Mon Jan 12 13:25:34 2026 user.notice pbr [16573]: pbr 1.2.0-r6 FAILED TO START in fw4 nft file mode!!!Check the output of nft -c -f /var/run/pbr.nftERROR: The pbr 1.2.0-r6 service failed to discover WAN gateway!
Mon Jan 12 13:25:34 2026 user.notice pbr [16573]: ERROR: Errors encountered, please check https://docs.openwrt.melmac.ca/pbr/1.2.0/#ErrorMessagesDetails!
4

Is the PBR service only checking for the wan interface?

5

Then you have only one option left. As said earlier,

You need to specify it in the configuration with option uplink_interface

From the docs:

Name of the upstream IPv4 interface (logical interface name). Defaults to wan . Use this option if your WAN interface has a different name.

1 Like
6

Hmmm. This device is a travel router, so the interface to the Internet could be either the wan interface or the wwan interface. Does this mean that the “option uplink_interface” needs to be changed each time the Internet interface changes between those two?

7

I think so. Perhaps you can create a hotplug script that detects the uplink and changes the PBR config.

1 Like
8

I have gotten to work on creating a hotplug script. Before getting too far into that, I decided to test the commands the script would run when either the wwan or wan interface comes up. For this experiment, I know the wwan interface is connected. From SCP, I executed the following three commands simulating what the hotplug script would do for the wwan.

uci set pbr.config.default_interface="wwan"
uci commit pbr
/etc/init.d/pbr reload

Same error messages. Could not find wan interface. I confirmed that the default_interface option was set to wwan in the config file after the commit. Were these commands the wrong thing to do?

9

Wrong option?

10

Made good progress. Yes, default_interface was not the only option to set. Needed to also set uplink_interface. Hogplug script runs fine, so moved to creating the needed to policy to send all traffic for one device through the wan or wwan (whichever is connected). Have a problem here.

Through uci, I can set the appropriate interface name to wan or wwan using:

uci set pbr.@policy[4].interface=”wwan”

Using this syntax has a disadvantage because what if rules above [4] are deleted, blah-blah-blah. Would prefer to use

uci set pbr.AsusTest.interface=”wwan”

but this fails with an invalid argument. AsusTest is the correct policy name as confirmed with

uci show pbr

I think I will be finished once this is solved. Any thoughts?

11

There is a difference between a policy name and an uci section name.

uci rename pbr.@policy[4]='AsusTest'

https://openwrt.org/docs/guide-user/base-system/uci#sections_naming

1 Like
12

uci show pbr will show you what is present

13

Side fun fact. You can use this to spot and find uci syntax errors before trying to apply them.

1 Like
14

I am still somewhat of a noob to Openwrt and did not understand that distinction.

Seems like the luci-app-pbr package could use an improvement. The web interface it provides has a “name” field, but that name is not applied to the section name. It applies it only to the poilcy name option of the policy. Because of that, one muar use ssh to manually add the section name. What do you think?

15

This is not related to luci-app-pbr.

Every time you use LuCI to create an entry (no matter an ip rule/route in /etc/config/network, a firewall rule in /etc/config/firewall or something else), you create a so called "unnamed" section.

Such a section can be addressed by uci only if you use its sequence number, which, as you noticed, may change.

So yes, you need to use ssh to name the section.

Use the provided command or edit the config file manually.

An unnamed section example:

root@MikroTik:~# cat /tmp/pbr
config policy
        option name 'MyTestPolicy'
        option interface 'wan'
root@MikroTik:~# uci -c /tmp/ show pbr
pbr.@policy[0]=policy
pbr.@policy[0].name='MyTestPolicy'
pbr.@policy[0].interface='wan'

A named section example:

root@MikroTik:~# cat /tmp/pbr
config policy 'MyTestPolicy'
        option name 'MyTestPolicy'
        option interface 'wan'
root@MikroTik:~# uci -c /tmp/ show pbr
pbr.MyTestPolicy=policy
pbr.MyTestPolicy.name='MyTestPolicy'
pbr.MyTestPolicy.interface='wan'
16

Just create all rules with LuCi and disable those.

Then enable/disable the rules per hotplug script

17

Yup, I have been doing that and it works well.

18

Sounds like a great candidate for automation so it does not have to be remembered by every user. I confirmed that if one deletes a policy rule, all the section names become incorrect.

19

Clarity, all the section names below the one deleted become incorrect.

20

This would work, but for what is needed, just setting the interface for the policies that specify the WAN interface avoids duplication and is straightforward to do. Having all the rules that could be needed would result in duplicated rules for all intents and purposes. Future mods would have too much opportunity to miss something.