(RADIATOR) Does this ring a bell, anyone?

[Prins, R.]

Thanks for replying, but I am afraid it isn't that simple. A diff of the
configs of "Radiator 1" and "Radiator 2" show no different secrets
between the two. Only the NAS-IP_Address in the Handler clause is
different betweeen the two (Outside vs inside adress of the Firewall 1).

					Greetings, Ryko Prins

-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: 22 februari 2005 0:44
To: Prins, R. 
Cc: radiator at open.com.au
Subject: Re: (RADIATOR) Does this ring a bell, anyone?



Hello Ryko -

This is almost certainly a problem with the shared secrets somewhere 
along the line.

Check the secrets in the AuthBy RADIUS clause(s) and the corresponding 
Client clause(s).

regards

Hugh


On 22 Feb 2005, at 02:30, Prins, R. wrote:

>
>
>
> I am migrating my radius servers from one place to another, and try to
> do that without downtime for users. At the moment I have the following

> setup (Ascii graphics, use non-proportional font):
>
>    City Center                                   Campus
>
>
> Radiator 2-----Firewall 2 --------- Firewall 1 ----- Radiator 1
>    |                                                      |
>    |                                                      |
>    |                                                      |
>    +-----------------External Radiator--------------------+
>
>
> I am running Radiator 3.11 on both servers. The external Radiator is 
> 3.8
>
> Firewalls are Cisco 6500 FWSM with latest software release Clients are
> behind Firewall 1, which enforces autenthication
>
> All radius request are forwarded to the external Radius Server either
> through Radiator 1 or Radiator 2 All firewalls let Radius traffic pass

> Requests to Radiator 1 are handled smoothly Requests to Radiator 2 
> give problems
>
> Radiator 2 says "Access rejected for user at realm: Proxied"
> The External Radiator says then "Access rejected for user at realm: Bad
> Password" It seems (from the password log file on the External
> Radiator)
> that passwords are received scrambled and therefore are unequal to the

> password in the database. I can't imagine what might spontaneously 
> scramble a password underway.
>
> I know it is a strange problem, but I hope maybe this rings a bell
> with anyone
>
>
> 	
> Greetings, Ryko Prins
> 	
> Leiden University,
> 	
> The Netherlands
>
> ----------------------------------------
> I am using the free version of SPAMfighter for private users. It has
> removed 13415 spam emails to date. Paying users do not have this 
> message in their emails. Try www.SPAMfighter.com for free now!
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with 'unsubscribe
> radiator' in the body of the message.
>
>

NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive 
(www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


----------------------------------------
I am using the free version of SPAMfighter for private users. It has
removed 13415 spam emails to date. Paying users do not have this message
in their emails. Try www.SPAMfighter.com for free now!

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.