Be even noisier about /proc/sys/net/ipv4/ip_forward disabled

[apenwarr]

tailscale up --advertise-routes doesn't work, of course, when /proc/sys/net/ipv4/ip_forward is set to 0 (which stops any packets from being relayed). We can't automatically set it to 1 because that could cause unexpected security holes outside of tailscale; a user should decide for sure that they want ip forwarding enabled.

We do print a warning (I think) in tailscale up when that flag is set wrong, but it's easy to miss, and also, if someone fixes it temporarily (by writing to /proc/sys/net/ipv4/ip_forward), it'll eliminate the warning and work for a while, but suddenly stop after they reboot, and then there is nowhere good to put a warning since they don't need to re-run tailscale up.

I suggest we have tailscaled provide an optional set of warning strings when it registers itself. We could print those warnings in the admin UI in some prominent place, and trigger a warning when ip_forwarding is disabled (perhaps among other things).

In the shorter term, we should at least warn about it in the tailscaled logs somewhere that shows up periodically, so someone reading the diagnostic logs would notice it right away.

[crawshaw]

There's the very aggressive option: set it for them if they --advertise-routes. Risky though.

Plumbing errors through to the admin console makes sense to me. (It seems actively an error to both set --advertise-routes and disable ipv4 forwarding.)

[apenwarr]

Yeah. We could have a --force-ip-forwarding flag instead of just a warning in 'tailscale up'. If the flag is not set, and ip forwarding is disabled, and advertise-routes is enabled, then we could fail the whole network at next reboot so at least it's obvious they did something wrong. If the flag *is* set, we force-enable ip forwarding on next reboot. But even with a --force option, it can lead to problems to have apps just globally changing routing settings. Then the admin tries to disable forwarding, thinks they succeeded, and some app flips it back on again sometime later.

…

On Tue, Jul 21, 2020 at 2:59 PM David Crawshaw ***@***.***> wrote: There's the very aggressive option: set it for them if they --advertise-routes. Risky though. Plumbing errors through to the admin console makes sense to me. (It seems actively an error to both set --advertise-routes and disable ipv4 forwarding.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Avery Pennarun // CEO @ Tailscale

[DentonGentry]

Since this was filed, we've added flagging with an exclamation point in the Admin panel when a subnet router has IP forwarding disabled or is otherwise unable to route.

Barring further updates or comments, we'll expect to close this during the next bug scrub.