iptables/netfilter: “nf_nat_ftp” is not working well with recent Linux kernels

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












I'm facing the following issue with Linux kernel 4.10-28-generic, embedded in Ubuntu-16.04.02-LTE.
My machine has two ethernet adapters, namely the following ones:



enp0s3: 198.168.56.2 (internal network)

enp0s8: 172.22.181.41 (external network)



In the internal network, connected to enp0s3, there is an FTP server and a telnet server I want to access from the external
network connected through enp0s8.

The FTP mode is requested to be active.



To accomplish this task I use the following iptables rules:



modprobe nf_conntrack_ftp 
modprobe nf_nat_ftp
sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

## Masquerade settings
iptables -A POSTROUTING -t nat -o enp0s3 -j MASQUERADE
iptables -A POSTROUTING -t nat -o enp0s8 -j MASQUERADE

## ftp rules
iptables -t nat -I PREROUTING -p tcp -m tcp --dport 20 -i enp0s8 -j DNAT --to-destination 192.168.56.2:20
iptables -t nat -I PREROUTING -p tcp -m tcp --dport 21 -i enp0s8 -j DNAT --to-destination 192.168.56.2
iptables -t nat -I PREROUTING -p tcp -m tcp --dport 1024:65535 -i enp0s8 -j DNAT --to-destination 192.168.56.2:1024-65535

## telnet rules
iptables -t nat -I PREROUTING -p tcp -m tcp --dport 23 -i enp0s8 -j DNAT --to-destination 192.168.56.2`


These rules work well with Ubuntu-10, that has Linux kernel 2.6.32-38-generic, but with the new kernel data connection can't be established: when the client issues the PORT command, the server receives the IP address of the external network and not that of the internal one. According to "netstat" running on server side, it seems that the module "nf_nat_ftp" is not working well, that is it does not substitute the client IP address (external address) with that of the input interface enp0s8, (internal address) before forwarding the command to the server. For this reason the server get stuck trying to establish a connection with the external IP address (SYN state).

No problem with the FTP working in passive mode and with telnet connection as well.



Could you give me a suggestion to overcome this issue? Is it a regression or am I expected to change my iptables rules according to some new requirements?



Thank you in advance!



Best regards,
Stefano







share|improve this question
























    up vote
    0
    down vote

    favorite












    I'm facing the following issue with Linux kernel 4.10-28-generic, embedded in Ubuntu-16.04.02-LTE.
    My machine has two ethernet adapters, namely the following ones:



    enp0s3: 198.168.56.2 (internal network)

    enp0s8: 172.22.181.41 (external network)



    In the internal network, connected to enp0s3, there is an FTP server and a telnet server I want to access from the external
    network connected through enp0s8.

    The FTP mode is requested to be active.



    To accomplish this task I use the following iptables rules:



    modprobe nf_conntrack_ftp 
    modprobe nf_nat_ftp
    sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

    ## Masquerade settings
    iptables -A POSTROUTING -t nat -o enp0s3 -j MASQUERADE
    iptables -A POSTROUTING -t nat -o enp0s8 -j MASQUERADE

    ## ftp rules
    iptables -t nat -I PREROUTING -p tcp -m tcp --dport 20 -i enp0s8 -j DNAT --to-destination 192.168.56.2:20
    iptables -t nat -I PREROUTING -p tcp -m tcp --dport 21 -i enp0s8 -j DNAT --to-destination 192.168.56.2
    iptables -t nat -I PREROUTING -p tcp -m tcp --dport 1024:65535 -i enp0s8 -j DNAT --to-destination 192.168.56.2:1024-65535

    ## telnet rules
    iptables -t nat -I PREROUTING -p tcp -m tcp --dport 23 -i enp0s8 -j DNAT --to-destination 192.168.56.2`


    These rules work well with Ubuntu-10, that has Linux kernel 2.6.32-38-generic, but with the new kernel data connection can't be established: when the client issues the PORT command, the server receives the IP address of the external network and not that of the internal one. According to "netstat" running on server side, it seems that the module "nf_nat_ftp" is not working well, that is it does not substitute the client IP address (external address) with that of the input interface enp0s8, (internal address) before forwarding the command to the server. For this reason the server get stuck trying to establish a connection with the external IP address (SYN state).

    No problem with the FTP working in passive mode and with telnet connection as well.



    Could you give me a suggestion to overcome this issue? Is it a regression or am I expected to change my iptables rules according to some new requirements?



    Thank you in advance!



    Best regards,
    Stefano







    share|improve this question






















      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I'm facing the following issue with Linux kernel 4.10-28-generic, embedded in Ubuntu-16.04.02-LTE.
      My machine has two ethernet adapters, namely the following ones:



      enp0s3: 198.168.56.2 (internal network)

      enp0s8: 172.22.181.41 (external network)



      In the internal network, connected to enp0s3, there is an FTP server and a telnet server I want to access from the external
      network connected through enp0s8.

      The FTP mode is requested to be active.



      To accomplish this task I use the following iptables rules:



      modprobe nf_conntrack_ftp 
      modprobe nf_nat_ftp
      sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

      ## Masquerade settings
      iptables -A POSTROUTING -t nat -o enp0s3 -j MASQUERADE
      iptables -A POSTROUTING -t nat -o enp0s8 -j MASQUERADE

      ## ftp rules
      iptables -t nat -I PREROUTING -p tcp -m tcp --dport 20 -i enp0s8 -j DNAT --to-destination 192.168.56.2:20
      iptables -t nat -I PREROUTING -p tcp -m tcp --dport 21 -i enp0s8 -j DNAT --to-destination 192.168.56.2
      iptables -t nat -I PREROUTING -p tcp -m tcp --dport 1024:65535 -i enp0s8 -j DNAT --to-destination 192.168.56.2:1024-65535

      ## telnet rules
      iptables -t nat -I PREROUTING -p tcp -m tcp --dport 23 -i enp0s8 -j DNAT --to-destination 192.168.56.2`


      These rules work well with Ubuntu-10, that has Linux kernel 2.6.32-38-generic, but with the new kernel data connection can't be established: when the client issues the PORT command, the server receives the IP address of the external network and not that of the internal one. According to "netstat" running on server side, it seems that the module "nf_nat_ftp" is not working well, that is it does not substitute the client IP address (external address) with that of the input interface enp0s8, (internal address) before forwarding the command to the server. For this reason the server get stuck trying to establish a connection with the external IP address (SYN state).

      No problem with the FTP working in passive mode and with telnet connection as well.



      Could you give me a suggestion to overcome this issue? Is it a regression or am I expected to change my iptables rules according to some new requirements?



      Thank you in advance!



      Best regards,
      Stefano







      share|improve this question












      I'm facing the following issue with Linux kernel 4.10-28-generic, embedded in Ubuntu-16.04.02-LTE.
      My machine has two ethernet adapters, namely the following ones:



      enp0s3: 198.168.56.2 (internal network)

      enp0s8: 172.22.181.41 (external network)



      In the internal network, connected to enp0s3, there is an FTP server and a telnet server I want to access from the external
      network connected through enp0s8.

      The FTP mode is requested to be active.



      To accomplish this task I use the following iptables rules:



      modprobe nf_conntrack_ftp 
      modprobe nf_nat_ftp
      sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

      ## Masquerade settings
      iptables -A POSTROUTING -t nat -o enp0s3 -j MASQUERADE
      iptables -A POSTROUTING -t nat -o enp0s8 -j MASQUERADE

      ## ftp rules
      iptables -t nat -I PREROUTING -p tcp -m tcp --dport 20 -i enp0s8 -j DNAT --to-destination 192.168.56.2:20
      iptables -t nat -I PREROUTING -p tcp -m tcp --dport 21 -i enp0s8 -j DNAT --to-destination 192.168.56.2
      iptables -t nat -I PREROUTING -p tcp -m tcp --dport 1024:65535 -i enp0s8 -j DNAT --to-destination 192.168.56.2:1024-65535

      ## telnet rules
      iptables -t nat -I PREROUTING -p tcp -m tcp --dport 23 -i enp0s8 -j DNAT --to-destination 192.168.56.2`


      These rules work well with Ubuntu-10, that has Linux kernel 2.6.32-38-generic, but with the new kernel data connection can't be established: when the client issues the PORT command, the server receives the IP address of the external network and not that of the internal one. According to "netstat" running on server side, it seems that the module "nf_nat_ftp" is not working well, that is it does not substitute the client IP address (external address) with that of the input interface enp0s8, (internal address) before forwarding the command to the server. For this reason the server get stuck trying to establish a connection with the external IP address (SYN state).

      No problem with the FTP working in passive mode and with telnet connection as well.



      Could you give me a suggestion to overcome this issue? Is it a regression or am I expected to change my iptables rules according to some new requirements?



      Thank you in advance!



      Best regards,
      Stefano









      share|improve this question











      share|improve this question




      share|improve this question










      asked Oct 16 '17 at 9:07









      Stefano

      1




      1




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote













          I already answered it at superuser.com



          Basically newer kernels ( >= 4.7 ) are deprecating the automatic helper module's port assignment in favor of explicit rules.



          Short fix to get the old behaviour:



          echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper


          Better long term fix (requiring more work but giving better control):




          See the CT target description in the
          iptables-extensions(8) man page for further information.`




          and read also this blog for examples:



          https://home.regit.org/netfilter-en/secure-use-of-helpers/



          IMPORTANT NOTE: many of your FTP rules don't make any sense (you need only the 2nd rule). For example there's no such --dport 20. Ever. Active FTP uses source port 20, never destination port 20. The nf_conntrack_ftp/nf_nat_ftp handle all this already. Don't attempt to nat related connections at all, that's the helper's job.



          If you're firewalling, in the firewall rules (filter not nat) you only need the usual -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
          (but read the blog about this too for the long term solution). Perhaps you didn't put all of your rules, or you just don't use any firewall?






          share|improve this answer






















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f398359%2fiptables-netfilter-nf-nat-ftp-is-not-working-well-with-recent-linux-kernels%23new-answer', 'question_page');

            );

            Post as a guest






























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            1
            down vote













            I already answered it at superuser.com



            Basically newer kernels ( >= 4.7 ) are deprecating the automatic helper module's port assignment in favor of explicit rules.



            Short fix to get the old behaviour:



            echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper


            Better long term fix (requiring more work but giving better control):




            See the CT target description in the
            iptables-extensions(8) man page for further information.`




            and read also this blog for examples:



            https://home.regit.org/netfilter-en/secure-use-of-helpers/



            IMPORTANT NOTE: many of your FTP rules don't make any sense (you need only the 2nd rule). For example there's no such --dport 20. Ever. Active FTP uses source port 20, never destination port 20. The nf_conntrack_ftp/nf_nat_ftp handle all this already. Don't attempt to nat related connections at all, that's the helper's job.



            If you're firewalling, in the firewall rules (filter not nat) you only need the usual -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
            (but read the blog about this too for the long term solution). Perhaps you didn't put all of your rules, or you just don't use any firewall?






            share|improve this answer


























              up vote
              1
              down vote













              I already answered it at superuser.com



              Basically newer kernels ( >= 4.7 ) are deprecating the automatic helper module's port assignment in favor of explicit rules.



              Short fix to get the old behaviour:



              echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper


              Better long term fix (requiring more work but giving better control):




              See the CT target description in the
              iptables-extensions(8) man page for further information.`




              and read also this blog for examples:



              https://home.regit.org/netfilter-en/secure-use-of-helpers/



              IMPORTANT NOTE: many of your FTP rules don't make any sense (you need only the 2nd rule). For example there's no such --dport 20. Ever. Active FTP uses source port 20, never destination port 20. The nf_conntrack_ftp/nf_nat_ftp handle all this already. Don't attempt to nat related connections at all, that's the helper's job.



              If you're firewalling, in the firewall rules (filter not nat) you only need the usual -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
              (but read the blog about this too for the long term solution). Perhaps you didn't put all of your rules, or you just don't use any firewall?






              share|improve this answer
























                up vote
                1
                down vote










                up vote
                1
                down vote









                I already answered it at superuser.com



                Basically newer kernels ( >= 4.7 ) are deprecating the automatic helper module's port assignment in favor of explicit rules.



                Short fix to get the old behaviour:



                echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper


                Better long term fix (requiring more work but giving better control):




                See the CT target description in the
                iptables-extensions(8) man page for further information.`




                and read also this blog for examples:



                https://home.regit.org/netfilter-en/secure-use-of-helpers/



                IMPORTANT NOTE: many of your FTP rules don't make any sense (you need only the 2nd rule). For example there's no such --dport 20. Ever. Active FTP uses source port 20, never destination port 20. The nf_conntrack_ftp/nf_nat_ftp handle all this already. Don't attempt to nat related connections at all, that's the helper's job.



                If you're firewalling, in the firewall rules (filter not nat) you only need the usual -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
                (but read the blog about this too for the long term solution). Perhaps you didn't put all of your rules, or you just don't use any firewall?






                share|improve this answer














                I already answered it at superuser.com



                Basically newer kernels ( >= 4.7 ) are deprecating the automatic helper module's port assignment in favor of explicit rules.



                Short fix to get the old behaviour:



                echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper


                Better long term fix (requiring more work but giving better control):




                See the CT target description in the
                iptables-extensions(8) man page for further information.`




                and read also this blog for examples:



                https://home.regit.org/netfilter-en/secure-use-of-helpers/



                IMPORTANT NOTE: many of your FTP rules don't make any sense (you need only the 2nd rule). For example there's no such --dport 20. Ever. Active FTP uses source port 20, never destination port 20. The nf_conntrack_ftp/nf_nat_ftp handle all this already. Don't attempt to nat related connections at all, that's the helper's job.



                If you're firewalling, in the firewall rules (filter not nat) you only need the usual -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
                (but read the blog about this too for the long term solution). Perhaps you didn't put all of your rules, or you just don't use any firewall?







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Oct 22 '17 at 14:32

























                answered Oct 22 '17 at 14:15









                A.B

                3,4801621




                3,4801621



























                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f398359%2fiptables-netfilter-nf-nat-ftp-is-not-working-well-with-recent-linux-kernels%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?