Re: FTP NAT fails after kernel upgrade

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

 



Em 17/07/2017 20:04, Adel Belhouane escreveu:
Seems I missed an email too. To keep things very simple:
I'd say revert to the pre-kernel 4.7 way (see why it didn't work in
my other email) and keep all the rules, or switch to
nf_conntrack_helper=0, still keep all the rules, and just add these two
rules to mimic the former behaviour:
iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp
iptables -t raw -A PREROUTING -p tcp --dport 2121 -j CT --helper ftp

Copy a working configuration, like the configuration used in
production. Try to not change it beside the minimum (to prevent new
problems like missing nf_nat_ftp) and forget about "securing" the rules
for now until it works (like before).

regards,

Hi Adel, thanks for your answers so far.

Please ignore that ESTABLISHED in the place of RELATED. I was trying several things and sent it wrong in the email.

So, I did exactly what you told. I've preserved all my rules, but set nf_conntrack_helper=0, added the line at the raw table (port 21) and restarted my test machine (to be sure nothing is loaded wrongly). The policy for FORWARD is still ACCEPT just to be sure nothing is being dropped. The sysctl files are empty.

As before, from the public side I can connect but not from LAN.

I added a NAT rule for port 2121 in the test machine (available like that to the public side). Without the helper it does connect through port 2121 both from outside and inside, only failing to estabilish the data channel. If I enable the helper for that port, the connection times out while trying to estabilish the *control channel*. However, with LOG I can see it reach POSTROUTING.

Summing up: any port with the ftp helper is timing out while establishing the control channel when a LAN originated connection goes back to a host in the same LAN (via firewall's public IP). SNAT is used to deliver it to the LAN using the firewall IP.

Does anyone know why this would happen?

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