Re: [Radiusplugin-users] +bird+ipv6 -> proto static and dev tun0, let openvpn do it?

[Ralf Lübben]

Hi,

thanks for the comments. My answers are attached below. 

Am Freitag, 28. Dezember 2012, 03:03:13 schrieb Samuel Thibault:
> Hello,
> 
> We are setting up an openvpn service that provides public IPs, the
> actual routing from the internet being managed by the bird daemon.
> 
> First, the bird bit brings some constraint: the route has to be added to
> the static routing protocol, as described in ip-route(8):
> 
>   redirect - the route was installed due to an ICMP redi‐
>   rect.
> 
>   kernel - the route was installed by the kernel during
>   autoconfiguration.
> 
>   boot - the route was installed during the bootup
>   sequence.  If a routing daemon starts, it will purge all
>   of them.
> 
>   static - the route was installed by the administrator to
>   override dynamic routing. Routing daemon will respect
>   them and, probably, even advertise them to its peers.
> 
>   ra - the route was installed by Router Discovery proto‐
>   col.
> 
> The route brought by radius is indeed actually static from the point of
> view of the kernel: it shall not change until the user disconnects, and
> that's indeed what bird is listening to.
> 
> Unfortunately, AIUI selecting the static routing protocol is only
> supported by the iproute tools (ip command), not the net-tools tools
> (route command).
> 
> A second constraint is that we want ipv6 support.  I started writing
> a patch for that, the same way as ipv4 is done, but then I had an issue
> with the actual route to add.
> 
> To make things perhaps clearer: the user connects to openvpn with a
> radius login, the radius server returns for instance:
> 
>       Framed-IP-Address = 80.67.176.89
>       Framed-IP-Netmask = 255.255.255.255
>       Framed-Route = 141.255.129.0/24 0.0.0.0 1
>       Framed-IPv6-Route = "2001:910:1059::/48 :: 1"
> 
> Which means the user is given the 80.67.176.89 IP address, but the
> 141.255.129.0/24 IPv4 prefix is also routed to the client, as well as
> the 2001:910:1059::/48 IPv6 prefix. Since we are using a tun device, in
> the end what we want is simply:
> 
> ip route add 141.255.129.0/24 via 80.67.176.89 metric 1 proto static
> ip route -6 add 2001:910:1059::/48 dev tun0 metric 1 proto static
> 
> being run, and
> 
> ifconfig-push 80.67.176.89 255.255.255.255
> iroute 141.255.129.0 255.255.255.0
> iroute-ipv6 2001:910:1059::/48
> 
> being given to openvpn, so that it knows which client to send the packets
> to.
> 
> However, with the current approach of the route commands being run by
> radiusplugin, we are missing the "tun0" information, only known by
> openvpn. In the ipv4 case, we usually know the ip of the other end and
> can thus use "via", but in ipv6 we only know the prefix, and generally
> not what ip was chosen among it at the other end (and we don't want to
> impose the choice). And we don't need it anyway: everything that the
> kernel needs to know is to send the packets to tun0.
> 
> Maybe there is a way for the plugin to get that interface name, but I'm
> wondering: isn't it simpler to let openvpn run the commands, by just
> writing the following to the ccd instead of duplicating the iproute
> command generation already implemented in openvpn?
> 
> ifconfig-push 80.67.176.89 255.255.255.255
> route 141.255.129.0 255.255.255.0 80.67.176.89 1
> iroute 141.255.129.0 255.255.255.0
> route-ipv6 2001:910:1059::/48 :: 1
> iroute-ipv6 2001:910:1059::/48

I think this would be right way to use route and iroute in the client config 
file for IPv4 and IPv6

This file is written in "UserAuth::createCcdFile(PluginContext *context)" and 
superseds the functions "UserAcct::delSystemRoutes(PluginContext * context)" 
and "UserAcct::addSystemRoutes(PluginContext * context)".

Do you also want to add the attributes Framed-IPv6-Route and Framed-IPv6-
Address? 

Ralf



> 
> openvpn can then add the proper routes at the proper moment with all the
> needed information.
> 
> I'll work on the patches to achieve that at least for ipv6 which needs
> it anyway, but my question is whether I should work on doing it for ipv4
> too. If not, I'll work on making radiusplugin at least switch to using
> iproute, in order to properly pass proto static.
> 
> Samuel
> 
> _______________________________________________
> Radiusplugin-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/radiusplugin-users