Score:0

Wireguard not working with enpoint included in AllowedIps

cn flag

I run a wireguard enpoint as a docker container on my server with roadwarrior clients connecting to it via LTE:

wireguard network diagram

The real server address is a static public IP. The client config is as follows (irrelevant parts excluded):

[Interface]
Address = 10.254.99.2

[Peer]
AllowedIps = 10.254.99.1/32
Endpoint = 192.168.5.55

This works fine if I ping the client from within the docker container. But since I also want to reach the client from the docker host, I add a route on the server:

ip route add 10.254.99.0/24 via 172.17.0.2 dev docker0 src 192.168.5.55

Accordingly, I add the src address to the list of AllowedIps on the server:

[Peer]
AllowedIps = 10.254.99.1/32, 192.168.5.55/32

And with this things stop working. I cannot ping the client, neither from the server nor from within the container anymore. If I allow all Ips on the client instead, everything works as expected:

[Peer]
AllowedIps = 0.0.0.0/0

But I don't want to route all traffic through the tunnel. What's the proper way to do this?

A.B avatar
cl flag
A.B
multiple issues at once. `Endpoint = 192.168.5.55`. Does that mean you're attempting to tunnel 192.168.5.55 inside of the tunnel envelopped within 192.168.5.55 ?
cn flag
I don't intend to but I guess that's what I'm doing. I only want to allow traffic originating from 192.168.5.55 through wg. Not sure why this works with 0.0.0.0/0 in allowed IPs though.
Score:2
cn flag

You can't use the same address in the client's Endpoint and AllowedIPs settings*. Endpoint should be the server's address outside the tunnel, and AllowedIPs should include all the addresses you want to have access inside the tunnel.

To fix it, get rid of the src setting on the route you added to the server, so that the route will just use the address of the server's docker0 interface:

ip route add 10.254.99.0/24 via 172.17.0.2 dev docker0

Then change the WireGuard client's AllowedIPs setting to include the address of the server's docker0 interface (172.17.0.1):

AllowedIps = 10.254.99.1/32, 172.17.0.1/32

Your server will now use its docker0 interface address (172.17.0.1) as the source of the packets it sends through your WireGuard network.


However, instead of adding that extra layer of routing on your server, the simplest thing to do would be to run the WireGuard container in "host" network mode (using the --network=host flag with docker run, or the network_mode: host setting with docker-compose). That would expose the WireGuard container's wg0 interface directly to the host, so you wouldn't need additional routing rules on the server, and you wouldn't need to add additional AllowedIPs to the client.

In that case, the server would just use the WireGuard interface's own 10.254.99.1 address as the source of the packets it sends through your WireGuard network.


* unless you set up some fancy packet routing/filtering rules on your client instead of using the defaults the WireGuard client sets up for you

us flag
"You can't use the same address in the client's Endpoint and AllowedIPs settings." Why does it work when AllowedIPs=0.0.0.0/0? That CIDR covers the Endpoint.
cn flag
`AllowedIPs = 0.0.0.0/0` works because the WireGuard client special-cases `/0` to set up some fancy packet routing/filtering rules for you. Start here for an explanation of how wg-quick handles this on Linux: https://stackoverflow.com/a/70827884/149050
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.