On 26.01.17 08:41, Alexander wrote:
It seems that I have solved the issue by using nf_conntrack_ftp and
redirecting "NEW,RELATED" traffic to squid:
ftp_port 2121 intercept
modprobe nf_conntrack_ftp ports=2121
iptables -t nat -A PREROUTING -p tcp --dport 21 -j REDIRECT --to-port 2121
iptables
Well, actually these rules are just a kind of proof of concept and there is
something to think about later. The redirection rule should be more precise
and include destination address. Also, 'NEW' state should probably be
excluded from the list.
--
View this message in context:
On Thursday 26 January 2017 at 17:41:21, Alexander wrote:
> It seems that I have solved the issue by using nf_conntrack_ftp and
> redirecting "NEW,RELATED" traffic to squid:
Excellent news.
> ftp_port 2121 intercept
>
> modprobe nf_conntrack_ftp ports=2121
>
> iptables -t nat -A PREROUTING -p
It seems that I have solved the issue by using nf_conntrack_ftp and
redirecting "NEW,RELATED" traffic to squid:
ftp_port 2121 intercept
modprobe nf_conntrack_ftp ports=2121
iptables -t nat -A PREROUTING -p tcp --dport 21 -j REDIRECT --to-port 2121
iptables -t nat -A PREROUTING -p tcp -m state
On 01/23/2017 12:18 PM, Alexander wrote:
> 2017-01-23 21:41 GMT+03:00 Alex Rousskov:
> It is possible that Squid needs a knob to handle your use
> case differently. However, I am pretty sure that somebody does want
> Squid to do what it does know so we should not change Squid behavior
2017-01-23 21:41 GMT+03:00 Alex Rousskov :
>
> Needless to say, your specific needs may differ from that general
> principle. It is possible that Squid needs a knob to handle your use
> case differently. However, I am pretty sure that somebody does want
> Squid
On 01/23/2017 11:11 AM, Alexander wrote:
> Actually, a PASV-handling logic looks a bit strange to me. In
> Ftp::Server::handlePasvReply() there is a comment:
>
> "In interception setups, we combine remote server address with a local port
> number and hope that traffic will be redirected to us."
>
On 01/23/2017 03:11 AM, Alexander wrote:
> 3. Squid opens a local port and sends it back to client via the "Entering
> passive mode" reply. Seems to be ok, but a client sees a real server's IP
> address, not a squid's one. So when a client tries to connect to a server,
> it gets ECONNREFUSED
Actually, a PASV-handling logic looks a bit strange to me. In
Ftp::Server::handlePasvReply() there is a comment:
"In interception setups, we combine remote server address with a local port
number and hope that traffic will be redirected to us."
How is it supposed to work? A client receives
Just tried it out with REDIRECT rule. Still no luck, but now Filezilla client
reports ECONNREFUSED error. I do not see any critical errors in squid's
output, however the following thing is suspicious:
2017/01/20 19:10:11.604| 33,3| FtpServer.cc(1655) checkDataConnPost: missing
client data conn:
On 23/01/2017 2:49 a.m., Alexander wrote:
> As far as I remember, I have tried both options, REDIRECT and TPROXY, but
> TPROXY is the preferred one for us. I will try one more time on Monday.
> However, I suppose that something else prevents squid from working properly.
> Maybe on of sysctls, like
As far as I remember, I have tried both options, REDIRECT and TPROXY, but
TPROXY is the preferred one for us. I will try one more time on Monday.
However, I suppose that something else prevents squid from working properly.
Maybe on of sysctls, like net.ipv4.ip_nonlocal_bind, will do the trick.
On 20/01/2017 9:40 p.m., Alexander wrote:
> Hello, I have a question regarding a native FTP relay (squid's version is
> 3.5.23).
Have you tried NAT intercept for the FTP port?
TPROXY has some low-level things including socket mapping that might not
go so well with how FTP uses multiple
Hello, I have a question regarding a native FTP relay (squid's version is
3.5.23).
I've tried to test this feature like this:
[Filezilla Client, 1.1.1.2] <-> [ Router: iptables + squid ]
<-> [vsftpd server, 5.5.5.10]
The router is CentOS 6.5 machine. Firewall settings are:
ip route
14 matches
Mail list logo