• 3 Posts
  • 139 Comments
Joined 1 month ago
cake
Cake day: June 4th, 2024

help-circle

  • I’m thinking about the RS6 a lot but really want to put Alpine Linux on it if I can manage it. My reasoning is I already know how to set up a router from scratch on the command line.

    OpenWRT is probably easier but I’ve had bad experiences with its UI (and the distro as a whole) in the past, but the version of it on my GL.inet travel router is pretty rock solid though the UI still annoys me and I’d rather do most configuration via SSH.

    Does OpenWRT support multiple WireGuard interfaces and VLANs? This is kind of what I’m wanting.

    pfSense (I know, it’s UNIX) looked good on paper too but after playing with it on a VPS the UI just seemed overly complex. I don’t want to learn the ins and outs of some weird UI.


  • You can strike a balance with higher-end (in quality) consumer or small business networking gear.

    If it’s in your budget, I’d suggest buying a simple router like the Ubiquiti Edgerouter X, run some Ethernet and rely on a switch and access points for WiFi (I use Ubiquiti U6 Pro but I wouldn’t be too picky about it). I’ve never been into the “mesh” WiFi networking concept because it doesn’t make sense to use the air as your backhaul (if you can help it).

    What I wouldn’t recommend is buying some beefed up consumer all-in-one router. It’ll cost a fortune, your coverage won’t be as good and once it’s time to upgrade you’ll be forced to replace the entire thing.

    Hopefully this helps.



  • Your setup looks more advanced than mine, and I’d really like to do something similar. I’m just going to copy/paste what I have with some addresses replaced by:

    VPN_IPV4_CLIENT_ADDRESS: The WireGuard IPv4 address of the VPN provider’s interface (e.g. 172.0.0.1) VPN_IPV6_CLIENT_ADDRESS: The WireGuard IPv6 address of the VPN provider’s interface VPN_IPV6_CLIENT_ADDRESS_PLUS_ONE: The next IPv6 address that comes after VPN_IPV6_CLIENT_ADDRESS. I can’t remember the logic behinds this but I’d found an article online explaining it. WG_INTERFACE: The WireGuard network interface name (e.g. wg0) for the commercial VPN

    I left 100.64.0.0/10, fd7a:115c:a1e0::/96 in my example because those are the networks Tailscale traffic will come from. I also left tailscale0 because that is the typical interface. Obviously these can be changed to support any network.

    I’m using Alpine Linux so I don’t have the PostUp, PostDown, etc. in my WireGuard configuration. I’m not using wg-quick at all.

    Before I hit paste, one thing I’ll say is I haven’t addressed the “kill switch” yet. But so far (~4 months) when the VPN provider’s tunnel goes down nothing leaks. 🤞

    sysctl -w net.ipv4.ip_forward=1
    sysctl -w net.ipv6.conf.all.forwarding=1
    
    sysctl -p
    
    ip link add dev WG_INTERFACE type wireguard
    
    ip addr add VPN_IPV4_CLIENT_ADDRESS/32 dev WG_INTERFACE
    ip -6 addr add VPN_IPV6_CLIENT_ADDRESS/127 dev WG_INTERFACE
    
    wg setconf WG_INTERFACE /etc/wireguard/WG_INTERFACE.conf
    ip link set up dev WG_INTERFACE
    
    iptables -t nat -A POSTROUTING -o WG_INTERFACE -j MASQUERADE
    iptables -t nat -A POSTROUTING -o WG_INTERFACE -s 100.64.0.0/10 -j MASQUERADE
    
    ip6tables -t nat -A POSTROUTING -o WG_INTERFACE -j MASQUERADE
    ip6tables -t nat -A POSTROUTING -o WG_INTERFACE -s fd7a:115c:a1e0::/96 -j MASQUERADE
    
    iptables -A FORWARD -i WG_INTERFACE -o tailscale0 -j ACCEPT
    iptables -A FORWARD -i tailscale0 -o WG_INTERFACE -j ACCEPT
    iptables -A FORWARD -i WG_INTERFACE -o tailscale0 -m state --state RELATED,ESTABLISHED -j ACCEPT
    
    ip6tables -A FORWARD -i WG_INTERFACE -o tailscale0 -j ACCEPT
    ip6tables -A FORWARD -i tailscale0 -o WG_INTERFACE -j ACCEPT
    ip6tables -A FORWARD -i WG_INTERFACE -o tailscale0 -m state --state RELATED,ESTABLISHED -j ACCEPT
    
    mkdir -p /etc/iproute2/rt_tables
    
    echo "70 wg" >> /etc/iproute2/rt_tables
    echo "80 tailscale" >> /etc/iproute2/rt_tables
    
    ip rule add from 100.64.0.0/10 table tailscale
    ip route add default via VPN_IPV4_CLIENT_ADDRESS dev WG_INTERFACE table tailscale
    
    ip -6 rule add from fd7a:115c:a1e0::/96 table tailscale
    ip -6 route add default via VPN_IPV6_CLIENT_ADDRESS_PLUS_1 dev WG_INTERFACE table tailscale
    
    ip rule add from VPN_IPV4_CLIENT_ADDRESS/32 table wg
    ip route add default via VPN_IPV4_CLIENT_ADDRESS dev WG_INTERFACE table wg
    
    service tailscale start
    rc-update add tailscale default
    
    iptables -A INPUT -i tailscale0 -p udp --dport 53 -j ACCEPT
    iptables -A INPUT -i tailscale0 -p tcp --dport 53 -j ACCEPT
    
    ip6tables -A INPUT -i tailscale0 -p udp --dport 53 -j ACCEPT
    ip6tables -A INPUT -i tailscale0 -p tcp --dport 53 -j ACCEPT
    
    service unbound start
    rc-update add unbound default
    
    /sbin/iptables-save > /etc/iptables/rules-save
    /sbin/ip6tables-save > /etc/ip6tables/rules-save
    
    tailscale up --accept-dns=false --accept-routes --advertise-exit-node
    









  • I use Tailscale to do this. I install the software on everything I can, but for resources on the LAN that don’t have Tailscale running I use its Subnet Router feature to masquerade the traffic and connect to those clients.

    As for the commercial VPN, it’s a bit more involved. I have a few Exit Nodes (VPS) that take incoming Tailscale traffic destined to the Internet and re-route it via the commercial VPN’s WireGuard network interface.

    This was a huge challenge for me (lots of iptables, ip6tables rules) but I have it down to a reproducible script I can provide if you’d like an example.

    My next goal is to containerize the two VPS servers into one with Docker. Tailscale is a bit annoying that you can’t have multiple Nodes running on the same machine (hence my temporary two VPS solution).

    Note: capitalized terms are Tailscale feature names





  • You won’t be “on a different local network,” you’ll be accessing specific networks (or subnets) via the VPN tunnel rather than some other network interface on your machine.

    So if you’re at home with a 192.168.0.0/24 network and you want to access an office resource on the 192.168.141.0/24 network, likely what will happen is your machine with have a route to 192.168.131.0/24 via the network the VPN provides (let’s just say 10.0.0.1).

    Depending on how everything’s configured, the server you’re accessing might see it coming from the VPN server (masquerade) or it could very well be passed on as-is (which would only work if the server has a routing table back to you via the VPN).

    Typically when people use VPNs for internet access, the traffic is sent out masqueraded so that it appears to come from the VPN’s WAN IP address.