Investigate / implement route priorities

[kallisti5]

Haiku today doesn't implement any route "priority" system. Linux calls this "metric".

Essentially, the Linux, BSD, etc network stacks have a "metric" which is the 'cost' of each route.

This is relevant in cases like OpenVPN. Example:

• OpenVPN adds multiple routes to route traffic over the VPN..
  • one route to ensure traffic to the VPN server continues to go over the current "real" network interface / gateway
  • one route to send all traffic (default / 0.0.0.0) over the VPN

OpenVPN adds these routes on linux with the assumed metric of "0" (highest priority). While the system's DHCP allocated routes have a metric of "600".

Traffic is directed over the OpenVPN added routes with a lower cost / metric. On shutdown, these routes with the lower cost are just removed returning the system to it's former routing.

Haiku lacks a priority system, meaning to have OpenVPN work, we need to:

• Add a route to the VPN server over the existing gateway
• Delete the systems current default gateway (since we don't have a metric/priority, we can't add multiple default gateways)
• Add a new default gateway over the VPN

Another example of our limitation is attaching two interfaces with DHCP w/ a gateway. Haiku will always route traffic over the "last attached" interface. We don't have the option of routing default traffic over either interface.

[kallisti5]

So.. one final observation. We already have "Metric" on the individual physical network interfaces...

ifconfig tun/0
tun/0	Hardware type: unknown, Address: none
	inet addr: xxx.xxx.xxx.xxx, Mask: 255.255.255.255
	MTU: 1500, Metric: 0, up link
	Receive: 47065 packets, 0 errors, 3952992 bytes, 0 mcasts, 0 dropped
	Transmit: 46995 packets, 0 errors, 3947580 bytes, 0 mcasts, 0 dropped
	Collisions: 0

Looking over our code, Metric is set and stored, but never used anywhere LOL.

[kallisti5]

I can see where Be was going adding Metric to the BNetworkInterface, however it's putting a priority where there really shouldn't be one.

Priorities effectively adjust "which route the network stack takes", not "which interface the network stack uses". My opinion is it's a bit oversimplistic adding the priority to the overall interface instead of the individual routes.

Think in these terms:

• A VPN needs to retain connectivity to the VPN server over the current interface, and it needs to route all other traffic over the VPN.
  • If the priority was only on the interface, how would it do this? It needs to prioritize routes, not interfaces.

[kallisti5]

waddlesplash pointed out BSD might work like this with an interface-level metric.

I confirmed FreeBSD does indeed have interface-level metrics. I feel like the interface level design leaves a lot of people confused from my initial research.

[humdinger]

Would this be the right place to mention implementing a "kill switch", i.e. should the connection to a VPN go down, all traffic stops (until the VPN connection is re-established)?