Oh... I'm sorry. Let me move this back to original thread.
1 Like
@nbd - I finally tried out your unetd implementation. Could not get it to work.
Working through the documented example (which I filled out a bit more in the wiki), it raised questions. One:
Is key generation of a new host you add supposed to be idempotent? It seems like the same (public) key is always generated for the same IP, when running e.g.
unet-cli test.json add-ssh-host ap1 root@192.168.1.13 endpoint=192.168.1.13 tunnels=vx0:l2-tunnel groups=ap
So if I knew this maintenance IP that you use to add a host to your network, and your port, I can derive your key and auth_key... and join your network? Or does this depend on some locally generated master key? Does not seem right.
Was (dns) hostname capability added to the connect parameter? Or must bootstrapping be done via IP still?
Edit: it would be nice if unet-cli could be a bit more verbose during setup, about what its subshell on remote hosts is doing. Also nice if unet acquires abililty to check for dependencies on remote hosts, and try to install e.g. unetd, unet-cli, vxlan etc if they are absent.
1 Like
@nbd great project! I'm running with 4 peers without public IP address and 1 with public ip. It's a very good alternative to netmaker and netbird, since the package size it's large.
Exist a command that reload unet port lookup? Sometimes, one or more peers doesn't work anymore, and demands a reboot to work again.
I am unable to sign and upload the configuration, when following the documentation:
unet-cli test.json sign upload=192.168.200.1
Uploading test.json.bin to 192.168.200.1
Upload failed
I set up three openwrt devices, one just to work as the localhost in the example, so to create and upload the config, and two routers that are the ones I want to be connected via unet.
openwrt-deploy has no lan and 192.168.200.3 as wan
openwrt-1 has lan 192.168.1.1 and wan 192.168.200.1
openwrt-2 has lan 192.168.1.2 and wan 192.168.200.2
- I opened port 51830 and 51831 UDP on both routers wan interface ( openwrt-1 and 2 )
- I opened port 22 ( ssh ) on both routers
- I can ping and ssh between their wan network ( 192.168.200.1, .2, .3 )
I ran the following commands from the router that deploys the conf to the other two:
unet-cli test.json create
unet-cli test.json add-service l2-tunnel type=vxlan members=@ap
unet-cli test.json add-ssh-host openwrt-1 root@192.168.200.1 endpoint=192.168.200.1 tunnels=vx0:l2-tunnel groups=ap ( asks for root pass )
unet-cli test.json add-ssh-host openwrt-2 root@192.168.200.2 endpoint=192.168.200.2 tunnels=vx0:l2-tunnel groups=ap ( asks for root pass )
after this I can see that both routers have the /etc/config/network configured with the unet interface.
I then try to run this to upload the config and sign and it fails with the upload failed error.
unet-cli test.json sign upload=192.168.200.1
my end goal is to bridge both lans over the tunnel, so that I extend the l2 network from one router to the other. I am already doing this with wireguard, vxlan and stp across several nodes, but I am running into mtu issues and would like to see if unet solves them.
also unet is easier to maintain.
please help.
I was able to figure out the issue with tcpdump running on 192.168.200.1. the upload happens over port 51819 udp.
The unet interface is up and running on both routers, but no vxlan interface. vxlan kernel module and package and luci-proto-vxlan are installed.
I'm guessing the documentation is wrong and there is something missing to get the vxlan interface configured and running.
hope someone can help.
@nbd ?
Great project! With BPF integration, i'm feeling an performance improvement above vanilla wireguard.
But, i'm have a issue: to get unet interface works i'm need to open input rules, setting to default accept.
There is another solution that i'm doesn't need to open all input ports from router?
how do you know BPF is working?
For me it isnt even after enabling LLVM toolchain build in openwrt build config and ticking unetd VXLAN support ( need to enable LLVM for this option to appear )
I still have the same problems with MTU that I had with my previous VXLAN over Wireguard configuration. I replaced that for unet thinking the MTU issues would be over but it's exactly the same thing minus a proper integration into Luci.
also the default ports you need to open are 51819 51830 and 51831 UDP
@nbd
If you care about this:
MTU issues with VXLAN unet tunnels.
- LLVM toolchain build enabled on build options
- VXLAN support ticked on unet build options
- unet interface with MTU 1420 and vx0 interface with MTU 1350 up on both devices
- vx0 interface on both deviced bridged with br-lan
- br-lan on both devices has the same /16 network, each with a different IP address on this network
- traffic goes trough the vx0 interface and everything seems like the same L2 network
BUT:
- hosts connected to that br-lan network on both sides cannot comunicate except when the MTU's of their network cards is set to 1350 or bellow
OR: - I do ifconfig unet MTU 1570 and ifconfig MTU vx0 1500 on both devices
- this also makes it work without any MTU issues.
- My problem is that if I specify the MTU of unet and vx0 devices on /etc/config/network it doesn't work. It only works if I do it manully on the cli.
I would think you added BPF to fix the MTU issue but I can't see now BPF is running.
A tcpdump of traffic shows that hosts on oposite sides of the tunnel negotiate mss at 1460 ( MTU 1500 ) without taking into consideration that there are devices in the path that have lower MTUS ( 1420 for unet and 1350 for vx0, so lower is 1350 ).
I ended up fixing my link by going back to my Wireguard+VXLAN setup and setting the MTU of the wireguard interface on both ends to 1550. With this change, the VXLAN MTU is set automatically to 1500 and no more MTU issues.
I would say that being able to configure the unet MTU value via unet-cli would make it work as well as a wireguard+vxlan setup.
notice that the wan device that the wireguard tunnel uses to send packets has an MTU of 1500 so there will for sure be alot of fragmentation, but it's better to have fragmentation than to have no solution.
I got it to work it looks very nice 
The vxlans also work, but not the way how i expected i had to make sure to tag without bridge filtering to make extra sure 
but i wonder this is correct right with bridge filtering (vx0 bridged with lan) if i want to mix 802.1q with vxlan?
and the same on the other side?, or can 802.1q not mix well with vxlan this way?