dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
702
share rss forum feed

Bigpaddy_Irl

join:2005-12-12
Ireland

radius timeouts

Hi lads, I posted this on another forum, but hepefully I will get a quicker answer here.

My core router which had usermanager installed on it was sitting at the edge with a lan ip of 10.11.13.1.
So I decided to install a rb1200 router on 10.11.13.1 and just move the old server over to 10.11.13.50 and disable all the routing and natting so I could have a standalone radius server.
All my rb750 pppoe servers are authenticating fine, after I changed the radius ip to 10.11.13.50. These are the ones with wan ips of 10.11.13.0/24 and connected directly to 10.11.13.1.

But I have 2 other rb750 pppoe servers sitting behind another rb750 server which is directly connected to 10.11.13.1
I am getting radius time-outs on these 2 remote pppoe servers. They can ping 10.11.13.50, and 10.11.13.50 can ping them.

What could be wrong? My whole network is static routed.

UPDATE
Using torch. the pppoe requests from the remote pppoe servers are getting to 10.11.13.1 which is my core router.
Using torch on my radius server which is 10.11.13.50 and on the same lan as my core router, it is not receiving anything from the remote pppoe's.
It is as though the core router does not know where to send the packets on to.


warwick

join:2009-06-05
Hollywood, FL
At first glance it seems like an arp issue. As you have so many things behind so many things (haha) try turning on proxy-arp on the relevant interface(s) to see if it helps.

manually editing the arp may help as well.

Bigpaddy_Irl

join:2005-12-12
Ireland
Click for full size
This is torch on the core router. looking at it now, i actually think the core is forwarding on the requests.
10.40.238 is the remote radius server.

Bigpaddy_Irl

join:2005-12-12
Ireland
Click for full size
here is torch from the first pppoe server away from the core.
The problematic pppoe servers are behind this.
As you can see, there is no tx packets, only rx.

Proxy are didnt help either.


Rhaas
Premium
join:2005-12-19
Bernie, MO
reply to Bigpaddy_Irl
said by Bigpaddy_Irl:

This is torch on the core router. looking at it now, i actually think the core is forwarding on the requests.
10.40.238 is the remote radius server.

Looks as though you have some natting going on. The responses are being sent directly to 10.11.13.1 instead of 10.12.40.238.
--
I survived Hale-Bopp!

Bigpaddy_Irl

join:2005-12-12
Ireland
Yes I am natting the whole 10.0.0.0 range.

Bigpaddy_Irl

join:2005-12-12
Ireland
Ok I see now whats happening. The radius server is seeing all the remote pppoe servers coming in as 10.11.13.1, and not their unique ips as I have configured in in the router setup in usermanager.
For instance, the radius server should see one of my pppoe servers talking to it on 10.12.40.253, but instead it sees it coming in at 10.11.13.1. As soon as I change this ip in radius, they all connect.

So how do I go about this? I am sure its just a route to add somewhere?

Bigpaddy_Irl

join:2005-12-12
Ireland
reply to Bigpaddy_Irl

Re: radius timeouts SOLVED :)

I dont believe it.......but I had the 10.12.40.0/24 range natted which is the wan range of both remote pppoe servers.

Amazing it is how quick you over look the simplest things when your flustered!


Rhaas
Premium
join:2005-12-19
Bernie, MO

1 recommendation

Yep, that was what I was getting at since the responses were going back to your core router and not to the pppoe termination server.
--
I survived Hale-Bopp!


DaDawgs
Premium
join:2010-08-02
Deltaville, VA
Good solve.


TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5
reply to Bigpaddy_Irl

Re: radius timeouts

I was going to suggest making sure that the new 10.11.13.1 had a route for the subnet that the failing hosts sit in pointing towards the RB750 that they sit behind (if that makes sense..)

Sounded like although the failing hosts know how to get to 10.11.13.1, 10.11.13.1 doesnt know how to get back to them. Classic routing issue.