Protocol handler not working with firewall zone

[bluebb]

Hi,

I'm working on fixing issues with nebula-proto package. This package is a protocol handler for nebula vpn. Nebula works like this:

• config file specifies tun device name and other params to establish a successfull connection
• this config file path is specified in nebula protocol based interface in /etc/config/network
• protocol handler (source) grabs relevant info from config file and starts nebula -config path/to/config.yml (I know this is suboptimal, but not the actual issue right now); also the nebula-proto is using cfg name as interface name instead of grabbing interface name from yml config - I already fixed that in my build;
• nebula starts and creates a tun device using name from yml config file
• routes are added to tun device and OpenWRT device can successfully communicate with VPN network.

When we assign zone to this device like this to allow lan users to access vpn network:

config zone
        option name 'nebula'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'nebula1'
        option masq '1'

The rules for this zone are not added to nft. It looks like the nebula interface (the uci one we defined in network, not actual tun) is treated as not ready or down? The workaround is to use tun interface name and pass it via list device 'actual_tun_iface_name'. This works, but seems a bit dirty and unintuitive. Hence my questions:

• is it normal or there is some kind of an issue with the protocol handler itself?
• the handler is setting no_device=1 in proto_nebula_init_config() since there is no physical device available, right?
• when I query ubus call network.interface.nebula1 status the device is "up": false and "pending": true. I tried modyfing protocol handler to send "up" status by using proto_init_update with additional param: proto_init_update "${interface}" 1 1, but no success. Is this even relavant for this issue?

Thanks in advance

EDIT: I also tried doing proto_export INTERFACE="$config" with appropriate interface name, but this did not change anything

[bluebb]

For the reference: I figured it out