with the new “WireGuard Client support (with static routing)” feature in route10 i’m able to setup a wg client, but i cant find a way to add routing to that ‘tunnel’ and actually use it.
is that part still not available in the controller (im using the cloud controller)? is there a guide on how to set it up?
(the subnet field on the client setting does nothing)
I think this feature may have been broken in 1.3x, I had everything working in 1.3w but since upgrading to 1.3x no peers are added for wg clients I create, and I can’t see any config for it when doing a uci show or a wg show / wg showconf <interface>.
Which FW version are you on?
Latest fw on every device. and i can see my peers (from wg server) and the wg client using wg show / wg showconf <interface>
These are supposed to work. Firmware 1.3y is being pushed out now with fixes for the WG client.
update to 1.3y … reboot … still not routing the subnet 10.x.x.1/24 out thru the wg_client
(i even tried 10.x.x.1/32 [route just 1 ip] still not luck [with reboot of route10 after every client change])
also, im still not able to add wg client without PKS.
firmware 1.3x → Add support for WireGuard client without PSK (controller support pending)
current firmware:
route10 -- 1.3y
s8-poe -- 2.1t
APs -- 2.2g
controller -- cloud
@Alta-MikeD – any news? i’m doing anything wrong on the setup?
My Route10 is on the 1.3y firmware and also unable to save my configuration with no PSK in the field.
Can you please clarify the use of “out” here? I assume this is out from the server? Or do you literally mean out/transmit from the WG client/peer (to server)?
This still is not yet supported, even as of 1.0v. This is Control side.
I’ll be doing some testing/verification shortly and will follow up. This was working perfectly fine for me before when I tested—any of the configured remote peer’s subnets were accessible, but only after I configured them in the AllowedIPs list (and AllowedIPs is really only meant for the remote peer, not for subnets local to the device, to my understanding).
I do have a question mark/possible bug I’m wondering about there, but you don’t appear to have hit that one based on what you shared in your post (I’m curious about network address interpretation as there was a previous bug related to exactly that). There is another one I’m wondering about with S2S, too, but that’s a separate topic…
Support will be fixed in a future Control update. This is not a firmware side change. It is not supported in 1.0v which is the latest at the time of this post.
@Alta-MikeD – what im trying to do is this:
- connect to a wg server in another state (wg_s1)
- use route10 as a wg client (wg_c1) to connect to wg_s1
(i can connect successfully from wg_c1 to wg_s1 – at least thats what i see in the wg_s1 logs) - my local machine (local1) should exit to the internet thru wg_s1 via the wg_c1 tunel
(local1 is in the subnet assigned in the wg_c1 settings) - local1 gets no internet access when the wg_c1 is enabled
- if i connect to wg_s1 directly from my laptop wg client (wg_c2) or phone wg client (wg_c3) using the same settings, i can see the successful connection(s) in wg_s1 logs, and my traffic goes out to the internet via wg_s1 (if i visit ip.wtf or ip.me i get the wg_s1 public IP address)
my question: how can i direct the traffic from my local1 via the wg tunnel created between wg_c1 and wg_s1? (on my wg_c2 and wg_c3 tunnels, Allowed IPs in the settings is 0.0.0.0/0)
PS - in the wg_c1 config, the IP range from Subnet, shows as Allowed IPs if i do a wg show (in route10 via ssh); if i try to add Subnet 0.0.0.0/0 its not letting me (Please enter a valid subnet address and prefix.)
PS2 - if you need access to my site let me know; all hardware is on latest firmware as of right now, and i use cloud controller
1 Like
Thanks for the details! So I haven’t gotten to testing yet, but based on your details I think it’s leaning at least partially on what I was suspecting. I really want to test before I say too much more though as I’m not 100% sure of all the parts. Getting set up for it now, I have 2 WANs here at home, and multiple Route10s, so that part is easy…
When you specify the actual remote peer’s subnet in the AllowedIPs on the client, are you entering the gateway IP 10.x.x.1/24? or 10.x.x.0/24? Both are technically valid ways to write it, but the latter written as a literal network address is more likely to fail, and it should be the (actual) gateway IP+CIDR when you want an entire subnet. If you haven’t yet tried that, please do (not entirely sure in the above post with the /24 and /32 mentioned). I realize this won’t route all traffic, but this would confirm if we can access a remote peer’s subnet, which is a start.
I know 0.0.0.0/0 is also valid, and usually is used client side to route all client/peer traffic over the WG tunnel, but if the firmware is reporting it’s not valid then that is a red-flag for an issue if it’s what’s currently configured in AllowedIPs. I am not sure why it’s allowed in the front end if it’s being rejected by the firmware, but that’s something I need to check too.
I’m more than happy to take a look if that’s what you’d prefer. Please just let me know. I’ll follow up shortly with the various results from my testing.
in route10 client setup … what should be entering for Subnet?
(subnet in our route10 … or a subnet in wg server?)
i just tested, if i enter a subnet (i used 10.x.x.0/24) in the wg server … i can access stuff on that network. but its using the tunnel just for the IPs in that range. Im not going out to the internet via that tunnel.
(edit: 10.x.x.1/24 does not allow me to access any resources)
maybe as feedback … on the route10 client setup GUI … Subnet should be renamed to Allowed IPs ?
1 Like
Sorry, to answer this, my understanding is that the AllowedIPs should contain the IP(s)/subnet(s) you wish to allow from the remote peer. So for the client you would want the server’s remote subnets, and then if it was S2S, you would want the server to have the subnets of the client in the AllowedIPs to get 2 way traffic over the tunnel.
Now that part just covers internal subnet traffic, but not everything. This goes back to 0.0.0.0/0 being rejected by firmware. I certainly could be mistaken, but I think on the client side this is usually what you’d enter to route all (IPv4) traffic over the tunnel ( ::/0 for IPv6). That seems like an unintended bug/limitation that needs to be fixed in firmware, but I could be mistaken.
Technically server/client roles really are only defined by the connection initiation (i.e., the server listens for incoming connections), once the tunnel is established both ends are essentially peers… If that helps simplify what I meant by peer and remote peer above.
Thanks! So maybe it’s not the network address interpretation. However that does confirm my other suspicion.
Thanks! Will bring this up for discussion.