1
23.1 Legacy Series / Dealing with (point-to-point) interfaces generated by non-plugins
« on: June 11, 2023, 02:59:21 pm »
I'm a bit confused here.
Goal: Add SlackHQ/Nebula (final goal: set it up as lighthouse and router) to OPNSense.
First obstacle: OPNSense is ignoring tunx (for very good reasons, but there is no way to override it)
Obstacle 1.5: Nebula insists on using tun* interfaces with fixed names in its configuration. Remedied by modifying the code a bit. Nebula also does not destroy an interface before quitting or trying to use it. If you put a shell script renaming an interface after creating it, nebula will fail to (re)start.
Now I'm ending up with interfaces nebulaX like
and OPNSense is at least recognizing them:
https://router.rhb.bnc.net/status_interfaces.php shows it as
(wait... didn't ifconfig claim it was a POINTTOPOINT -- what is the MAC address doing there and where iis the /24 netmask coming from?)
So: Is there a way to mark this as general purpose point-to-point interface inside OPNSense or is that not even necessary? Nebula is carrying rudimentary firewalling capabilities as part of client configuration and authorization as part of the authentication material (a certificate) that will restrict routeing but I would have liked adding this information to OPNsense even if it is just for reference and there are a few other new VPN/mesh tools out there that are intended to let the endpoint make routing decisions. In these cases it would be necessary to assign addresses by the user (i.e. OPNSense) and deal with the routing table, too.
Achim
Goal: Add SlackHQ/Nebula (final goal: set it up as lighthouse and router) to OPNSense.
First obstacle: OPNSense is ignoring tunx (for very good reasons, but there is no way to override it)
Obstacle 1.5: Nebula insists on using tun* interfaces with fixed names in its configuration. Remedied by modifying the code a bit. Nebula also does not destroy an interface before quitting or trying to use it. If you put a shell script renaming an interface after creating it, nebula will fail to (re)start.
Now I'm ending up with interfaces nebulaX like
Code: [Select]
nebula0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1300
options=80000<LINKSTATE>
inet 172.31.255.3 --> 172.31.255.3 netmask 0xffffff00
inet6 fe80::4e52:62ff:feb9:5bb6%nebula0 prefixlen 64 scopeid 0x10
groups: tun
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
Opened by PID 46890
and OPNSense is at least recognizing them:
https://router.rhb.bnc.net/status_interfaces.php shows it as
Code: [Select]
Unassigned interface (nebula0)
Status up
MAC address 00:00:00:00:00:00 - XEROX CORPORATION
MTU 1300
IPv4 address 172.31.255.3/24
IPv6 link-local fe80::4e52:62ff:feb9:5bb6/64
In/out packets 0 / 2 (0 bytes / 232 bytes)
In/out packets (pass) 0 / 2 (0 bytes / 232 bytes)
In/out packets (block) 0 / 0 (0 bytes / 0 bytes)
In/out errors 0 / 0
Collisions 0
(wait... didn't ifconfig claim it was a POINTTOPOINT -- what is the MAC address doing there and where iis the /24 netmask coming from?)
So: Is there a way to mark this as general purpose point-to-point interface inside OPNSense or is that not even necessary? Nebula is carrying rudimentary firewalling capabilities as part of client configuration and authorization as part of the authentication material (a certificate) that will restrict routeing but I would have liked adding this information to OPNsense even if it is just for reference and there are a few other new VPN/mesh tools out there that are intended to let the endpoint make routing decisions. In these cases it would be necessary to assign addresses by the user (i.e. OPNSense) and deal with the routing table, too.
Achim