1

I think I miss something during configuration. Ping still shows host is not reachable

My goal is to access remote host 10.0.0.2 from 10.0.0.99.

enter image description here

UPDATE: enter image description here After playing with different AllowedIPs I finally get traffic flow as expected.

1
  1. Enable IP forwarding on 10.0.0.99

user@wg-server:~$ cat /etc/sysctl.d/99-sysctl.conf | grep -i forw net.ipv4.ip_forward=1

reload sysctls: sudo systemctl reload sysctl

  1. Set proper routes on the wireguard clients: If AllowedIPs directive on .99 and .2 do not include 0.0.0.0/0, or a network including 10.0.0.0/24 then add: AllowedIPs = 10.0.0.0/24 <<<<< include this on your client configuration or extend the current AllowedIPs list.
| improve this answer | |
  • 1. ip_forwarding enabled on all servers 2. changed everywhere where possible AllowedIPs to 10.0.0.0/24 but still not luck :( – Marat Gainutdinov Jun 17 at 17:37
2

The problem is most certainly from the way wireguard's cryptokey routing works:

Cryptokey Routing

At the heart of WireGuard is a concept called Cryptokey Routing, which works by associating public keys with a list of tunnel IP addresses that are allowed inside the tunnel.

this association is declared with allowed-ips/AllowedIPs. Thus at a given time, on a given wireguard interface, one associated IP address can be associated with only one peer. (Probably nothing prevents to use more than one wireguard interface to "overcome" this, but this probably wouldn't scale as well.)

So if each node has this setting:

AllowedIPs = 10.0.0.0/24

it's fine for nodes connected to one peer and thus declaring this once, but becomes wrong for a node with multiple peers. A routing node having multiple peers, it's always wrong for it.

On marat3c when the first peer's config section, from my guess, 10.0.0.2's peer, is read, 10.0.0.0/24 is associated to this peer. Then when the second peer's (10.0.0.99's) config section is read, 10.0.0.0/24 is removed from the first peer and associated to the second peer. If you now type just wg on marat3c, you 'll get something like this:

interface: wg0
[...]

peer: (right peer's public key)
  endpoint: [...]
  allowed ips: (none)

peer: (left peer's public key)
  endpoint: [...]
  allowed ips: 10.0.0.0/24

If you change the order of the configuration you'll just reverse the problem: you can never have both with allowed ips: 10.0.0.0/24, the other will switch to (none), as explained at the start.

The multi-peer node should use only the IP addresses (often just one) expected to appear on the given peer to avoid this clash. So on marat3c's wg-quick's config use AllowedIPs = 10.0.0.99 for the left peer, and AllowedIPs = 10.0.0.2 for the right peer. You can also correct it "manually" (won't save it) using wg instead of wg-quick with:

wg set wg0 peer 'longpublickeyforleftpeer' allowed-ips 10.0.0.99
wg set wg0 peer 'longpublickeyforrightpeer' allowed-ips 10.0.0.2
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.