After you create the interface, it should be visible in LuCI under Network->Interfaces.
1 Like
How do I create the interface? I don't see any new interface type, only the usual ones (DHCP/static/PPP/unmanaged/Wireguard).
Have you restarted the router since you've installed luci-proto-nebula?
PS. Looking at the other threads, a service network restart may be sufficient for system to pick up the new protocol.
Thanks, a reboot did it. I had tried restarting uhttpd but that wasn't enough.
Is there a recommended way to restart Nebula after changing the config? The restart button in LuCI doesn't seem to do anything, but I also need a way from the command line. Just killall -HUP nebula?
If using nebula-proto, same way as any other interface should work. I was planning to improve netifd support but didn't have the time/knowledge to do it before I stopped using nebula.
I think the other way is with ubus. However since restarting nebula from LuCI doesn't work I guess it won't work from ubus either. However I'm looking for a graceful reload rather than a restart so the killall -HUP is better anyway.
Thanks for your help!
I found that when using the protocol integration, the device was never actually added to the configured firewall rules - as viewed with nft list table inet v4 - even though the interface was in the firewall zone.
Instead I used an unmanaged interface containing the nebula device, with nebula-service, and the rules are added OK. This is how I run my former TINC network interface too as TINC has no protocol integration.
1 Like
Probably due to:
As in, the netifd support is incomplete.
I'm glad the service option is working for you. If you're interested in continuing using nebula on OpenWrt, do consider becoming the maintainer.
1 Like
I have recently found Nebula and well, that's a bit of letdown 
I found some issue working with firewall zones using the proto package, so instead I am using the nebula-service.
I create an interface with static ip, is assigned to the device created by nebula and the static ip is inserted manually.
I have no issues for now, I guess if I need new versions I would just get the precompiled binary for my arch.
You're welcome to take over maintainership of the package so it doesn't get deleted.
It's not just me who quite maintaining OpenWrt packages over toxicity tho.
Thanks @stangri for this cool package! I discovered how to make the nebula-proto work with firewall. The issue is that if you configure a zone for nebula proto interface you add the interface via list network 'nebula1' (or whatever your nebula tun device is called). I assume firewall either this device is unmanaged or down (it reports "up": false, "pending": true, "available": true via ubus call network.interface.nebula1 status) and no rules are applied. However you can bypass this by using list device 'nebula1' - this config is used with unmanaged devices and works.
I tried various approaches by modifying /lib/netifd/proto/nebula.sh like using proto_export INTERFACE="${interface}" or adding additional param for 'up' to proto_init_update: proto_init_update "${interface}" 1 1, but it does not fix the problem. Writing protocol handlers is basically undocumented so I'll ask around developer forum - perhaps someone will point the error out. I already inspected other packages that implement custom protocol handlers including net/external-protocol/files/external.sh which seems to be a template on which nebula-proto was based. I tried tinkering around a bit, but there does not seem to be any notable difference in those implementations 
1 Like
Ok, I got it mostly figured out somehow nesting stuff inside proto_init_update broke the notification to ubus. I wrapped only addresses handling in proto_init_update. I also added sleep before the init to make sure the nebula interface is actually up. This is a dirty fix, but I'll rewrite whole proto over the weekend so one could configure more stuff from uci 
The change also requires to manually add routes for some reason - I've done this only for ipv4, since it's a dirty fix at the moment. Tearing down of routes happens automatically I also take ifname from nebula config, not use the interface name from uci.
Fixed code:
proto_nebula_setup() {
local cfg="$1" interface config_file address addresses
local yaml_listen_host yaml_listen_port yaml_tun_dev
config_load network
config_get config_file "${cfg}" "config_file"
[ -s "$config_file" ] || { log "Config file not found or empty!"; return 1; }
eval "$(yaml_parse "$config_file" "yaml_")"
local interface="${yaml_tun_dev%"${yaml_tun_dev##*[![:space:]]}"}"
#[ "$yaml_tun_dev" = "$interface" ] || { log "Tunnel device in config file (${yaml_tun_dev}) doesn't match interface name (${interface})!"; return 1; }
log "Setting up ${interface} from $(basename "$config_file")."
proto_run_command "$cfg" "$PROG" -config "$config_file"
sleep 2
proto_init_update "${interface}" 1
addresses="$(ip -4 a list dev "$interface" 2>/dev/null | grep inet | awk '{print $2}' | awk -F "/" '{print $1}')"
log "Running ${interface} from $(basename "$config_file")${addresses+: with addresses: $addresses}."
for address in ${addresses}; do
case "${address}" in
*:*/*)
proto_add_ipv6_address "${address%%/*}" "${address##*/}"
;;
*.*/*)
proto_add_ipv4_address "${address%%/*}" "${address##*/}"
local subnet=$(ipcalc.sh "${address%%/*}/24" | grep NETWORK | cut -d= -f2)
proto_add_ipv4_route "${subnet}" "24" "${address%%/*}"
;;
*:*)
proto_add_ipv6_address "${address%%/*}" "128"
;;
*.*)
proto_add_ipv4_address "${address%%/*}" "32"
local subnet=$(ipcalc.sh "${address%%/*}/24" | grep NETWORK | cut -d= -f2)
proto_add_ipv4_route "${subnet}" "24" "${address%%/*}"
;;
esac
done
proto_send_update "${cfg}"
}
1 Like
@bluebb outstanding progress, please adopt the package when you send the PR for updated proto handler.
1 Like
Hi,
Are the changes in OpenWRT 24 yet?
I'm trying to have a lighthouse on my router and it's been harder than expected.
I wrote a simple nebula service because I could not figure how stuff works, but I don't have firewall working.
I just run nebula -config ... From an init script so I don't have service status or firewall.
I've got nebula ping working by adding a firewall zone for the device.
In my case , the nebula tun device is called dava1 .
This was after I've made time to read the documentation https://openwrt.org/docs/guide-user/firewall/firewall_configuration and understood what I have to do.
config zone
option name 'dava1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list device 'dava1'
list network 'lan'
list network 'podman'
config forwarding
option src 'dava1'
option dest 'lan'
config forwarding
option src 'dava1'
option dest 'podman'
config forwarding
option src 'lan'
option dest 'dava1'
config forwarding
option src 'podman'
option dest 'dava1'
my nebula service is - but it seems to not start with OpenWrt - so I am investigating this.
cat /etc/init.d/dava1-nebula
#!/bin/sh /etc/rc.common
START=90
STOP=95
start() {
cd /etc/nebula
/usr/sbin/nebula -config config.yml &
}
stop(){
echo "Killing nebula"
killall nebula
}
It seems that nebula-proto works - but I did not know how to set it up.
It seems that once you have nebula-proto package, you need to copy to a directory (I used /etc/nebula ) the files:
- ca cert
- device cert and key
- nebula config.yml file
The tun device name in config.yml file needs to match the name in the interface.
( images bellow show different device / interface names: neb1 and dava1) .
You can see info in the logs, for debugging.
