I Sent today another mail to the userlist which (hopefully) explains my problem a little better!
regards ;-) On Mon, 2004-10-11 at 14:45 +0200, Nicolas Baradakis wrote: > Raimund Sacherer wrote: > > [...] > > > But THERE is somewhere a problem i could not figure out until now: > > > > If the 62.4 and the 10.4 are on different interfaces > > (eth0=62.4/eth1=10.4) the packet is send to the roamingpartner and the > > roamingpartner answers (i verified it with tcpdump) BUT the radius > > server did not seem to receive this packet. > > I'm not sure I understand the whole explanation. Please specify who is > the radius client, who is the proxy and who is the server. (an ascii > schema can help, too) > > > I tried from localhost to connect with netcat to the proxy port 1814 and > > the server recieved something (as i typed nonsens, it put's malformed > > packet in the logfile, but it was receiving something). > > > > Netstat displayed the 62.4 and 10.4 listening on 1812 and 1813 and * > > (0.0.0.0) listening on 1814. > > In radiusd.conf, are you using the directive "bind_address" > or "listen" ? > > > Currently our implementation works very well and i also could create a > > heartbeat interface now, as it is possible to listen on more > > ip-addresses, but it is not a clean solution, i want to fix this proxy > > behavior in the right way and put my patches into radius itself soon, as > > it seems without this outstanding fixes the UDPFROMTO patch is not > > complete! > > Is this the final setup you want to implement ? > > proxy1 eth0 > +----> 62.4.e.f > client 1 vip 1 | > 62.4.a.b ---> 62.4.c.d -| proxy1 eth1 > | +-> 10.4.g.h > | | > | | proxy2 eth0 > +--|-> 62.4.m.n > client 2 vip 2 | > 10.4.i.j ---> 10.4.k.l ----| proxy2 eth1 > +-> 10.4.o.p > >
signature.asc
Description: This is a digitally signed message part
