Re: Losing connection between nat and filter tables

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

 



Hi Pascal, thank you for clarifying the behavior of the rp_filter. And yes, the two interfaces are in the same network, but it's a limitation that our ISP imposes to us, as we have a limited range of public IPs in only one /28 subnet. The objective this "messy" configuration is that two different groups of users have access to different FTP sites without having to set a non default port. My only choice was to do a DNAT based on the destination IP (even though they are on the same network).
Would you do that in a different way? I really apreciate your help!

Em 10/5/2014 14:21, Pascal Hambourg escreveu:
Hello,

Bruno de Paula Larini a écrit :
Wow, thank you Mart! I didn't really think that the rp_filter would have
anything to do with it, but in fact it had!
Of course it does, and it's all your fault.
Either eth1 and eth2 are actually connected to the same network and
connecting several interfaces to the same network is wrong and useless
in most cases, or they are not and defining the same subnets on several
interfaces which are connected to different networks is wrong. In either
case, it's wrong. Why did you do so ?

Even though I had disabled
for "all" interfaces, it seems that the rp_filter files for each
interface overlaps "all".
It doesn't overlap. Both values are combined using the MAX operator.

   rp_filter functional value for $iface = MAX (all, $iface)

All this and much more is detailed in ip-sysctl.txt.

But unlike the eth1 interface, the RELATED state isn't allowing (or
recognizing) the data channel. After doing a DNAT from port 49152 to
65535, the default data ports for MS FTP, I can now successfully connect
through the second interface.
I'm afraid that's because you messed with the FTP control port. By
default the FTP conntrack monitors only the port 21. You can either
specify both 21 and 2121 in the port= option when you load the
nf_conntrack_ftp module, or DNAT the second address to an IP alias
address assigned to the same server, so that you don't need to change
the port.




--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux