Weird shared secret issues
Tuc at T-B-O-H.NET
ml at t-b-o-h.net
Sun May 4 18:49:56 CEST 2008
> > Tech calls in and say that he can't get an appliance working in the field.
> > I ask him what secret he's using and the IP address of the appliance. I want to
> > be able to be locally logged onto the radius server and use radtest/radclient/rad????
> > to be able to query radius asking "If I was IP, and I gave you SECRET, would you
> > authorize me?".
> > So I want to be on 126.96.36.199, but say I'm on 188.8.131.52 . Right now, If I
> > say I'm on 184.108.40.206, it still wants the secret for 220.127.116.11 .
> you want to spoof the source address? tricky. one 'easy' way to do this would
> be to create a local VPN/GRE tunnel on the linux box under which you could
> emulate a remote link.
> configure freeradius to also listen on that virtual address, run the
> radclient with the destination being the end point of the VPN - the
> linux routing tables would then come into play. you'd have to
> reconfigure the VPN end addresses etc each time to emulate an
> outside world link...but it would work.
Not worth it. All I'm looking to do is get programatic confirmation
that the ip/secret combination in the field is correct. Since this is an
appliance, not an OS, I don't have access to radtest on the appliance. To
have someone start setting up VPN/GRE/etc is more hassle than its worth.
I just have to tell the tech to RTFD closer. I was just hoping I could
put together a local form on a webserver that could shell out to a script
to make the test.
We'll just have to suffer. :) (Or ask the manufacturer to include
a utility in the "diagnostic" section)
More information about the Freeradius-Users