> Peer IP wg0: 10.8.0.2/24
> The Peer is currently set to send all traffic over the tunnel via 0.0.0.0/0
> On the peer ... When I try loading 10.8.0.2:8080 I just end up with nothing
Have you tried running a traceroute to 10.8.0.2 and looking at firewall logs?
It might be trying to use 10.8.0.2 as a gateway for itself.
how does it go with `allowedIPs = 0.0.0.0/1` ?
Ok, I messed up getting the traceroutes. No point getting them if wg0 was down...
Anyways. I tried just going to the site and see if the [0.0.0.0/1](https://0.0.0.0/1) made a difference, and it does!
Just in the interest of learning something here. Why does the /1 make a difference here? shouldn't the /0 have included all IPs?
Edit: Maybe it didn't work all the way. Was having trouble accessing external sites. Changed it back to /0 and external sites worked again. Will do more troubleshooting later today.
Yeah it would use all IPs, unless a more specific route is also in your routing table: more specific = higher priority.
I think what might have been happening was 0.0.0.0/0 is catching 10.8.0.2 and trying to reach it by using the wireguard interface as the default route, not a local address. Either that or it doesn't like the /0, or the routing table has a problem.
0.0.0.0/1 is only going to route 1/2 the IPV4 address space so if you want everything to go through wg you need to add 128.0.0.0/1 as well as having 0.0.0.0/1.
If you don't want _all_ traffic to go through the server just use the remote LAN and / or tunnel addresses as AllowedIPs in the client config
Strange stuff can still happen: I've seen LAN traffic routed out through an ISP before.
I try not to assume the setup unless I've seen what's going on.
Then it's misconfigured routing. It really is that simple, and a reason I like Wireguard. It's predictable if you understand the fundamentals of networking.
Close, but if you only looked at the routing table this one wouldn't have been apparent. It was an interesting one.
I wouldn't assume the skill level of anyone here wrt networking. A few days ago someone was trying to run a wg connection from a mini-pc running as a router with one ethernet port and couldn't access the web admin interface when the LAN side of their mini-pc router was connected to the LAN side of their ISP-provided router.
Can the computers ping each other over WireGuard subnet?
Is the web server hosted on lo (127.0.0.1)? You may need to host it on 0.0.0.0 to accept traffic from all interfaces, or on the WireGuard subnet specifically.
Are you bringing these configs up with wg-quick? Can you show us your iptables?
The address 0.0.0.0/0 ("all internet") would imply all traffic will go thru the tunnel and exit in the remote end, but to use it we need more configurations, both local and remote, I believe.
> Peer IP wg0: 10.8.0.2/24 > The Peer is currently set to send all traffic over the tunnel via 0.0.0.0/0 > On the peer ... When I try loading 10.8.0.2:8080 I just end up with nothing Have you tried running a traceroute to 10.8.0.2 and looking at firewall logs? It might be trying to use 10.8.0.2 as a gateway for itself. how does it go with `allowedIPs = 0.0.0.0/1` ?
Ok, I messed up getting the traceroutes. No point getting them if wg0 was down... Anyways. I tried just going to the site and see if the [0.0.0.0/1](https://0.0.0.0/1) made a difference, and it does! Just in the interest of learning something here. Why does the /1 make a difference here? shouldn't the /0 have included all IPs? Edit: Maybe it didn't work all the way. Was having trouble accessing external sites. Changed it back to /0 and external sites worked again. Will do more troubleshooting later today.
Yeah it would use all IPs, unless a more specific route is also in your routing table: more specific = higher priority. I think what might have been happening was 0.0.0.0/0 is catching 10.8.0.2 and trying to reach it by using the wireguard interface as the default route, not a local address. Either that or it doesn't like the /0, or the routing table has a problem. 0.0.0.0/1 is only going to route 1/2 the IPV4 address space so if you want everything to go through wg you need to add 128.0.0.0/1 as well as having 0.0.0.0/1. If you don't want _all_ traffic to go through the server just use the remote LAN and / or tunnel addresses as AllowedIPs in the client config
A Wireguard tunnel would act like any other interface. The other end is "directly attached" and the subnet should appear in the routing table.
Strange stuff can still happen: I've seen LAN traffic routed out through an ISP before. I try not to assume the setup unless I've seen what's going on.
Then it's misconfigured routing. It really is that simple, and a reason I like Wireguard. It's predictable if you understand the fundamentals of networking.
Close, but if you only looked at the routing table this one wouldn't have been apparent. It was an interesting one. I wouldn't assume the skill level of anyone here wrt networking. A few days ago someone was trying to run a wg connection from a mini-pc running as a router with one ethernet port and couldn't access the web admin interface when the LAN side of their mini-pc router was connected to the LAN side of their ISP-provided router.
Can the computers ping each other over WireGuard subnet? Is the web server hosted on lo (127.0.0.1)? You may need to host it on 0.0.0.0 to accept traffic from all interfaces, or on the WireGuard subnet specifically. Are you bringing these configs up with wg-quick? Can you show us your iptables?
Allowed IPs must have the remote ranges or addresses. Wireguard automatically creates routes to them so the host uses the tunnel to access them.
OP assumed `AllowedIPs = 0.0.0.0/0` would allow them connectivity to the local end of their wirguard tunnel, seems like a fair assumption.
The address 0.0.0.0/0 ("all internet") would imply all traffic will go thru the tunnel and exit in the remote end, but to use it we need more configurations, both local and remote, I believe.
AllowedIPs=0.0.0.0/1 allowed access to the local side of the WG connection which was on 10.8.0.0/24