IPTables Port Redirection Should Have Broken Apache But Didn't












3















I have a Load Balance set up in Apache httpd:



<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName xxx.xxx.xxx.com
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://xxx.xxx.xxx.xxx:8080/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:8080/
</VirtualHost>


:8080 is an Apache tomcat application server running on the same host. We have log retention requirements where I work, so I figured making everything apache httpd would make things ideal for analytics.



I was attempting to get all public requests to go through port 80 without breaking any links or bookmarks end users might have. I was going to do that by doing some port translation so that everything looked like it was coming in via port 80 to applications. Without thinking about my load balance above I added the following rules to the nat table:



-A PREROUTING -i eth0 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8081 -j REDIRECT --to-ports 80


Problem is, that I can get to the application either through httpd or directly by going to :8080. The packet count is also going up on each rule so apparently they're being matched against.



My question is this: Why didn't this just create an infinite loop?



It would seem the :8080 requests would get forwarded to httpd which would itself attempt to retrieve them by going over :8080 and thus the circle would continue onwards until I was reformatting my new resume.










share|improve this question





























    3















    I have a Load Balance set up in Apache httpd:



    <VirtualHost *:80>
    DocumentRoot /var/www/html
    ServerName xxx.xxx.xxx.com
    ProxyRequests Off
    ProxyPreserveHost On
    ProxyPass / http://xxx.xxx.xxx.xxx:8080/
    ProxyPassReverse / http://xxx.xxx.xxx.xxx:8080/
    </VirtualHost>


    :8080 is an Apache tomcat application server running on the same host. We have log retention requirements where I work, so I figured making everything apache httpd would make things ideal for analytics.



    I was attempting to get all public requests to go through port 80 without breaking any links or bookmarks end users might have. I was going to do that by doing some port translation so that everything looked like it was coming in via port 80 to applications. Without thinking about my load balance above I added the following rules to the nat table:



    -A PREROUTING -i eth0 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80
    -A PREROUTING -i eth0 -p tcp -m tcp --dport 8081 -j REDIRECT --to-ports 80


    Problem is, that I can get to the application either through httpd or directly by going to :8080. The packet count is also going up on each rule so apparently they're being matched against.



    My question is this: Why didn't this just create an infinite loop?



    It would seem the :8080 requests would get forwarded to httpd which would itself attempt to retrieve them by going over :8080 and thus the circle would continue onwards until I was reformatting my new resume.










    share|improve this question



























      3












      3








      3


      1






      I have a Load Balance set up in Apache httpd:



      <VirtualHost *:80>
      DocumentRoot /var/www/html
      ServerName xxx.xxx.xxx.com
      ProxyRequests Off
      ProxyPreserveHost On
      ProxyPass / http://xxx.xxx.xxx.xxx:8080/
      ProxyPassReverse / http://xxx.xxx.xxx.xxx:8080/
      </VirtualHost>


      :8080 is an Apache tomcat application server running on the same host. We have log retention requirements where I work, so I figured making everything apache httpd would make things ideal for analytics.



      I was attempting to get all public requests to go through port 80 without breaking any links or bookmarks end users might have. I was going to do that by doing some port translation so that everything looked like it was coming in via port 80 to applications. Without thinking about my load balance above I added the following rules to the nat table:



      -A PREROUTING -i eth0 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80
      -A PREROUTING -i eth0 -p tcp -m tcp --dport 8081 -j REDIRECT --to-ports 80


      Problem is, that I can get to the application either through httpd or directly by going to :8080. The packet count is also going up on each rule so apparently they're being matched against.



      My question is this: Why didn't this just create an infinite loop?



      It would seem the :8080 requests would get forwarded to httpd which would itself attempt to retrieve them by going over :8080 and thus the circle would continue onwards until I was reformatting my new resume.










      share|improve this question
















      I have a Load Balance set up in Apache httpd:



      <VirtualHost *:80>
      DocumentRoot /var/www/html
      ServerName xxx.xxx.xxx.com
      ProxyRequests Off
      ProxyPreserveHost On
      ProxyPass / http://xxx.xxx.xxx.xxx:8080/
      ProxyPassReverse / http://xxx.xxx.xxx.xxx:8080/
      </VirtualHost>


      :8080 is an Apache tomcat application server running on the same host. We have log retention requirements where I work, so I figured making everything apache httpd would make things ideal for analytics.



      I was attempting to get all public requests to go through port 80 without breaking any links or bookmarks end users might have. I was going to do that by doing some port translation so that everything looked like it was coming in via port 80 to applications. Without thinking about my load balance above I added the following rules to the nat table:



      -A PREROUTING -i eth0 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80
      -A PREROUTING -i eth0 -p tcp -m tcp --dport 8081 -j REDIRECT --to-ports 80


      Problem is, that I can get to the application either through httpd or directly by going to :8080. The packet count is also going up on each rule so apparently they're being matched against.



      My question is this: Why didn't this just create an infinite loop?



      It would seem the :8080 requests would get forwarded to httpd which would itself attempt to retrieve them by going over :8080 and thus the circle would continue onwards until I was reformatting my new resume.







      linux iptables tomcat apache-httpd






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 2 hours ago









      Rui F Ribeiro

      39.6k1479132




      39.6k1479132










      asked May 16 '14 at 17:41









      BratchleyBratchley

      12k74388




      12k74388






















          1 Answer
          1






          active

          oldest

          votes


















          3














          The answer lies in -i eth0.



          Even though you have httpd set to connect to 17.98.65.28, which I assume is an IP on eth0, the traffic won't actually flow over eth0, it'll use lo instead.



          The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo. You can verify this with the following:



          ip route get 17.98.65.28


          You will get a line back that contains dev lo, this tells you which interface will be used to send traffic to that address.



          For example, on my laptop, I have wlan0 with 10.252.28.62:



          $ ip route get 10.252.28.62
          local 10.252.28.62 dev lo src 10.252.28.62
          cache <local>





          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',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            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%2f130665%2fiptables-port-redirection-should-have-broken-apache-but-didnt%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            3














            The answer lies in -i eth0.



            Even though you have httpd set to connect to 17.98.65.28, which I assume is an IP on eth0, the traffic won't actually flow over eth0, it'll use lo instead.



            The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo. You can verify this with the following:



            ip route get 17.98.65.28


            You will get a line back that contains dev lo, this tells you which interface will be used to send traffic to that address.



            For example, on my laptop, I have wlan0 with 10.252.28.62:



            $ ip route get 10.252.28.62
            local 10.252.28.62 dev lo src 10.252.28.62
            cache <local>





            share|improve this answer




























              3














              The answer lies in -i eth0.



              Even though you have httpd set to connect to 17.98.65.28, which I assume is an IP on eth0, the traffic won't actually flow over eth0, it'll use lo instead.



              The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo. You can verify this with the following:



              ip route get 17.98.65.28


              You will get a line back that contains dev lo, this tells you which interface will be used to send traffic to that address.



              For example, on my laptop, I have wlan0 with 10.252.28.62:



              $ ip route get 10.252.28.62
              local 10.252.28.62 dev lo src 10.252.28.62
              cache <local>





              share|improve this answer


























                3












                3








                3







                The answer lies in -i eth0.



                Even though you have httpd set to connect to 17.98.65.28, which I assume is an IP on eth0, the traffic won't actually flow over eth0, it'll use lo instead.



                The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo. You can verify this with the following:



                ip route get 17.98.65.28


                You will get a line back that contains dev lo, this tells you which interface will be used to send traffic to that address.



                For example, on my laptop, I have wlan0 with 10.252.28.62:



                $ ip route get 10.252.28.62
                local 10.252.28.62 dev lo src 10.252.28.62
                cache <local>





                share|improve this answer













                The answer lies in -i eth0.



                Even though you have httpd set to connect to 17.98.65.28, which I assume is an IP on eth0, the traffic won't actually flow over eth0, it'll use lo instead.



                The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo. You can verify this with the following:



                ip route get 17.98.65.28


                You will get a line back that contains dev lo, this tells you which interface will be used to send traffic to that address.



                For example, on my laptop, I have wlan0 with 10.252.28.62:



                $ ip route get 10.252.28.62
                local 10.252.28.62 dev lo src 10.252.28.62
                cache <local>






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered May 16 '14 at 17:52









                PatrickPatrick

                50.3k11127179




                50.3k11127179






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f130665%2fiptables-port-redirection-should-have-broken-apache-but-didnt%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Loup dans la culture

                    How to solve the problem of ntp “Unable to contact time server” from KDE?

                    ASUS Zenbook UX433/UX333 — Configure Touchpad-embedded numpad on Linux