Hugh Irvine wrote:
>
> Salut Fr�d�ric - comment va la belle France?
Paris is very nice without parisians !
>
> On Fri, 30 Jul 1999, Fr�d�ric GARGULA wrote:
> > My old Radius proxy is dead, so I'm building a new one using Radiator.
> >
>
> Excellent idea!
I will be very very happy when our customers will be able to connect...
>
> > The old one was running Radius DTC 2.03.
> > I didn't find the configuration file, but I found the users file.
> > In that file, there is the config for handling runneling from one of the
> > clients.
> >
>
> I presume that all of your equipment is DTC?
I must explain a little thing : We are an ISP, and we have many POPs.
But to extend the number of our POPs, we buy access from SIRIS, a french
Telecom Operator.
Our customers can connect using a national dialup number, which is owned
by SIRIS
Our trouble is that SIRIS uses a L2F tunnel. To correctly answer to the
incoming requests from SIRIS's servers, we have to add this attributes :
Tunnel-Type = Tunnel-L2F,
Tunnel-Medium-Type = Tunnel-IP,
Tunnel-Client-Endpoint = "[EMAIL PROTECTED]",
Tunnel-Server-Endpoint = "@toto_example",
Tunnel-Password = "yyyyyy"
to the incoming request.
Those request may arrivve from two Radius Servers. So I have two
<Client> clauses in my radius.cfg file.
In the old configuration, those attributes was injected in the incoming
in the users file. We had a line in the users file that filter incoming
requests from a particular client :
DEFAULT Password = "PROXY", Suffix="@netclic.fr", DTC-AP-Name="tnt"
^^^^^^^^^^^^^^^^
(in this example, we had a #ap:tnt entry in the clients files,
describing the ip address and secret for tnt client.
>
> All of this looks quite straightforward, provided we have the correct radius
> dictionary that defines the above attributes. Have you found that?
>
> >
> > My question is : How do I convert that config to suit Radiator ?
> > I think I can use a
> > <Realm toto.org>
> > <AuthBy RADIUS>
> > Host radius.toto.org
> > AuthPort 1812
> > AcctPort 1813
> > Secret topsecret
> > </AuthBy>
> > </Realm>
> >
> You will not be able to do this with a <Realm toto.org>, as it is
> the same in both cases, so I think Handlers would be better in this case.
How can I differentiate incoming request by the client ? those request
are with same Realm...
> I will also need to know how your other users are defined, and how they enter
> their usernames to verify that my suggestions will work.
with have many realm : some with tunnel connection and non-tunnel
connection.
We can suppose that for each realm, there are two cases : with tunnel
(incoming from SIRIS) and without tunnel (incoming from our POPs)
>
> My assumption here is that the tunnel creation is part of the user
> authentication - there is another possibility too, which is that the tunnel
> creation occurs as a separate transaction before the user is authenticated.
> However based on the two fragments that you have provided it looks to me like
> its part of the user authentication.
>
We don't create the tunnel. the tunnel is created, and we must reply in
it. It's SIRS that create the tunnel.
I think we just have to add the tunnel attributes the the incoming
request, before forwarding it to the correct Radius Server.
> # Standard configuration parameters
>
> Foreground
> LogStdout
> LogDir .....
> DbDir .....
> AuthPort 1812
> AcctPort 1813
>
> <Client .....>
> .....
> </Client>
>
> # Define a Handler for "ClientWithTunnel"
> <Handler DTC-AP-Name="ClientWithTunnel">
I can't use DTC-AP-Name because using the DTC Radius server, it
correspond to a specific Radius client IP address...
> <AuthBy FILE>
> Filename ....
> AddToReply User-Service = 2,
> DTC-Auth-Allow = "",
> DTC-Auth-Port = 1812,
> DTC-Auth-Server = xxx.xxx.xxx.xxx,
> DTC-Auth-Secret = "topsecret",
> DTC-Acct-Port = 1813,
> DTC-Acct-Server = xxx.xxx.xxx.xxx,
> Tunnel-Type = Tunnel-L2F,
> Tunnel-Medium-Type = Tunnel-IP,
> Tunnel-Client-Endpoint = "[EMAIL PROTECTED]",
> Tunnel-Server-Endpoint = "@toto_example",
> Tunnel-Password = "yyyyyy"
> </AuthBy>
> </Handler>
>
I can't send the tunnel parameters at each time, but only if the client
ip address is from SIRIS, or if the NAS-Identifier field begins with
"SH"
> #Define a Handler for "ClientWithoutTunnel"
> <Handler DTC-AP-Name="ClientWithoutTunnel">
> <AuthBy FILE>
> Filename ......
> AddToReply Service-Type = Framed-User,
> DTC-Auth-Allow = "",
> DTC-Auth-Port = 1812,
> DTC-Auth-Server = xxx.xxx.xxx.xxx,
> DTC-Auth-Secret = "topsecret",
> DTC-Acct-Port = 1813
> </AuthBy>
> </Handler>
>
I must try this, but DTC-AP-Name="ClientWithoutTunnel" couldn't be
defined in Radiator because it was a parameter of the DTC Radius Server
(The one that is dead).
> >
> > but I have to make the difference between clients that use the tunnel
> > and client that don't use it
> >
> > (in the old users file, I have also this :
> >
> > DEFAULT Password = "PROXY", Suffix="@toto.org",
> > DTC-AP-Name="ClientWithoutTunnel"
> > Service-Type = Framed-User,
> > DTC-Auth-Allow = "",
> > DTC-Auth-Port = 1812,
> > DTC-Auth-Server = xxx.xxx.xxx.xxx,
> > DTC-Auth-Secret = "topsecret",
> > DTC-Acct-Port = 1813,
> > )
> >
> > How can I handle the tunnel, depending of the client ?
> >
>
> There must be another part of the original configuration (perhaps in the
> equipment itself) that generates the DTC-AP-Name check item.
The equipment can't play a role here :
In the case of the tunnel, the equipment is a Shiva.
Thanks a lot for Help...
--
Frederic GARGULA
Ingenieur Reseaux & Systemes
EASYNET France
Tel.: +33 1 44 54 70 55
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
