User Manager - Radius Authentication - Response send from wrong Interface

RouterOS General
1

Hello,
I have two microtik router and these routers are connected via GRE-Tunnel. Router1 has the User Manager running.
Router 2 uses the Radius Server of Router1 and I tried to send the Radius Request from the Management-Interface of Router2 to the Management-Interface of Router1, Router1 receives the Request and the Authentication is successful (User Manager Log), but now the Router1 uses the IP of the GRE-Tunnel to send the Response to Router2. Router2 displays a “Login failed” and Login is not working.
Is this the correct behaviour? Why does Router1 not send the response from the “incoming Interface” = Management Interface?
Thanks for your support.
br
Tom

PS: Workaround is working, when using the GRE-Interface of Router1 on Router2 to authenticate the user.

2

Without any configuration details it is difficult to say. By default the RADIUS client will use the address of the egress interface as the source address unless you explicitly set one, and the RADIUS server / user manager will reply to that address.

3

Configuration:

  • R1
  • WAN-IP 1.2.3.4/24
  • GRE-Tunnel-IP 10.0.0.1/30 (1.2.3.4 → 5.6.7.8 )
  • Management-IP 192.168.0.1/32


  • R2
  • WAN-IP 5.6.7.8/24
  • GRE-Tunnel-IP 10.0.0.2/30 (5.6.7.8 → 1.2.3.4 )
  • Management-IP 192.168.0.2/32

Management-IP is proviced via OSPF and this is working fine and I can ping the R1-Management-IP from the R2-Management-IP.

Radius-Configuration:

  • Radius-Configuration of R2 which is not working: Server: 192.168.0.1 (Source-Add: 192.168.0.2)
  • Packetsniffer @ R2: 192.168.0.2:xxxxx → 192.168.0.1:1812 => OK
  • Packetsniffer @ R1: 192.168.0.2:xxxxx → 192.168.0.1:1812 => OK
  • Radius-Log: Authentication successful
  • Packetsniffer @ R1: 10.0.0.1:1812 → 10.0.0.2:xxxxx => NOK
  • R2-Login failed (timeout @ radius packet log)


  • Radius-Configuration of R2 which is working: Server: 10.0.0.1 (Source-Add: 10.0.0.2)
  • Packetsniffer @ R2: 10.0.0.2:xxxxx → 10.0.0.1:1812 => OK
  • Packetsniffer @ R1: 10.0.0.2:xxxxx → 10.0.0.1:1812 => OK
  • Radius-Log: Authentication successful
  • Packetsniffer @ R1: 10.0.0.1:1812 → 10.0.0.2:xxxxx => OK
  • Packetsniffer @ R2: 10.0.0.1:1812 → 10.0.0.2:xxxxx => OK
  • R2-Login successful

My Questions:

  • Why does the Radius Server doesn’t use the incoming interface/ip to send the replys?


  • Why is the login not working at the first configuration? I could not find any blocks at the firewall.

Thanks for your support,
Tom

4

We set the RADIUS source address to a loopback /32 on each Mikrotik and tunnel traffic to FreeRADIUS based servers over L2TP/IPsec tunnels (rather than GRE) without issue. As your user manager and tunnel endpoints are on the same device it isn’t possible to determine the exact source of the problem without seeing the full packet dumps. It is most odd that the server replies both from a different address (10.0.0.1) to the received destination (192.168.0.1), AND to a different address (10.0.0.2) from the received source (192.168.0.2) - those packet dump addresses are the tunnel endpoints rather than tunnelled contents.

5

Thanks for the reply. I’m using the loopback-interfaces to send the packets and what I can see at the recieving device (UserManager & GRE Tunnel end point), the Router/UserManager receives the packet with the correct loopback ip addresses; I also see a successful authentication at the UserManager log. The response is then send back with the wrong IP’s and I have no idea why and the sending router does not accept this packet and the authentication times out.
br
Tom

6

It does sound like a bug, you could report it to Mikrotik support.

7

I reported the issue to MicroTik.