RADIUS source interface / address

I have a request for a field in the RADIUS client configuration to specify originating address of RADIUS packets.

The reason for this is so RADIUS packets always come with the same source address from the device. Take a scenario of 3 routers connected in a triangle, one of the routers has an Ethernet interface with the radius server attached. The routers are converged with a routing protocol. If one of the links of the triangle was to fail, the RADIUS packets generated from a router that normally sends its traffic across this link would be forced across the alternate link, leaving the router from a different interface and having a different source IP address.

I would also like to see a new interface type, loopback.

Both these features are available on cisco, currently I use a bridge with no interfaces as a loopback interface.

on Cisco:

interface loopback 0
ip address x.x.x.x y.y.y.y
!
ip radius source-interface loopback 0

To get around the radius source issue I have a src-nat configuration, however this is clumsy.

This would also be useful for other management features, ie syslog.

src-nat is your friend.

As I said, that’s what I am currently using, however it is clumsy, as you have to add one for every address of the router. (sometimes up to 15).

Can you comment on whether this would be looked at for a future release?

Amen.

Enough of this backasswards way of doing things. Instead of using 15 different steps to accomplish 1 single goal, just implement 1 single, more useful feature.

add a bridge but do not add any member ports to it.
add the management address to this bridge with a subnet mask of /32
add a static host route (or two) to your radius servers with a preferred src address with that of the management address.

but sure, this could have been solved alot more elegant with the radius src address attribute. it could instead be shortened and cleaner like;

add a bridge …
add the management address …
set radius src address

this way you wouldnt need to polute your routing tables with the host routes.

Also a bridge will, even if no ports are members, use quite a few more cpu cycles than a loopback device. So why not give us the ability to configure the onboard loopback interface? It’s there, why try to hide it?

sten

You cant use a static route because the gateway field is mandatory, and locking it to one gateway is pointless as it has nowhere to go if the gateway is invalid / down.

That’s what routing protocols are for.

So make it check the availability of the gateway (using either arp or icmp)
Add multiple routes with different preference (distance).

Ill just stick to my src nat rule untill mikrotik sort out a src-address feature…

Can you provide detail of your src-nat rule please?

Thank’s
Patrick

The feature was introduced a long time ago, and RADIUS clients now have a src-address parameter. You shouldn’t need those NAT rules anymore. The thread is coming up on 5 years old.

Can i set this in winbox? i cant find it? maybe i’m blind…

Thank’s
Patrick

Hi Patrick, dont think it ever made it winbox, you can set it from the terminal though:

/radius set 0 src-address=10.10.10.10

it’s in WinBox at least in v5.0