Community discussions

MikroTik App
 
dalami
Member Candidate
Member Candidate
Topic Author
Posts: 134
Joined: Mon Dec 12, 2011 9:18 am

Non-service based mesh wireguard

Fri Apr 22, 2022 1:07 am

As the subject indicates - options such as Tailscale or Zerotier aren't what I'm asking about. This is actually more of a basic networking/routing question.

I presently have a physical office server with a static IP. Impressive I know. Additionally I have a subscribed cloud server. I'm playing with moving my services from the physical server to the cloud server - the cloud has a faster CPU, much faster internet, supposedly better backup. Less CPU cores & RAM since I'm not paying much. Anyway - that's the background.

Obviously a MT router (actually, more than one) in my office and I have Wireguard setup. I've also installed Wireguard on the cloud Linux server. I have a few remote sites or RoadWarriors including my Android phone.

Now - some more specifics. My office router WG IP is 10.1.1.1/24. The office LAN for workstations is 192.168.0.0/24. My various remote sites have 10.1.1.x/24 addresses.

I've set my cloud server to 10.1.1.10/24. My remotes & roadwarriors have both servers listed as peers. Because the internet connection is so much faster on the cloud server I want my RoadWarriors to use the cloud server as the gateway to the remote sites (other than the office of course). So I do that by setting the AllowedIPs and individually listing the remote sites as being on the cloud server's connection and the office LAN on the office server's connection.

This seems to work sometimes but not all times. So now I'm wondering - instead of having the two servers configured on the same 10.1.1.x/24 network do I need to have them on separate networks? And therefore if I want the remotes to communicate to both servers they will need two separate IP's for each? The final goal is transparent redundancy and fail-over with optimized speed.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Non-service based mesh wireguard

Fri Apr 22, 2022 9:05 pm

I would probably establish 3 wireguard interfaces in total
1 between remote sites and Cloud Server
1 between remote sites and MT server
1 between Cloud and MT device (mainly for the ADMIN in both directions to be able to config either device).
(this would allow , while at the MT device location (local) users to reach the cloud server subnets for work/internet and you the admin can config the Cloud server.)
(would also allow you to, if remotely connected to either, easily config the other without logging out and into the required server directly.)

The reason is you stated redundancy required, thus if cloud Server is down you still want to be able to reach MT Server and if MT server is down you still want to be able to reach Cloud Server.
If you make reaching one through the other the only method, then there is no redundancy.


Remote Site1 is >>>>>>>>>>>> needs access to which server, and for what , internet ? subnets on cloud service or MT router?
Remote Site2 is >>>>>>>>>>>> needs access to which server, and for what, internet? subnets on cloud device or MT router?
etc..
Remote SiteX is >>>>>>>>>>..


Is the intent to be able to config the Router via Wireguard from a remote site?
Is the intent to be able to config the Cloud Device via wireguard from a remote site.
 
dalami
Member Candidate
Member Candidate
Topic Author
Posts: 134
Joined: Mon Dec 12, 2011 9:18 am

Re: Non-service based mesh wireguard

Fri Apr 22, 2022 10:03 pm

So - from a routing standpoint, having two routers in the same network doesn't work? Or is that what policy-based routing is for?

I understand, I think, *how* to implement multiple networks as you described. So each remote is going to have two IP's? I just would prefer the elegance of a single endpoint IP for each that automatically implements a failover if one of it's routers is lost.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Non-service based mesh wireguard

Fri Apr 22, 2022 10:24 pm

I thought you were asking for Wireguard connectivity between sites, you seem to be talking failover routing????
 
dalami
Member Candidate
Member Candidate
Topic Author
Posts: 134
Joined: Mon Dec 12, 2011 9:18 am

Re: Non-service based mesh wireguard

Fri Apr 22, 2022 10:41 pm

Yes and yes.

So starting over - I have Wireguard setup now with two servers/routers and multiple remotes. I would like to be able to, from my remote, access any other remote and transparently use whichever server provides the optimum connection. Is this possible - preferably using a single network? Or does having two gateways to the same network break routing rules?

I'm running into problems doing this, so obviously there is an issue, I'm just not certain how much is Wireguard and how much is basic routing principles. The is probably the kind of thing I should be asking on a platform-agnostic netfilter forum if there was one (I know there used to be).
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Non-service based mesh wireguard

Fri Apr 22, 2022 10:50 pm

I personally dont think this is possible.
I think its viable for remote users to connect to one LOCATION SERVER, and then from there go to another SITE .

It gets tricky if any of your requirements involved INTERNET access as one may easily start overlapping peers for requirements.

My rule of thumb is that there is no reason to wireguard over two tunnels from A to B to C , if A can reach C directly!
In other words if both A and C (cloud server and MT device) are capable of being servers, there is no need for the complexity of relay.

Hence my suggestion.
WG interface 1 (all remotes to CLoud Server) WG network 10.10.5.1/24
WG interface 2 (all remotes to MT server WG network 10.10.10.1/24
+
WG interface 3 tunnel betweeen servers for whatever needs you define. WG network 10.10.20.1/24

How many interfaces is determined by detailed requirements.

Where relay make sense
Where A NEEDS to reach C but both cannot be servers!!! B then can be the SERVER and thus relay between multiple sites.
 
gdanov
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

Re: Non-service based mesh wireguard

Sat Apr 23, 2022 12:28 am

Yes and yes.

So starting over - I have Wireguard setup now with two servers/routers and multiple remotes. I would like to be able to, from my remote, access any other remote and transparently use whichever server provides the optimum connection. Is this possible - preferably using a single network? Or does having two gateways to the same network break routing rules?

I'm running into problems doing this, so obviously there is an issue, I'm just not certain how much is Wireguard and how much is basic routing principles. The is probably the kind of thing I should be asking on a platform-agnostic netfilter forum if there was one (I know there used to be).
WG doesn't have any sort of dynamic routing. It's 100% static. If I remember correctly (can't guarantee) routing decisions don't account for peer's status (connected or not). There is no failover out of the box. You'll need to look around, I've seen projects trying to address this and more. You'll also need to manually re-connect every now & then from the roaming device as the roaming does not work as one might expect after reading their doc.

You can build star or full graph topology with WG but it won't act as a mesh network.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Non-service based mesh wireguard

Sun Apr 24, 2022 3:00 am

Or does having two gateways to the same network break routing rules?
It "breaks" WG. Each peer has configured allowed addresses and it works as another routing layer inside WG. If peer A has allowed address 10.1.1.2/32 and peer B has allowed address 10.1.1.3/32, there's no problem. Even peer A with 10.1.1.0/24 and peer B with 10.1.1.3/32 works, same way as with regular routing, .3 will go to B and the rest from the /24 subnet to A. But you'd need allowed addresses 10.1.1.0/24 for both Office and Cloud, and that doesn't work (it will work for only one of them and you can't control which one).

Two WG interfaces solve this, only two different subnets are not great. But if it's for other subnets, e.g. if behing 10.1.y/z.x is another 192.168.88.0/24, it should be possible even with failover, although I'm not sure about all clients. RouterOS as client is fine, both peers can be active and you can have two routes with gateways 10.1.y.x and 10.1.z.x, different distances and check-gateway option. Linux can do the same, at least with manual config. With Windows I'm not sure.

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot], lurker888 and 68 guests