There's many topics on this, but none of them have helped me.
I've created a wireguard interface and set it up and I'm successfully connecting to it from a mobile phone from the internet, and the phone can access the internet through wireguard, and the internet sees the phone coming from the (public) IP of eth5.
However, the mobile phone cannot access 10.11.12.1 (device 1) on the LAN.
Here is my setup (although disabled VLAN 9 until I get VPN to work):
I have not looked to everything but it looks like your WG address is inside the LAN subnet
WG is a routed solution and needs three different subnets, the servers subnet, WG subnet and the clients subnet all have to be different to route properly
It's a linux box, as is 10.11.11.2, which also can't be accessed via the VPN. Apparently the DHCP was serving out a /8 mask to LAN devices (including 10.11.12.1). That setting seems to not be present in luci, but I did find it in /etc/config/dhcp and I've changed that with uci now to /16. Now at least 10.11.12.1 responds to pings. Hmm..
Can we see the DHCP file since clearly something is unusual.
As an aside, why are you using such large subnets (/16)? Why not use more standard /24s? It even looks like you have an IoT range that is part of your trusted LAN... it is usually considered better to put them on their own subnet, unless you can't due to mdns or other non-routable type traffic that is required for connectivity from the lan.
Just to make it easy to group and/or filter them. E.g., 1.11.11.x are statically configured, and other 1.11.x.y are DHCP-assigned. 1.11.10.x are infrastructure, 1.11.0.x are unsafe (maybe these should have their own subnet and not just their own VLAN), 1.11.12.x are normal devices, etc. I guess I could make multiple /24s instead, but that seemed like more config work.
Yes, well, that's going into its own VLAN in any case once I have the VPN sorted out.
I'd recommend actually doing this first. Use /24's (which are just easier to work with at a human level). Get all these networks functioning properly, and then do the WG VPN.
Why are you saying that? How should they be configured? Since I anyway need to do separation by VLAN, what benefit would I have to also make multiple virtual interfaces?
A /24 network is a nicely "human readble" subnet size insofar as the first 3 octets define the network, and the last octet is the host...
for example:
For a /24, 10.0.10.0/24 -- the bold part defines the network -- very easily to discern visually. The last octet, ranging from 1-254, is for the hosts. The 0 address is not valid as it forms the overall subnet ID 10.0.10.0/24, and the 255 address is the broadcast.
This is a sufficient size network to contain most normal home networks (especially when this is actually one of a few subnets being used), while keeping the network efficient (more than ~500 or so devices starts to become less efficient due to the amount of broadcast traffic).
VLANs and multiple interfaces go hand in hand -- without multiple interfaces, there's no practical use for VLANs (it could be argued that there are uses, but I'm just talking at a practical level the way most people plan to use VLANs, including your scenario).
So, for example, you might have VLANs like this:
VLAN 1 - main trusted LAN; 10.0.1.0/24
VLAN 5 - camera network; 10.0.5.0/24
VLAN 10 - IoT network; 10.0.10.0/24
VLAN 20 - Guest network; 10.0.20.0/24
Each VLAN has an associated network interface stanza (technically, VLANs are actually just an L2/switching concept with 802.1q tags to keep the traffic flows separate; it is the multiple subnets that are often assigned to VLANs to make the whole thing practical; in every day language, we use the term VLANs very loosely to imply multiple subnets, but multiple subnets are possible without VLANs and VLANs are possible -- but not terribly useful -- without subnets).
While there can be uses for larger networks than /24 (but in that case you need to be very much on top of netmasks to get all the details right), you will encounter quite a few bugs[*] and unmet expectations from proprietary clients - so really, stick to /24 unless you really know what you're doing and why.
(*) just off the top of my head:
not working at all in a > /24 subnet
not being able to accept x.y.z.0 as a client address in a >> /24 subnet
not finding the broadcast address
even in a > /24 subnet only 'seeing' the first x.y.z.[1-254] devices/ addresses
many other subtle issues
Especially with consumer devices, vendors never test anything other than /24, accordingly you will be the first to find bugs.
And those are on 4 different virtual interfaces, right? Should I make 4 new static (virtual) interfaces on the br-lan device, or how should they defined?
And again, why have 5 interfaces instead of just one, like:
VLAN 1 - main trusted LAN; 10.0.1.0/16
VLAN 5 - camera network; 10.0.5.0/16
VLAN 10 - IoT network; 10.0.10.0/16
VLAN 20 - Guest network; 10.0.20.0/16
and all are on the same interface.
What's the benefit of having multiple virtual interfaces instead, besides you thinking the last ip octet is easier to see than the last 2 octets? (Mind you, I'd be happy with even /12 or somesuch, because I'm quite comfortable with bitmasks.)
Yes, although I would just call them "interfaces" (not virtual interfaces) for clarity.
The VLANs (i.e. the L2/switching part of the equation) are defined as bridge-VLANs. Those bridge VLANs are then used as the 'device' for the network interfaces.
Because one interface means that there is no separation, and you cannot use VLANs.
Right those are all on the same interface. But it means you cannot create any separation. A /16 is massive (can handle 65K hosts) with zero separation capabilities. Think of it like a concert where you have just one type of admission -- general admission for all 65K people. Also, as @slh pointed out, devices might not work properly with large subnets.
Quite simply, multiple interfaces means that you can create networks that are isolated from others and/or that have specific rules allowing and/or prohibiting access across the networks (typically known as inter-VLAN, inter-subnet, or simply inter-network routing; at a much larger scale, the internet is actually short for 'inter-network'). Those rules can be as broad/simple or granular/complex as you desire. For example, maybe you want your IoT devices to be unable to connect to any device on your trusted lan, but your trusted lan can connect to the iot devices. Maybe you want to have a guest network that has internet access only, but no ability to connect to your IoT or trusted lan... except maybe you want to be able to share a printer that sits on your trusted lan. These types of things are only possible with multiple interfaces.
For the reasons @slh mentioned, it is often good to stick with /24 networks. Besides, simplifies everything so you're not even thinking about bitmasks or the math of the network addresses. I'm also comfortable with bitmasks and binary/octal math, but I love working with /24 networks just makes it so much less error prone and so immediately obvious what is going on (for example, I can connect to any one of my VLANs and look at the 3rd octet -- immediately I know what network I'm on, and I don't have to do any bitmask operations).
Agreeing on the /24 subnets but want to come back on the original question
Make sure that the box you want to reach on your subnet allows traffic from WireGuard (10.16.1.0/24).. The firewall on that box will usually allow only local traffic and not traffic from the WG subnet
