Skip to content

IP does not belong to any network addresses of WireGuard server #667

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
raihei opened this issue Mar 8, 2025 · 6 comments
Open

IP does not belong to any network addresses of WireGuard server #667

raihei opened this issue Mar 8, 2025 · 6 comments

Comments

@raihei
Copy link

raihei commented Mar 8, 2025

Trying to add a IP range to one of the clients, so that all requests for that range go through that client tunnel to the devices located at the client side.
I want to access these devices from other clients that connect to this wg-server.
Without wireguard-ui it works like expected, but now I tried to switch to wireguard-ui and I cannot add this range to the client.

WG server: 172.17.19.1
WG client: 172.17.19.4
Network that should be accessible (located at client side): 172.17.17.0/24

Image

Config from my old wg0.conf (without wireguard-ui):

[Interface]
Address = 172.17.19.1/24

[Peer]
AllowedIPs = 172.17.19.4/32, 172.17.17.0/24

(Removed keys, etc)

@samrocketman
Copy link

You need to configure the server (which is your ip range) followed by adding your client (with a single ip within the range i.e. /32).

@raihei
Copy link
Author

raihei commented May 4, 2025

That is not the problem, the server is already configured with its interface IP:

Image

The subnet that cannot be entered in the dialog is NOT the server subnet. It is a completely different subnet, which is available at the client side.

Network that should be accessible (located at client side): 172.17.17.0/24
Server Subnet: 172.17.19.0/24

Wireguard works perfectly with the manual configured wg0.conf, so the configuration seems correct. It is only WGUI not accepting the input.

Edit: Ops, just saw in my old screenshot, that it seems I have tried to enter the allowed IP range into the wrong field (IP allocation). I will double check.

Edit2: Seems to be correct, because the subnet is on the client side and not on the server side. I have manually added that subnet via the conf file, because the UI did not allow it, and everything works as expected.

Edit3: Fixed wrong screenshot

@Bronn
Copy link

Bronn commented May 20, 2025

Same problem. My server has [Interface] Address=10.18.0.1/32 and wg work perfectly, but GUI write same error.
For workaround i add network 10.18.0.24 like on screenshot:

Image

@samrocketman
Copy link

samrocketman commented May 21, 2025

Edit: after some testing all of my comments don't make sense and I better understand what you're getting at. In my case the bridged networking is enough but I can see why you might want wg0 to have a dedicated IP if you start services specifically on wg0.


@Bronn @raihei I will try to restate the error in your config and the proper fix.

You have in Server Interface Addresses:

10.18.0.1/32 10.18.0.0/24

Remove 10.18.0.1/32 from your config.

Generating clients will work and successfully connect.

Fixed config

You Server Interface Addresses should have only network CIDR and not a /32 IP address.

Good config:

10.18.0.0/24

My wireguard UI setup has 4 interfaces (LAN access, two DMZ, one isolated VPN network) and it is working fine using only network CIDRs.

@samrocketman
Copy link

samrocketman commented May 21, 2025

I just tested with a /32 successfully in my build but mine is heavily modified.

In my case, 10.0.0.2/32 and 10.0.0.0/24 mix together fine. In my case, I was able to add a couple of IPs after the server was assigned ".2". It's not ".1" because I already have a client configured.

Image

Image

@samrocketman
Copy link

I tried reversing the values and it still works fine in my build.

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants