Project

General

Profile

Feature #3104

EAP-RADIUS: binding address feature for routers with multiple interfaces connected to LAN.

Added by Adrian Ban over 1 year ago. Updated about 1 year ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
libcharon
Target version:
-
Start date:
30.06.2019
Due date:
Estimated time:
Resolution:

Description

Hello,

I'm using the Strongswan software on my Linux boxes for long time. My routers are using FRRouting software suite and of course I have multiple interfaces towards my network. Because of this setup I'm facing a problem: RADIUS packets are going out on the fastest/shortest link as source IP. If that link for some reasons is changed, RADIUS packets are going out with another sources IP.
PPP software has also a RADIS-ul plugin and I've did a patch for it to use the bind address configuration directive and I'm using one of the loopback interface IP of my router as source IP. In this way the loopback address is distributed in the network and reachable from anywhere in the network.
With this feature the RADIUS plugin will bind on a specific address and it will send the RADIUS packets only from that source IP regarding the uplink and it will not be necessary to add in RADIUS server all the router interface, which is an ugly workaround.

Kind regards,
Adrian

History

#1 Updated by Tobias Brunner over 1 year ago

  • Status changed from New to Feedback

Because of this setup I'm facing a problem: RADIUS packets are going out on the fastest/shortest link as source IP. If that link for some reasons is changed, RADIUS packets are going out with another sources IP.

Why is that a problem? Fix your routing if you want a different behavior.

Also, couldn't you just NAT RADIUS packets to whatever source IP address you want to use?

to use the bind address configuration directive and I'm using one of the loopback interface IP of my router as source IP. In this way the loopback address is distributed in the network and reachable from anywhere in the network.

Not sure I fully get what you are saying, but it sounds horrible.

#2 Updated by Adrian Ban over 1 year ago

Hi Tobias,

Why is that a problem? Fix your routing if you want a different behavior.

How I suppose to "fix" my routing if everything is dynamic? OSPF, BGP etc?
Each router has more than 3 interfaces connected. In your opinion fixing the routing is to use static routes towards the RADIUS server? Sorry, but I didn't get your idea.

Also, couldn't you just NAT RADIUS packets to whatever source IP address you want to use?

Don't like using NAT for such setups. NAT is using too much resources.

to use the bind address configuration directive and I'm using one of the loopback interface IP of my router as source IP. In this way the loopback address is distributed in the network and reachable from anywhere in the network.

Example:

lo1 is a dummy interface renamed to lo1 with IP 10.190.0.1/32.
Interface eth0 has IP 10.190.0.33/30 towards to another switch which is a L3 switch and is connected to LAN.
Interface eth1 has IP 10.190.0.37/30 to the second switch connected to LAN.
Switches are running VRRP.

Everything is running OSPF.

Let's say that the primary link on eth0 is used. Then all radius packets going out from router are using IP 10.190.0.33, right?

If link on ETH0 is going down, OSPF will use eth1 as main link towards radius. Then all packets are going out with IP 10.190.0.37, not with 10.190.0.33.

With bind address on 10.190.0.1, all packets will go out, regarding the uplink, with same 10.190.0.1.
Because all the routes are redistributed in the network with OSPF, RADIUS server will reply back to 10.190.0.1.

Hope now is much clear. Is just an option if you want to use as default behavior address 0.0.0.0 can be used, otherwise you can specify a strict binding address.

This example is prety, think to much complex routers with much more interfaces.

Kind regards,
Adrian

#3 Updated by Tobias Brunner over 1 year ago

Let's say that the primary link on eth0 is used. Then all radius packets going out from router are using IP 10.190.0.33, right?

If link on ETH0 is going down, OSPF will use eth1 as main link towards radius. Then all packets are going out with IP 10.190.0.37, not with 10.190.0.33.

So? What's the problem with that?

With bind address on 10.190.0.1, all packets will go out, regarding the uplink, with same 10.190.0.1.

You can add a static route (even multipath) with whatever source IP you like to be used to reach the RADIUS server if you prefer that (or maybe use the same IP as source for the other two routes - no idea what options your routing daemon provides).

#4 Updated by Adrian Ban over 1 year ago

Tobias Brunner wrote:

Let's say that the primary link on eth0 is used. Then all radius packets going out from router are using IP 10.190.0.33, right?

If link on ETH0 is going down, OSPF will use eth1 as main link towards radius. Then all packets are going out with IP 10.190.0.37, not with 10.190.0.33.

So? What's the problem with that?

RADIUS server should be reconfigured each time when you do changes in the network. That means even the restart of the daemon. Each interface of the router should be declared in RADIUS server. That is an ugly configuration and workaround.

With bind address on 10.190.0.1, all packets will go out, regarding the uplink, with same 10.190.0.1.

You can add a static route (even multipath) with whatever source IP you like to be used to reach the RADIUS server if you prefer that (or maybe use the same IP as source for the other two routes - no idea what options your routing daemon provides).

Using static routes with Multipath: when if the L1 link is not going down the static routes will remain up, then packets are dropped. Not a solution. Dynamic routing is avoiding this.
BFD for static routes in FRR are not implemented. Using static routes with source is not working in routing daemons. In the OS you ca do it, but as I've mentioned earlier will face a drop packets because one of the links are not good.

I did a suggestion which a lot of daemons are using, is a simple feature which can simplify a lot the RADIUS setup and routers strongswan configuration and minimise the issues.

#5 Updated by Tobias Brunner over 1 year ago

  • Category changed from configuration to libcharon

RADIUS server should be reconfigured each time when you do changes in the network. That means even the restart of the daemon. Each interface of the router should be declared in RADIUS server. That is an ugly configuration and workaround.

What are you talking about? What has this to do with what the source IP address in RADIUS packets is? Why would the RADIUS server care?

Using static routes with Multipath: when if the L1 link is not going down the static routes will remain up, then packets are dropped. Not a solution.

Hm, OK, seems that feature is intended for load-balancing and not for redundancy.

BFD for static routes in FRR are not implemented. Using static routes with source is not working in routing daemons. In the OS you ca do it, but as I've mentioned earlier will face a drop packets because one of the links are not good.

According to the documentation it should be possible to set a preferred source IP for the installed routes (see http://docs.frrouting.org/en/latest/zebra.html#clicmd-setsrcADDRESS).

I did a suggestion which a lot of daemons are using, is a simple feature which can simplify a lot the RADIUS setup and routers strongswan configuration and minimise the issues.

We don't bind to addresses in general as it usually complicates stuff a lot. And I've currently no plans to implement it in the radius plugin/libradius.

#6 Updated by Adrian Ban over 1 year ago

Tobias Brunner wrote:

RADIUS server should be reconfigured each time when you do changes in the network. That means even the restart of the daemon. Each interface of the router should be declared in RADIUS server. That is an ugly configuration and workaround.

What are you talking about? What has this to do with what the source IP address in RADIUS packets is? Why would the RADIUS server care?

You really don't know that RADIUS needs some configuration for the devices (like PPPoE AC, strongswan RADIUS client) to be configured and to permit access to query the database? You don't know that you can create multiple client access (ACs) to different setups of RADIUS based on the sourece IP of the AC?
I'm a bit amazed..

https://linux.die.net/man/5/clients.conf

Is about who has permission to access the RADIUS, as a device AC, not a subscriber.

If the RADIUS is configured to permit the packets only from 10.190.0.33 then when the link has a problem and the OSPF is rerouting the traffic towards 10.190.0.37 link, and you don't set the correct configuration to RADIUS server, the RADIUS will drop the requests.
Multiply this with 5-8 times if you have multiple link and then you have to define in RADIUS all interfaces. If you miss one, then problems occurs.

Using static routes with Multipath: when if the L1 link is not going down the static routes will remain up, then packets are dropped. Not a solution.

Hm, OK, seems that feature is intended for load-balancing and not for redundancy.

BFD for static routes in FRR are not implemented. Using static routes with source is not working in routing daemons. In the OS you ca do it, but as I've mentioned earlier will face a drop packets because one of the links are not good.

According to the documentation it should be possible to set a preferred source IP for the installed routes (see http://docs.frrouting.org/en/latest/zebra.html#clicmd-setsrcADDRESS).

This is not dynamic routing anymore, is just static with multiple paths. In case of link issue you'll get one path as blackhole.

I did a suggestion which a lot of daemons are using, is a simple feature which can simplify a lot the RADIUS setup and routers strongswan configuration and minimise the issues.

We don't bind to addresses in general as it usually complicates stuff a lot. And I've currently no plans to implement it in the radius plugin/libradius.

OK.

#7 Updated by Noel Kuntze over 1 year ago

I am not sure if you are aware that the remaining solution is the usage of iptables/nftables rules to SNAT the RADIUS packets to the required source IP. Just to make sure this is explicitly mentioned as the remaining workable solution.

#8 Updated by Tobias Brunner over 1 year ago

If the RADIUS is configured to permit the packets only from 10.190.0.33 then when the link has a problem and the OSPF is rerouting the traffic towards 10.190.0.37 link, and you don't set the correct configuration to RADIUS server, the RADIUS will drop the requests.

Again, that's a problem you create yourself if you have multiple paths to your RADIUS server you obviously have to either make the server expect traffic from all of them or you make the client use a static IP address. If the daemon on the client doesn't support the use of a specific IP address use whatever means the OS provides to do it (NAT, source IP in routes, static routes).

Multiply this with 5-8 times if you have multiple link and then you have to define in RADIUS all interfaces. If you miss one, then problems occurs.

Automate it.

This is not dynamic routing anymore, is just static with multiple paths. In case of link issue you'll get one path as blackhole.

Doesn't this just set the preferred source IP to a specific address in the installed routes (at least the option is translated to RTA_PREFSRC). That's what you want, no?

I am not sure if you are aware that the remaining solution is the usage of iptables/nftables rules to SNAT the RADIUS packets to the required source IP. Just to make sure this is explicitly mentioned as the remaining workable solution.

Thanks Noel, I mentioned that in my very first comment.

#9 Updated by Karel Hendrych about 1 year ago

Another good trick on Linux to source traffic from specific source-address is using iproute2

ip route add [destination-address] via [gw] src [source-address]

if the destination is within interface prefix then:

ip route add [destination-address] dev [eth-dev] src [source-address]

Not sure if dynamic routing software can insert such routes though. For this kind of deployments IMHO binding RADIUS client to loopback is most appropriate.

Also available in: Atom PDF