Replace my old VPN-setup

[joachimtingvold]

Hello,

Stumbled across this project by happenstance while I was in the middle of figuring out my "VPN situation". For several years I've used a commercial enterprise VPN-solution (GlobalProtect towards my Palo Alto firewalls at home), but as that has gotten more unstable as of lately, and also not being very flexible for some of my needs, nylon looks like a potential replacement. Specifically it seems to solve several things that "irks" me with Tailscale/headscale:

• No need for full mesh
• Can use ad-hoc Wireguard-clients (where installing nylon is not possible, but where the device has native Wireguard support)
• Can use my own prefix/IPs for participating devices (due to how engrained the CGNAT/RFC6598-prefixes are within Tailscale-code, this is not something that will be available "anytime soon" in Tailscale)

For a while it looked like NetBird was a good candidate, but unfortunately it doesn't have IPv6-support, which I need.

The topology for my setup would be something like below. Arrows shows connection direction (i.e. anything with an arrow pointed to it, will accept incoming connections on the nylon port). Some are one-way, others in both directions.

graph LR
    vps[VPS];
    phone[Phone w/ Wireguard];
    4g[4G router w/ Wireguard];
    p1[Prefix A];
    h1a[Home #1 A];
    laptop[macOS laptop];
    h1b[Home #1 B];
    h1c[Home #1 4G];
    p2[Prefix A+B+C];

    vps ~~~ phone; 
    phone --> |60ms| vps;

    vps ~~~ 4g;
    4g --> |60ms| vps;
    4g --- p1;

    vps ~~~ h1a
    vps ~~~ laptop
    vps ~~~ h1b
    vps ~~~ h1c 

    h1a <--> |40ms| vps;
    laptop --> |10ms| h1a;
    laptop --> |40ms| vps;
    laptop --> |10ms| h1b
    h1b <--> |40ms| vps;
    h1c ---> |60ms| vps;

    h1a & h1b & h1c --- p2
    
    classDef whiteFill fill:white;
    class p1,p2 whiteFill;

Loading

I do have a couple of questions;

1. How resilient/quick is nylon to connect/reconnect on macOS via the launchctl plist setup? I'm thinking when you switch WiFi-networks, switch to phone-sharing, connect/disconnect wired, waking the machine from sleep (opening the lid), etc?
2. Is there a way to let nylon configure the DNS-servers of the client? (i.e. not just what DNS nylon itself uses, but what the client/system uses?). Tailscale/NetBird/etc does this, so that if you run your own DNS-servers, the client/laptop will always use these (routed over the VPN), rather than whatever they receive via DHCP/etc.
3. If you look at the topology above, you notice that prefix A is present two places. It's from the same source/location. Is there some kind of metric/weight that can be added to prefixes/subnets being announced into nylon, so that it will always prefer the routes coming from Home #1 A and Home #1 B, before choosing 4G router, regardless of the latency to these nodes? (and only choose 4G router if both Home #1 A and Home #1 B becomes unavailable).
4. Is there a way to dynamically announce routes into nylon? For the purpose of this discussion, let's assume Home #1 A and Home #1 B runs BGP towards my firewalls, and I wan't to announce any routes learned via BGP into nylon dynamically? (or via some script/hooks/similar).

[encodeous]

Hey Joachim,

Sorry for the delay in answering this question... Seems like GH doesn't notify me for Q&A.

As to your questions:

1. I try to target < 10s of time where a given node is disconnected from the network. It may take longer (on the order of 1 minute) for nylon to converge to the optimal path, since it's more conservative. (We don't want routes to flap all the time)
2. Currently, no. What I have done in the past was to run a set of CoreDNS servers, and announce them anycast on the nylon network. You can just set your system dns to that dns server. (However, on macOS there was an issue with captive portal detection...)
3. Yes, since v0.4, you can manually assign metrics to add to prefixes advertised by the current node.

    prefixes:
      # Static: always advertised at the given metric
      - type: static
        prefix: 192.168.0.0/24
        metric: 0 # optional, default 0
      # Ping: advertised with RTT as metric, withdrawn after max_failures consecutive failures
      - type: ping
        prefix: 10.1.0.0/24
        addr: 10.1.0.8           # address to ping
        delay: 10s               # interval between pings (default: 15s)
        max_failures: 3          # failures before withdrawal (default: 3)
        bind_if: en10            # optional: bind to a specific interface
        # metric: 0              # optional: override RTT with a static metric

4. This is not something I have explored yet. It should be possible with some small changes though.