On Sun, Sep 15, 2013 at 12:52 AM, Eliezer Croitoru <eliezer@xxxxxxxxxxxx> wrote: > I have found the problem and I will rephrase the problem description: > While using tproxy the main issue is that the ports of the source IP is NOPE. As I said before, it's NOT related to TPROXY code at all. Same problem exists, even when you try to bind with 2+ local IPs. Check both scenarios with my test script provided above. > beeing decreased to half for the same pair of ip:Xport to ip:Xport. > Which means that 192.168.1.1 cannot connect like regular proxy to 65k > ports but to 32k ports which makes IP "cheaper". > it's the same for server and client both.. > While using the port range of: > # cat /proc/sys/net/ipv4/ip_local_port_range > 32768 32867 > #end > the main issue is that the OS tries to bind using a 0 value maximum > ports per IP by the above mentioned value. Let me rephrase the issue. With the above config (100 ports allowed for auto-selection) the maximum number of ports you can assign is exactly 100. But it has to be n*100, where n is the number of IPs you use (either local or remote with TPROXY) > the kernel itself wont even try to bind an already binded ip+port so > there is no need for the upper layers of the user-land to "recover" from > such a state. > leaving these matters to the kernel level is much more appropriate from > any aspect you look at the OS. That's for sure. The problem is that I don't believe the kernel guys will fix this issue soon. So we have to adapt on application layer. Niki
