need basic help

[NorbertPausB]

Hello,
when I read the docs and the discussions, wag seems to be what I'm looking for. Although there are some contradictions in the docs. E.g: in limitations I read: "Only supports clients with one AllowedIP, which is perfect for site to site, or client -> server based architecture". On the other hand routing or routing restrictions seem to be a main function in wag. How can routing work when a Client has only one allowed IP?

On the learning by doing way I got stuck on an early stage: Wag is running as a docker container on a Cloud Server. I could - after a while - configure some clients which are now busy hand shaking with the server. From every client I can successfully ping the (wag-)server (10.168.168.1) but not from client to client let alone a machine behind a client.

Every client config has the wag-net (10.168.168.0/24) as "allowed IPs" and under wag rules every user has this network as public rule.

Tcp-dump on the docker host shows incoming packets which seem to correspond with then client ping reqests but there seem to go no packets out to the target client.

In a classic wireguard installation I would dump the packets in the server for analysis. The Basic red-hat machine behind wag gives no such tools and so I have no idea what I'm doing wrong or what I misunderstand.

Can anybody help me?

My goal is to manage access for several road warriors to machines behind client gateways. Is this possible at all (see restrictions)?

[NHAS]

Howdy,

Yeah that documentation saying site to site is just not correct. I cant remember why I wrote that.

Can you give your acls config? Wag has an in-built firewall that lets you define what resources can hit what routes and it sounds like the rule isnt being hit.

[NHAS]

In the UI you can test your firewall rules (as long as you're not defining IPv6 routes, work in progress) so see what decision is made.

[NHAS]

I have two internal network devices.
10.112.3.2
10.112.3.3

When my all route (*) is set to this, we can see the firewall drops the packet (ignore the port for icmp).

When the rule is added we can see that the packet is passed.

[NHAS]

Then making sure your range is also in the AllowedIps in the wireguard profile.

If that works, and you're using NAT mode (which is the default).

You'll need to add:

...
"NATExcludeRanges": ["10.168.168.0/24"]
...

To your config so that wag doesnt translate the internal ip address to the external ip and then pass it back into the tunnel.

[NHAS]

You may get some errors like this:

64 bytes from 10.112.3.3: icmp_seq=4 ttl=63 time=119 ms
From 10.112.3.1 icmp_seq=5 Redirect Host(New nexthop: 10.112.3.3)
64 bytes from 10.112.3.3: icmp_seq=5 ttl=63 time=131 ms
From 10.112.3.1 icmp_seq=6 Redirect Host(New nexthop: 10.112.3.3)
64 bytes from 10.112.3.3: icmp_seq=6 ttl=63 time=150 ms
64 bytes from 10.112.3.3: icmp_seq=7 ttl=63 time=172 ms

This is just the host being confused why you're routing link local traffic through it. Safe to ignore, and you can disable them if you want :)

Hope this helps!

[NorbertPausB]

Hi NHAS, thank you for your super fast response.
I tried
"NAT": true, "NATExcludeRanges": ["10.168.168.0/24"], "Webserver": { "Lockout": 5, "Tunnel": {..........
but got this in the logs:
2026/02/12 06:22:58 unable to load configuration file from /cfg/config.json: json: unknown field "NATExcludeRanges"

Switching NAT to "false" seems to be the solution. Ping is working now and I proceed with the learning by doing thing.....(Hope net behind the client will work without NAT)
Thanks a lot

[NHAS]

Ah sorry I've pointed you towards a feature I haven't released yet that was an external contribution.

You can try it out if you want to use the unstable branch, that'll mean that anything that does need natting will work as well.

[NorbertPausB]

Hi NHAS,
it looks like you define routing just from the server towards non-wg networks but not in a hub and spoke manner.
My challange is to connect road warriors with networks behind fibre or mobile routers which don't get a public ip and therefore hub and spoke it the only way to connect. I realized this with the standard wireguard approach an hoped to ease the management of the system with your software. But this seems not to work.