On Mon, Feb 9, 2015 at 6:06 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > On Mon, Feb 9, 2015 at 2:26 AM, Kevin Cernekee <cernekee at gmail.com> wrote: >> Currently the code sets the local interface IP to the same value as the >> P-t-P IP: >> tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 >> inet addr:192.168.63.1 P-t-P:192.168.63.1 Mask:255.255.255.0 >> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1341 Metric:1 >> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:500 >> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) >> This doesn't seem to get things routed correctly. e.g. pinging 192.168.63.1 >> from the ocserv gateway just loops traffic back to the local machine instead >> of pinging the client. >> So instead we'll set LIP = RIP + 1. This isn't terribly intuitive (an >> administrator might try to number consecutive users 192.168.1.1, 192.168.1.2, >> 192.168.1.3, ...) but it's better than the current situation. Maybe at some >> point, fixed IPs should also make use of the hash table. > > The original approach is nasty, but setting LIP=RIP+1 is pretty much > nastier. The single IP approach was used mainly for radius where the > server will certainly will not know about the LIP=RIP+1 convention, > and there will be very hard to track bugs. I think that leaving it > like that is better than the alternative... When LIP=RIP I am not able to pass any traffic at all. Is this actually working correctly for RADIUS users? Maybe I am missing something obvious...
