VyOS 1.4: FTP still remains broken

Bugs
, , ,
1

A month has passed, many improvements added to builds, but conntrack FTP helper still remains broken :frowning:

2

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

1 Like
3

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)

1 Like
4

Hi @Zamp

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.

5

Hi tjh
Yes, they know. TFTP is there too AFAIK.

6

Hi @Zamp .
I’ve found your previous entry in forum, but I wasn’t able to find a track in https://vyos.dev
Can you generate a bug report with as many details as possible, so we can check it?

7

Hi n.fort
I created a bug report there: “Conntrack FTP helper does not work properly”

1 Like
8

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:         [email protected]
Built on:         Sat 26 Aug 2023 00:21 UTC
Build UUID:       11a85f0e-36f8-4c82-9b39-6d9e50dc3caa
Build commit ID:  28e63c2dcaf1b6
9

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.

10

In order to make passive FTP to work through NAT:

  1. 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).

  2. Except for the ftp-port for login (normally TCP21) you must also define a pasv_port-range. Lets say TCP 10000-10099.

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

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

11

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.

12

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.

13

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

14

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

15

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

16

Yes, there is silence. I do not know why. I’m starting to think that no one needs it.

17

Bug report available at ⚓ T5376 Conntrack FTP helper does not work properly

18

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:

https://wiki.nftables.org/wiki-nftables/index.php/Conntrack_helpers

https://bugzilla.netfilter.org/

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.

19

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.

20

The latest releases of 1.5-rolling-202309080021 and 1.4-rolling-202309070021 still have this problem.