TOC
Yes Yes Diagrams I KNOW I KNOW, I’m working on it :)
The wireguard network will use a random selected address space within 172.16.0.0/16 actual size is undetermined for now. Operational services required for dynip, dns etc will be hosted by me with public access where required for the operation of the network. These will have a specific range.
The whole concept of a mesh network is that all endpoints are aware of every other endpoint. So a static public IP is a requirement for proper participation. Everyone will be assigned a static wireguard IP as their endpoint from the above pool.
As far as dynamic clients goes its a bit more muddy at the moment. I’m not entirely sure if they can plugin easily and directly into the mesh network. That is something that will require testing.
I do how ever see a couple of solutions. For one, a lot of us have hardware that support wireguard endpoint at the router, which allows for doing proper layer 3 routing into the mesh network. It’s almost a given that a lot of us have some kind of home vpn configured. I this case I would suggest simply routing from your mobile device -> vpn home -> router -> mesh network This also needs further testing, but it’s a configuration I already use to an extend, and with some modification to the addressing it should work just fine for accessing the mesh network.
I know of at least one user that is using a ghastly mobile internet connection and there for does not have any of the capabilities listed above.
Here I think it would be easiest to create an adjacent network with a predictable pool of IPs and just let the cloud opnsense instance do the actual routing into the mesh network. This seems pretty straight forward and would allow people mobile access from the outset, while we work on adapting the above.
These are in no way final. I’m very much still working out the routing of all of it.
This is all about the actual network routing, ideally we should end up with a /24 space handed out to anyone planning on hosting anything with the mesh network. I’ve decided on /24 because it’s what everyone is used to from their home networks and I assume that most people will only ever need the one network. If you need more I’ll make a take to refer to so it’s easy to adapt.
It’s still undetermined if it’s possible to have the actual wireguard mesh endpoint IP be part of the same /24 subnet. This would reduce the routing required considerably because any client in the network does not care about how many network segment the /24 network has been segmented into. All it case about is that it knows all traffic within that /24 address space is going to one specific mesh network IP.
Single PC users should get a /32 address in a reserved range, any services they provide must be hosted on the client PC.
Just a bulletpoint list for now, this is mostly notes for after the subnetting is done.
Goal is to have full local dns for the entire mesh network, this can include a public subdomain of the to be chosen public domain.
We could run a joint acme ca if there is interest, otherwise i’ll just keep using my internal one.
I should mention that i’ve already tested port forwarding from a cloud router via wireguard into my own home network. This is a possibility should there be a special use case or a service so valuable that we need to open public access. Probably have a talk about this later.
I’m going to pin a domain on it eventually, but for now that is undecided especially taking into account mail server requirements. The IP in question does support reverse dns.
This is merly kept here for reference now.
Over all we will be using the 172.16.192.0/18 space for this network
This can further be subdiveded into 16 blocks of /22
Network Address|Usable Host Range|Broadcast|Reserved for
----|-----|-----|----
172.16.192.0|172.16.192.1 - 172.16.195.254|172.16.195.255|test
172.16.196.0|172.16.196.1 - 172.16.199.254|172.16.199.255|
172.16.200.0|172.16.200.1 - 172.16.203.254|172.16.203.255|
172.16.204.0|172.16.204.1 - 172.16.207.254|172.16.207.255|
172.16.208.0|172.16.208.1 - 172.16.211.254|172.16.211.255|
172.16.212.0|172.16.212.1 - 172.16.215.254|172.16.215.255|
172.16.216.0|172.16.216.1 - 172.16.219.254|172.16.219.255|
172.16.220.0|172.16.220.1 - 172.16.223.254|172.16.223.255|
172.16.224.0|172.16.224.1 - 172.16.227.254|172.16.227.255|
172.16.228.0|172.16.228.1 - 172.16.231.254|172.16.231.255|
172.16.232.0|172.16.232.1 - 172.16.235.254|172.16.235.255|
172.16.236.0|172.16.236.1 - 172.16.239.254|172.16.239.255|
172.16.240.0|172.16.240.1 - 172.16.243.254|172.16.243.255|
172.16.244.0|172.16.244.1 - 172.16.247.254|172.16.247.255|
172.16.248.0|172.16.248.1 - 172.16.251.254|172.16.251.255|
172.16.252.0|172.16.252.1 - 172.16.255.254|172.16.255.255|
We are going to assign blocks of /22 to each peer regardless end user count
* Allows for expansion without modifying any configs
* Simplifies wireguard configuration each peers allowed networks is a /22 block
* Running containers, this configuration allows us to setup our own routing and assign a network for containers to be directly available within the wireguard network
### Wireguard NIC IPs ###
Name|Network|Comment
----|--|-------
Bob's Cloud|172.16.200.0/22|Probably too small for running the backbone services|
Bob's Home|N/A|TBA
Reverie|N/A|this was added as a test
Last modified: Tue Jan 14 17:31:14 2025