Configuring external routes

[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!

[Smephite]

Hi there!
Hope you had a merry Christmas (if you celebrate it).

You are correct. I had mismatched configurations on the home_server and vps nodes, where home_server was missing the home service.

Fixing this, I now encounter the same behavior as you are, where nylon is overwriting the route to the 192. network also on home_server.
I am not certain if this should be intended behaviour, as now the home network is also no longer reachable from home_server itself (as the default route to the 192. is overwritten to exit over the TUN).
The default route is luckily left untouched as it is fixed to a specific interface but could also suffer from this in some edge-case network configuration.

default via 192.168.32.1 dev eth0 proto dhcp src 192.168.32.10 metric 1003 
192.168.32.0/24 dev nylon scope link 

This behaviour is also seen with the new PR when missing the exclude_ips field.

I think there should at least be a warning/info whenever nylon overwrites a route defined externally or used by any other interface to prevent user error resulting in unexpected behaviour.

Regarding the NAT:
You assumed correctly that I have a NAT setup to route packets from my home network back to the VPN.
(Side node: The new post-up configuration is great.)

I tested the new PR and it works as intended!
All in all I think the useability is quite good with the changes (and the mentioned alert if overwriting existing routes).

Thanks a lot for the work and looking forward to the new release!

If you need any more information lmk.

[encodeous]

I did, and I hope you did too, cheers! :)

Ah cool, so my guess was right.

It will indeed still override the route, since I made it include all advertised prefixes on the network by default. From my perspective, this is a bit more use-friendly (so I don't have to go and manually include prefixes I want every time). If you have a different opinion, lmk

As regards to the warning, I think I might be able to check that, but it would not be foolproof... so I'm not sure if it is worth adding that check. I will, however, add some docs on how to use this feature, and include a warning about it.

It's good to hear that you like the new PR! I also added an option to centrally exclude ip ranges by default, then override that exclude on a specific node. (e.g If you want to remote access your LAN, but also have a lot of nodes on the same LAN, and don't want to configure each LAN node).

If we have more "rules" like this, I might consider adding a node/group policy feature... but I'll keep things simple for now.