Let the OS be the router, use TAP instead of TUN always
Posted: Tue Aug 20, 2013 10:17 pm
As of openvpn 2.3.1, in order to have multiple clients connect to a single server, either a bridge needs to be setup, or a tun device multiplex multiple connections.
I suggest instead of using a tun device, that always a tap device should be used, even in routing mode.
Openvpn would emulate an ethernet segment locally, allocating MAC address for each remote client.
Let's say:
we have the openvpn network be 10.0.0.0/24, the server is .1, clients from .2 through .254
local LAN is 192.168.0.1/24
each remote LAN is 192.168.X.0/24, where X=the remote client uses 10.0.0.X for its address
Today this would result with a tun device:
10.0.0.0/24 dev tun0
192.168.2/24 dev tun0
192.168.3/24 dev tun0
... One for each remote office
And openvpn needs to know what remote network each 192.168 network connects to. It needs to match the remote IP through its internal routing table - iroute's.
With this proposal implemented, here's how it would look like:
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:02:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth0
routing table:
10.0.0.0/24 dev tap0 src 10.0.0.1
192.168.2/24 via 10.0.0.2 dev tap0
192.168.3/24 via 10.0.0.3 dev tap0
192.168.4/24 via 10.0.0.4 dev tap0
192.168.5/24 via 10.0.0.5 dev tap0
192.168.6/24 via 10.0.0.6 dev tap0
...
Internally, hits to the remote IPs generate ARP requests, openvpn could add ARP entries statically, or respond the ARP requests locally to the kernel.
Then linux/bsd would send remote packets as layer2 packets, with a destination MAC address, openvpn would just match the remote MAC address to each remote client, completely eliminating the iroute table, the external OS routing table would be the only IPv4/IPv6 routing table involved.
The low level implementation is simple, since the local/remote MAC address would be set by openvpn, with up to the last 4 bytes of the MAC address settable any way openvpn deems more convenient. For instance, the remote MAC addresses could always be 00:02:<remote peer connection ID>, I'm using 00:02 prefix, as it's designated as a user administered MAC address range, from 00:02:00:00:00:00 through 00:02:ff:ff:ff:ff, there are other ranges, it's just the first one.
Why go through all this trouble ?
This allows for running OSPF/BGP4 over openvpn networks, with quagga inserting the all routes except for the main openvpn backbone route, which is created by justing adding a local ip+netmask to the tap device.
AFAIK, today this is impossible in routing mode, due to the presence of the iroute table.
Also allows for complex, failover, multi server setups, that are impossible with openvpn in routing mode, since openvpn must insert an overreaching routes on the OS and must keep an internal iroute table.
This could also make it easier to have a openvpn server-to-server connection, for having fully meshed setups in the future. This is outside the scope of this request, just food for thought.
I suggest instead of using a tun device, that always a tap device should be used, even in routing mode.
Openvpn would emulate an ethernet segment locally, allocating MAC address for each remote client.
Let's say:
we have the openvpn network be 10.0.0.0/24, the server is .1, clients from .2 through .254
local LAN is 192.168.0.1/24
each remote LAN is 192.168.X.0/24, where X=the remote client uses 10.0.0.X for its address
Today this would result with a tun device:
10.0.0.0/24 dev tun0
192.168.2/24 dev tun0
192.168.3/24 dev tun0
... One for each remote office
And openvpn needs to know what remote network each 192.168 network connects to. It needs to match the remote IP through its internal routing table - iroute's.
With this proposal implemented, here's how it would look like:
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:02:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth0
routing table:
10.0.0.0/24 dev tap0 src 10.0.0.1
192.168.2/24 via 10.0.0.2 dev tap0
192.168.3/24 via 10.0.0.3 dev tap0
192.168.4/24 via 10.0.0.4 dev tap0
192.168.5/24 via 10.0.0.5 dev tap0
192.168.6/24 via 10.0.0.6 dev tap0
...
Internally, hits to the remote IPs generate ARP requests, openvpn could add ARP entries statically, or respond the ARP requests locally to the kernel.
Then linux/bsd would send remote packets as layer2 packets, with a destination MAC address, openvpn would just match the remote MAC address to each remote client, completely eliminating the iroute table, the external OS routing table would be the only IPv4/IPv6 routing table involved.
The low level implementation is simple, since the local/remote MAC address would be set by openvpn, with up to the last 4 bytes of the MAC address settable any way openvpn deems more convenient. For instance, the remote MAC addresses could always be 00:02:<remote peer connection ID>, I'm using 00:02 prefix, as it's designated as a user administered MAC address range, from 00:02:00:00:00:00 through 00:02:ff:ff:ff:ff, there are other ranges, it's just the first one.
Why go through all this trouble ?
This allows for running OSPF/BGP4 over openvpn networks, with quagga inserting the all routes except for the main openvpn backbone route, which is created by justing adding a local ip+netmask to the tap device.
AFAIK, today this is impossible in routing mode, due to the presence of the iroute table.
Also allows for complex, failover, multi server setups, that are impossible with openvpn in routing mode, since openvpn must insert an overreaching routes on the OS and must keep an internal iroute table.
This could also make it easier to have a openvpn server-to-server connection, for having fully meshed setups in the future. This is outside the scope of this request, just food for thought.