Hi @rawfuls 

Thanks for posting in our business forum.

Seen someone on Reddit who has pasted you the correct link for the config. You might wanna retry the guide.

I don't iterate what's been explained by the user on Reddit. Basically, he's on the right direction.

Hi @rawfuls 

Thanks for posting in our business forum.

rawfuls wrote

  @Clive_A thank for the response.

I'm not looking to be spoon-fed, but also can't totally wrap my head around where I went wrong.

 

I don't mind all remote traffic going through the local gateway, I see this as a positive.

 

The only thing that has stuck out at me is:
i.e. Devices are using the interfaces below:
iOS device A, Peer A, interface = 10.0.0.1/24
macOS device B, Peer B, interface = 10.0.0.2/24
Windows device C, interface = 10.0.0.3/24
...
Allowed IPs in Omada router peer settings for A, B, and C should be 10.0.0.1/32 and 10.0.0.2/32, 10.0.0.3/32, and so on and so forth.

 

 

1. If I did choose to not pass the remote traffic, I would change the following in the WireGuard Peer (laptop): AllowedIPs = <local IP defined in WireGuard Omada router settings>/32, <local server IP>/32.
2. If I choose to keep all remote traffic going through the office network, I just need to update the Omada router peer settings to be the same allowed IP/32.

 

Is this correct?

I suppose this explains why when the host (Omada) network goes down, my laptop network goes down; because all internet traffic is going through the Omada network.

However, this doesn't explain why the Omada network goes down (or does it?)

The prerequisite is that routing all the traffic remotely(which you don't care about) depends on your tunnel connectivity.

When the tunnel is not properly set up, the network will be down.

When the network is down, the route does not work. And another peer connects to you, the network isn't working.

Both peers are routing the traffic to the other peer WG int, but that's some kind of problem.

For the explanation about the /24 or /32 on the WG int, you can refer to the guide.

Hi @rawfuls 

Thanks for posting in our business forum.

rawfuls wrote

Clive_A wrote

The prerequisite is that routing all the traffic remotely(which you don't care about) depends on your tunnel connectivity.

When the tunnel is not properly set up, the network will be down.

When the network is down, the route does not work. And another peer connects to you, the network isn't working.

Both peers are routing the traffic to the other peer WG int, but that's some kind of problem.

 

For the explanation about the /24 or /32 on the WG int, you can refer to the guide.

 

I'm getting that, do you have direct answers of where I am going wrong?

I'm trying to find my mistake and I've gleaned as much info from that tutorial as I could have, but nothing is jumping out at me.

 

Are my questions below on the right track? Should I be changing the Omada router peer to /32, are you indicating that is the problem here?

 

1. If I did choose to not pass the remote traffic, I would change the following in the WireGuard Peer (laptop): AllowedIPs = <local IP defined in WireGuard Omada router settings>/32, <local server IP>/32.
2. If I choose to keep all remote traffic going through the office network, I just need to update the Omada router peer settings to be the same allowed IP/32.

Instead of using 0.0.0.0/0 as the allowed IP, which routes all the traffic to the peer, start with the subnet you expect to access to the peer.

And, WG int with /32.

See if that works.