Weird shared secret issues

[Tuc at T-B-O-H.NET]

> 
> Hi,
> 
> > 	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 1.2.3.4, but say I'm on 3.4.5.6 . Right now, If I
> > say I'm on 3.4.5.6, it still wants the secret for 1.2.3.4 .
> 
> 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)

		Thanks, Tuc