DietPi version
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=13
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘applied’
G_LIVE_PATCH_STATUS[1]=‘not applicable’
Distro version: bullseye
Kernel version : Linux DietPi 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux
SBC model: Virtual Machine (x86_64)
Power supply used: n/a
SD card used: n/a
Additional Information (if applicable)
Software title: PiVPN (Wireguard)
Was the software title installed freshly or updated/migrated? Install Freshly via dietpi-software
Can this issue be replicated on a fresh installation of DietPi? yes
Steps intended
sudo apt-get install bridge-utils
sudo brctl addbr br0
sudo brctl addif br0 eth0 wg0
sudo ifconfig br0 192.168.1.8 netmask 255.255.255.0 up
steps 1 & 2 appear to go fine.
if i execute ‘sudo brctl show’ i see on the screen the following two lines:
bridge name bridge id STP enabled interfaces
br0 8000.000000000000 no
it looks to me like the bridge has been added. so i want to confirm persistency across reboots and execute a ‘sudo reboot’.
after reboot when i execute ‘sudo brctl show’ i get a null response and am returned to the prompt
as i’m a noob i have no idea if it’s even reasonable to expect persistency at this point so i just continue with step 2 above and again - if i execute ‘sudo brctl show’ i see on the screen the following two lines:
bridge name bridge id STP enabled interfaces
br0 8000.000000000000 no
so i go for step 3 intended above and the i get the following on the screen:
can’t add wg0 to bridge br0: Invalid argument
Next thing i know ssh via putty is dead. So i go back to the phycial vmware console, login and run ‘sudo brctl show’. i now get back:
bridge name bridge id STP enabled interfaces
br0 8000.000000000000 no eth0
When I run an ‘ifconfig’, eth0 still has it’s original address
If i reboot it doesn’t have persistency and i can putty back in.
I have no idea if I’m even going about this the right way. I just want a mobile device to be able to vpn into my lab and exist as if it is a device on the local network. No firewall/router/natting in between the remotely connected client device and the local network. This way all 65535 ports can talk to the remotely connected mobile device. (Eg, NVR app on mobile device connecting to NVR using rtsp)
Humble humble thanks for anybody able to point me in the right direction. Really can’t find any solid documentation on my use case.
Hello again folks - I just wanted to expand a little more on my objective.
I have an iphone running an nvr client which works fine when connected to the same segment that an nvr resides on.
It appears as though the app/nvr are using rtsp over varying ports to deliver the security camera streams from the nvr to the app on the iphone.
I would like to have this same functionality when away from my home using my cellular data. As I cannot install anything on the nvr and am essentially limited to the ios app being able to see the nvr on the same segment, I am trying to setup a vpn bridge such that the ios device appears on the same segment as the nvr.
I am running a dietpi vm and have tried multiple iterations/permutations with no success. I have been told that wireguard should be able to accomplish this, but as in post above - I’m doing something wrong because i don’t have persistency or one thing breaks other things.
If I can get this up and running I will add a tutorial, but there just doesn’t seem to be a lot available along the lines of vpn bridging using dietpi and wireguard.
Another thing that would be helpful is a whitepaper perhaps on how dietpi’s networking is different from standard debian installations. I believe there are some scripts running and locations which are different from say a standard install of raspbian, but again I haven’t found a table or documentation listing changes and methods used.
Humble humble thanks and appreciation again for all the amazing work on this project and of course anyone who has time to point me in the right directions.
There are no DietPi script running in the background to configure or run the network. It’s standard Debian configuration as we use /etc/network/interfaces for configuration and ifupdown to manage network interfaces.
ifconfig/net-tools is btw deprecated since a long time. Use ip/iproute2 instead.
Can you check how brctl actually sets up the bridge? It has hooks in /etc/network/*.d directories, so it should generally work with ifupdown. But where does it store the interface configuration for the bridge? It might conflict with the default eth0 config in /etc/network/interfaces itself.
And why are you actually using a bridge? Isn’t IP forwarding working for you to enable VPN clients to access the LAN without a bridge? This is at least the way we do it usually. But probably a bridge has some benefits, not sure.
I’m not sure that building a bright using a VPN interface will work. Because the VPN interface will need to be up before the bridge is able to start. As well traffic of the VPN interface will typically forward to the Ethernet adapter.
The forwarding of incoming VPN traffic could/would then need to be skipped, of course and is also then not necessary to access the LAN, if it generally works.
Generally, the VPN server can start up without any network/internet access, right? Does wg-quick wait for any network target?
systemctl cat wg-quick@.service
Can it bind to a port on 0.0.0.0 as long as eth0 has not been configured at all?
Regarding eth0, I think it would need to be configured this way:
auto eth0
iface eth0 inet manual
So the interface is up but not configured (leaving this for the bridge). wg-quick@<name>.service would need to start before network.target, or otherwise ifup@br0.service (depending on how it is setup) started after wg-quick@<name>.service, or the bridge even brought up manually after WireGuard, with a dedicated service or PostUp = ifup br0 the WireGuard config.