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
--
Nicolas Baradakis
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
