A month has passed, many improvements added to builds, but conntrack FTP helper still remains broken
Thats how things are - the "helpers aka ALG’s have always been broken in every product.
My recommendation is to disable these.
When it comes to FTP you should setup your server for passive FTP only and forward the portrange defined in your ftp-server.
For example TCP21 + TCP10000-10099 to allow for 100 concurrent connections (in theory a session is a 5-tuple thingy aka prot+srcip+dstip+srcport+dstport but most ftp-servers out there are stupid so one port is one connection).
I still can’t figure it out. What prevents to restore the FTP helper’s state at the beginning of the year? (I continue to use the January build now)
Is there a Vyos Phabricator (the official bug tracker) ticket for the problem, do you know?
It almost to me sounds like a Kernel bug if the FTP helper isn’t working.
Yes, they know. TFTP is there too AFAIK.
I created a bug report there: “Conntrack FTP helper does not work properly”
The same question. My test bed likes below and the active FTP working fine but passive mode FTP.
FTPserver(192.168.100.220)—Vyos(conntract FTP and D-NAT) ----Client(10.199.10.42)
I pasted the relevant clip below that’s a general scene in the home network.
set interfaces ethernet eth0 address '192.168.100.254/24' set interfaces ethernet eth0 description 'HomeInternal' set interfaces ethernet eth0 hw-id '00:0c:29:4d:60:e9' set interfaces ethernet eth1 address '10.199.10.100/24' set interfaces ethernet eth1 hw-id '00:0c:29:4d:60:f3' set interfaces loopback lo set nat destination rule 100 destination port 'ftp' set nat destination rule 100 inbound-interface 'eth1' set nat destination rule 100 protocol 'tcp' set nat destination rule 100 translation address '192.168.100.220' set nat source rule 100 outbound-interface 'eth1' set nat source rule 100 source address '0.0.0.0/0' set nat source rule 100 translation address 'masquerade' set protocols static route 0.0.0.0/0 next-hop 10.199.10.254
Btw, here is my version
vyos@vyos# run show version Version: VyOS 1.4-rolling-202308260020 Release train: current Built by: firstname.lastname@example.org Built on: Sat 26 Aug 2023 00:21 UTC Build UUID: 11a85f0e-36f8-4c82-9b39-6d9e50dc3caa Build commit ID: 28e63c2dcaf1b6
I agree with you. This problem doesn’t exist in 1.3.4 LTS, but 1.4 version has this problem for a long time. Since the problem with the CLI environment in 1.3.x, I have been seeking to replace it with version 1.4, but I have not been able to do so because FTP ALG issue.
In order to make passive FTP to work through NAT:
On the FTP-server find out what the IP-address will be that the client will connect to (for example WAN of VyOS) and configure that as pasv_ip (look in the manual of the FTP server what this setting is named).
Except for the ftp-port for login (normally TCP21) you must also define a pasv_port-range. Lets say TCP 10000-10099.
On the VyOS disable any “ftp helpers” etc and instead setup a static DNAT which will forward connections arriving at WAN to the DMZ-interface (or where your FTP server physically is reachable). Ports that needs to be forwarded will in this example be TCP 21 + TCP 10000-10099.
On client use “pftp” if you use cli or if gui make sure to enable passive ftp towards this server and login by connecting to x.x.x.x:21 (or hostname.example.com:21).
Now when you login to the FTP-server at port TCP21 you will login with user/pass.
Then your FTP-client will issue a command to find out which IP-address and port it should connect to for the data-channel.
The server will respond with that pasv_ip you configured previously along with a random port out of the configured pasv_port-range.
The client will use the above information to connect to lets say x.x.x.x:10024, which the VyOS box will just do a regular destination network address translation aka DNAT (replace dstip from the WAN-IP to the IP which the FTP is reachable by the VyOS box) and forward the packet to the FTP-server.
I believe your solution should be working but it’s not the correct way to deal with it. The FTP ALG works fine in 1.3.x LTS and it obviously has some software defects that cause it can’t catch the passive FTP command as expected.
Widely enabling TCP NAT aimed at FTP server will reduce the security level in the network, especially home network doesn’t have high-level IPS/firewall system.
Yes, my example of passive FTP is the correct way to deal with this. It will also be userfriendly when your customers themselves sits behind NAT that allows for outbound connections but not incoming connections.
When you configure the portrange you make sure that no other app on the server will listen to the same portrange so the security isnt affected. Your security is broken the moment you let anything speak to the cmd-channel of the FTP server.
The ALG’s is and always have been broken no matter what the vendor is.
I used to work at Juniper Networks and I confirm SRX firewall can handle FTP connection whatever passive or active mode it is.
Another hint to prove this is a software bug is, that the Vyos 1.3.3 LTS also works fine with both types of FTP. Your solution is a mitigation solution, not a resolving solution. Hope anybody can help to fix it. ToT
I have been using Juniper ALG’s during the years and I can confirm they are broken as the ALG’s with other vendors.
The proper fix is the one I described previously.
Using the FTP helper on VyOS will expose VyOS to any wrongdoings the software of that FTP helper is doing or if its malfunctioning. So if security is your priority thats another reason for why you should disable those “helpers” aka ALG’s.
But thats just my €0.05
Could you share your test environment with Juniper ALG? I have just tested the same topology as the above posts and the FTP worked smoothly under passive and active mode. I list my environment below:
root> show version Model: junosv-firefly JUNOS Software Release [12.1X44-D20.3] root> show security alg status ALG Status : DNS : Enabled FTP : Enabled H323 : Enabled MGCP : Enabled MSRPC : Enabled PPTP : Enabled RSH : Enabled RTSP : Enabled SCCP : Enabled SIP : Enabled SQL : Enabled SUNRPC : Enabled TALK : Enabled TFTP : Enabled IKE-ESP : Disabled
Below is the session status when FTP worked under passive mode:
root> show security flow session Session ID: 220, Policy name: default-policy-00/2, Timeout: 1790, Valid In: 10.199.10.42/49176 --> 10.199.10.100/21;tcp, If: ge-0/0/1.0, Pkts: 6, Bytes: 276 Out: 192.168.100.220/21 --> 10.199.10.42/49176;tcp, If: ge-0/0/0.0, Pkts: 5, Bytes: 370 Session ID: 221, Policy name: default-policy-00/2, Timeout: 1800, Valid Resource information : FTP ALG, 2, 0 In: 10.199.10.42/49177 --> 10.199.10.100/21;tcp, If: ge-0/0/1.0, Pkts: 10, Bytes: 497 Out: 192.168.100.220/21 --> 10.199.10.42/49177;tcp, If: ge-0/0/0.0, Pkts: 9, Bytes: 659 Session ID: 222, Policy name: default-policy-00/2, Timeout: 2, Valid Resource information : FTP ALG, 2, 1 In: 10.199.10.42/49178 --> 10.199.10.100/49212;tcp, If: ge-0/0/1.0, Pkts: 1398, Bytes: 55932 Out: 192.168.100.220/49212 --> 10.199.10.42/49178;tcp, If: ge-0/0/0.0, Pkts: 3740, Bytes: 5591828 Total sessions: 3
Here is my configuration of SRX:
set interfaces ge-0/0/0 unit 0 family inet address 192.168.100.254/24 set interfaces ge-0/0/1 unit 0 family inet address 10.199.10.100/24 set routing-options static route 0.0.0.0/0 next-hop 10.199.10.254 set security nat source rule-set 100 from zone inside set security nat source rule-set 100 to zone outside set security nat source rule-set 100 rule outputSNAT match source-address 0.0.0.0/0 set security nat source rule-set 100 rule outputSNAT match destination-address 0.0.0.0/0 set security nat source rule-set 100 rule outputSNAT then source-nat interface set security nat destination pool inboundFTP address 192.168.100.220/32 set security nat destination pool inboundFTP address port 21 set security nat destination rule-set 200 from zone outside set security nat destination rule-set 200 rule inputFTP match destination-address 0.0.0.0/0 set security nat destination rule-set 200 rule inputFTP match destination-port 21 set security nat destination rule-set 200 rule inputFTP match protocol tcp set security nat destination rule-set 200 rule inputFTP then destination-nat pool inboundFTP set security policies default-policy permit-all set security zones security-zone inside host-inbound-traffic system-services all set security zones security-zone inside host-inbound-traffic protocols all set security zones security-zone inside interfaces ge-0/0/0.0 set security zones security-zone outside host-inbound-traffic system-services all set security zones security-zone outside host-inbound-traffic protocols all set security zones security-zone outside interfaces ge-0/0/1.0
I still consistently think that this situation is a software problem, whatever the bug or un-completed codes it is.
@Zamp , I see there is no progress on your bug ticket… SAD
Yes, there is silence. I do not know why. I’m starting to think that no one needs it.
Bug report available at ⚓ T5376 Conntrack FTP helper does not work properly
Unless there is something wrong with the firewall ruleset in VyOS any malfunctions in the FTP helper itself will mainly be fixed upstream at the Linux kernel or in this particular case the netfilter team:
Hopefully some VyOS maintainer will look at this shortly and can figure out if this is a config error in VyOS or if the error must be reported upstream to get fixed.
Vyos is a great project for the open-source router. It has good performance and appropriate cost, it supports most enterprise features like Cisco/PA/Juniper devices.
If possible, I think the FTP ALG should be a valuable function in NAT/Gateway feature set. The problem will be resolved in the near future, I believe.
The latest releases of 1.5-rolling-202309080021 and 1.4-rolling-202309070021 still have this problem.