Core MT RB1100AHx2 RouterOS 6.6 as openvpn server with address 172.31.1.1/32 and also loopback bridge 10.0.0.1/32.
RB 951-2n RouterOS 6.7 as vpn client with address 172.31.1.2/32 and loopback bridge 10.13.13.1/24. There is DHCP network for local clients at loopback bridge defined.
Both of routers included onto OSPF backbone network, either (2) itself and all machines behind can reach 10.0.0.1 successfuly.
There is User Manager server on (1) and radius client on (2).
I want machines behind (2) receives addresses from (1) via radius protocol.
According to OSPF ideology, i wish to set radius server address at (2) to 10.0.0.1, because in theory route to (1) can be changed via other router(s), and i want to be able to receive addresses from 10.0.0.1 finally, even if there is no direct point-to-point connection between (1) and (2).
Point 1.
Radius server address at (2) defined as 172.31.1.1. All machines behind (2) can receive addresses and other settings correctly.
Point 2.
Radius server ad (2) defined as 10.0.0.1. Machines can NOT receive addresses, and logs at (2) full of messages like “radius server is not responding”.
I have tracked all connections and there is what i found out actually.
Step 0. (2) Receives DHCP request from machine behind.
Step 1. (2) initiates connection to (1), at both routers i can see connections from 10.13.13.1 to 10.0.0.1.
Step 2. (1) keep receiving connection from 10.13.13.1 to 10.0.0.1 (with only RX bytes), BUT starts connection from 172.31.1.1 to 10.13.13.1 with response.
As result, dhcp request always fails. After every failed request (2) adds new entry to log: “radius server is not responding”.
Can this configuration be alive? I am saddened with fact i should set radius server address as point-to-point address only.
You always have to set the Radius Server address as the real interface address, not the loopbacks addresses. The actual data usually goes between real addresses and NOT between loopback address.
I have enourmous network with lots of addresses. The radius server has loopback address: 10.0.0.1, this address is never going to reply to radius requests because actual reply would be sent from reald interface address. Imagine you have 3 incoming interfaces with addresses 10.10.10.30/30, 10.174.0.1/24 and 172.31.1.16/24. All you need is to track which interface is actually serving for radius requests and to set one of these addresses on each radius client. Depending on network topology these addresses may be various of course on various segments.
So, in a nutshell: You shoud set the real ip address of any radius server interface, NOT the loopback one.
I found a similar behavior with DHCP relay servers. If the master server was bound on a loop interface, the service wasn’t responding to the relayed requests. The workaround I found was to build a DHCP server for each of the possible interfaces, and to set all of them to use the same IP pool for leases and if I made static leases, I needed to make sure that they could be used by all servers and not just the one where I clicked “make static”
If you have multiple DHCP relays, then this can snowball quickly.
I’d recommend a dedicated UserMan server using a bridge interface as the server’s IP - and connect two links to two different routers and have the two routers use VRRP for first-hop redundancy - both of them can advertise the server network into OSPF so this would give you your redundant links, but not require any modifications if the network topology changes.
Another method might be to define all of 10.0.0.1’s physical interface addresses as radius servers in the clients and let them work like “primary/backup radius server pool” on the clients.