[PATCH -ocserv 4/5] Use distinct remote and local IPs when explicit_ipv[46] is specified

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux