wg AllowedIps not set

[Smephite]

While continuing my work on the NixOs integration I encountered the following issue:

My setup is as follows:

Nylon version v0.3.2.

routers:
  - id: vps
    address: 172.24.0.1
  - id: home_server
    address: 172.24.0.22
    services:
      - home
services:
   home: 192.168.32.0/24
graph:
  - vps, home_server

VPS is running NixOs with disabled firewall and enabled IP forwarding.
home_server is running Debian 6.12.48 with IP forwarding enabled.

By default, the two servers can ping each other, but I cannot ping the home network (192.168.32.0/24) from the VPS.

Using tcpdump, I can see the ping packets exiting the VPS nylon interface, but they are not being received on the home_server side.

Only after manually adding the allowed-ips settings to the WireGuard interface am I able to successfully ping the network.
(wg set nylon peer ... allowed-ips 192.168.32.0/24)

I am unsure, if this a nix specific issue, or something also encountered else wise.

Is there anything speaking against adding the AllowedIps setting to the wireguard interface from within Nylon?

[encodeous]

Hmmm… that is interesting behaviour. I’ll have to look into it a bit more over the weekend.

[Smephite]

Thanks a lot!

Issue also holds with v0.3.3.

[encodeous]

I played around a little bit, and indeed, I think my implementation is a bit flawed.

However, I haven't been able to reproduce your exact scenario.

Nylon shouldn't use allowedips for packet forwarding, it only falls back on allowedips if none of the filters match. On the receiving end (home_server), if the 192 prefix isn't marked as a service, then it would be dropped unless there was a fallback allowedips rule (which it sounds like you added). Are you sure the same configuration is synced to both machines? That would make sense if it were the case, since otherwise you'd run into the situation below, which I did reproduce.

Also, out of curiosity, did you look at how the packet was forwarded on home_server once you added the allowedip? Did it actually leave the server then return? I would imagine not, unless you have some kind of NAT set up, or you configured your home network to send the packets from the vpn subnet back to the home_server.

What I encountered:

If you set a service in the config, it would wipe out the configured route on all nodes, even on home_server... Meaning that even when a packet comes in to home_server, it's never routed to the local network (just straight back to the TUN). At the same time, the old behaviour would magically set an alias on the TUN for that service's ip, so the packet's journey ends there. This is not "wrong" per se, but I think the user should be able to configure that (and be a bit more explicit). (And its quite confusing)

• I originally designed it that way, as I was listening on the interface, and running services on the service ips, which is where the name originates.

This is probably undesirable in your scenario, where you want to egress out of a nylon network, and it's rather confusing ngl.

In this PR: #54, i'm opting to remove the concept of a service altogether, since I feel its a bit inflexible. (This would make it into v0.4) It would alleviate some of the confusion, and make it a lot easier to set up a scenario like yours.

In your scenario, you would now do:

routers:
  - id: vps
    addresses: [172.24.0.1]
  - id: home_server
    addresses: [172.24.0.22]
    prefixes:
      - 192.168.32.0/24
graph:
  - vps, home_server

On your home_server's local/node config, you would can exclude the advertised prefix (since you want it to go to the local network, not VPN), and optionally add a NAT rule

<other things>
post_up:
  - iptables -t nat -A POSTROUTING d 192.168.32.0/24 -j MASQUERADE
exclude_ips:
  - 192.168.32.0/24

You can try this new PR out, or wait for me to test it a bit more on my network and make a release :)

Also, if you have any suggestions on how this could be a little bit easier to use, lmk!