Output traffic on different interfaces based on destination port

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












23















My question is basically the same as Only allow certain outbound traffic on certain interfaces.



I have two interfaces eth1 (10.0.0.2) and wlan0 (192.168.0.2).
My default route is for eth1.
Let's say I want all https-traffic to go through wlan0.
Now if I use the solution suggested in the other question, https traffic will go through wlan0, but will still have the source-address of eth1 (10.0.0.2). Since this address is not routeable for the wlan0 gateway, answers won't ever come back. The easy way would be to just set the bind-addr properly in the application, but in this case it is not applicable.



I figure I need to rewrite the src-addr:



# first mark it so that iproute can route it through wlan0
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2


Now tcpdump sees the outgoing packets just fine and ingoing packets arrive for 192.168.0.2, however they probably never end up in the application, because all I ever get to see, is that the application is resending the SYN-packet, although the SYN-ACK was already received.



So I thought, maybe I need to rewrite the incoming address too:



iptables -A PREROUTING -t nat -i wlan0 -p tcp --sport 443 -j DNAT --to 10.0.0.2


but that didn't work either. So I’m kind of stuck here. Any suggestions?










share|improve this question




























    23















    My question is basically the same as Only allow certain outbound traffic on certain interfaces.



    I have two interfaces eth1 (10.0.0.2) and wlan0 (192.168.0.2).
    My default route is for eth1.
    Let's say I want all https-traffic to go through wlan0.
    Now if I use the solution suggested in the other question, https traffic will go through wlan0, but will still have the source-address of eth1 (10.0.0.2). Since this address is not routeable for the wlan0 gateway, answers won't ever come back. The easy way would be to just set the bind-addr properly in the application, but in this case it is not applicable.



    I figure I need to rewrite the src-addr:



    # first mark it so that iproute can route it through wlan0
    iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
    # now rewrite the src-addr
    iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2


    Now tcpdump sees the outgoing packets just fine and ingoing packets arrive for 192.168.0.2, however they probably never end up in the application, because all I ever get to see, is that the application is resending the SYN-packet, although the SYN-ACK was already received.



    So I thought, maybe I need to rewrite the incoming address too:



    iptables -A PREROUTING -t nat -i wlan0 -p tcp --sport 443 -j DNAT --to 10.0.0.2


    but that didn't work either. So I’m kind of stuck here. Any suggestions?










    share|improve this question


























      23












      23








      23


      24






      My question is basically the same as Only allow certain outbound traffic on certain interfaces.



      I have two interfaces eth1 (10.0.0.2) and wlan0 (192.168.0.2).
      My default route is for eth1.
      Let's say I want all https-traffic to go through wlan0.
      Now if I use the solution suggested in the other question, https traffic will go through wlan0, but will still have the source-address of eth1 (10.0.0.2). Since this address is not routeable for the wlan0 gateway, answers won't ever come back. The easy way would be to just set the bind-addr properly in the application, but in this case it is not applicable.



      I figure I need to rewrite the src-addr:



      # first mark it so that iproute can route it through wlan0
      iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
      # now rewrite the src-addr
      iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2


      Now tcpdump sees the outgoing packets just fine and ingoing packets arrive for 192.168.0.2, however they probably never end up in the application, because all I ever get to see, is that the application is resending the SYN-packet, although the SYN-ACK was already received.



      So I thought, maybe I need to rewrite the incoming address too:



      iptables -A PREROUTING -t nat -i wlan0 -p tcp --sport 443 -j DNAT --to 10.0.0.2


      but that didn't work either. So I’m kind of stuck here. Any suggestions?










      share|improve this question
















      My question is basically the same as Only allow certain outbound traffic on certain interfaces.



      I have two interfaces eth1 (10.0.0.2) and wlan0 (192.168.0.2).
      My default route is for eth1.
      Let's say I want all https-traffic to go through wlan0.
      Now if I use the solution suggested in the other question, https traffic will go through wlan0, but will still have the source-address of eth1 (10.0.0.2). Since this address is not routeable for the wlan0 gateway, answers won't ever come back. The easy way would be to just set the bind-addr properly in the application, but in this case it is not applicable.



      I figure I need to rewrite the src-addr:



      # first mark it so that iproute can route it through wlan0
      iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
      # now rewrite the src-addr
      iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2


      Now tcpdump sees the outgoing packets just fine and ingoing packets arrive for 192.168.0.2, however they probably never end up in the application, because all I ever get to see, is that the application is resending the SYN-packet, although the SYN-ACK was already received.



      So I thought, maybe I need to rewrite the incoming address too:



      iptables -A PREROUTING -t nat -i wlan0 -p tcp --sport 443 -j DNAT --to 10.0.0.2


      but that didn't work either. So I’m kind of stuck here. Any suggestions?







      linux networking iptables routing






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Apr 13 '17 at 12:36









      Community

      1




      1










      asked Sep 20 '11 at 11:05









      rumpelrumpel

      220126




      220126




















          4 Answers
          4






          active

          oldest

          votes


















          23














          You're close.



          The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:



          sudo sysctl net.ipv4.conf.wlan0.rp_filter=0


          But I wouldn't recommend it. The more proper way is to create an alternate routing instance.



          1. The mark is necessary. Keep it.

          2. Source NAT is also necessary.

          3. The final DNAT is unnecessary, so you can remove it.

          Make sure you have the iproute package installed. If you have the ip command then you're set (which it looks like you do, but if not get that first).



          Edit /etc/iproute2/rt_tables and add a new table by appending the following line:



          200 wlan-route


          You then need to configure your new routing table named wlan-route with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.



          ip route add default via 192.168.0.1 dev wlan0 table wlan-route
          ip rule add fwmark 0x1 table wlan-route


          Your final annotated script would look like this:



          # Populate secondary routing table
          ip route add default via 192.168.0.1 dev wlan0 table wlan-route
          # Anything with this fwmark will use the secondary routing table
          ip rule add fwmark 0x1 table wlan-route
          # Mark these packets so that iproute can route it through wlan-route
          iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
          # now rewrite the src-addr
          iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2





          share|improve this answer

























          • Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.

            – rumpel
            Sep 20 '11 at 18:06











          • Go back and read my answer again. I addressed that.

            – bahamat
            Sep 20 '11 at 19:14











          • The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.

            – rumpel
            Sep 20 '11 at 19:23











          • You need to add a src option to the ip route commands to specify the correct source address.

            – David Schwartz
            Sep 23 '11 at 10:51











          • @DavidSchwartz: the POSTROUTING SNAT will take care of that.

            – bahamat
            Sep 23 '11 at 21:06


















          7














          bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.



          for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
          echo 1 > /proc/sys/net/ipv4/route/flush


          (see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)






          share|improve this answer

























          • Thanks for this answers, I too could only get bahamats solution working considering your answer.

            – Dynalon
            May 13 '14 at 8:05











          • for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.

            – Costin Gușă
            Jun 23 '14 at 15:28



















          0














          One suggestion: you should always use --sport instead of --dport in output chain.



          NATs change the dport and that will make your rule unuasble.






          share|improve this answer




















          • 2





            Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P

            – Someone
            Feb 7 '16 at 18:41


















          0














          I think below is needed:



          ip ru add from 192.168.0.2 table 3 prio 300
          ip ro add table 3 default via 192.168.0.1 dev wlan0





          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%2f21093%2foutput-traffic-on-different-interfaces-based-on-destination-port%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            4 Answers
            4






            active

            oldest

            votes








            4 Answers
            4






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            23














            You're close.



            The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:



            sudo sysctl net.ipv4.conf.wlan0.rp_filter=0


            But I wouldn't recommend it. The more proper way is to create an alternate routing instance.



            1. The mark is necessary. Keep it.

            2. Source NAT is also necessary.

            3. The final DNAT is unnecessary, so you can remove it.

            Make sure you have the iproute package installed. If you have the ip command then you're set (which it looks like you do, but if not get that first).



            Edit /etc/iproute2/rt_tables and add a new table by appending the following line:



            200 wlan-route


            You then need to configure your new routing table named wlan-route with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.



            ip route add default via 192.168.0.1 dev wlan0 table wlan-route
            ip rule add fwmark 0x1 table wlan-route


            Your final annotated script would look like this:



            # Populate secondary routing table
            ip route add default via 192.168.0.1 dev wlan0 table wlan-route
            # Anything with this fwmark will use the secondary routing table
            ip rule add fwmark 0x1 table wlan-route
            # Mark these packets so that iproute can route it through wlan-route
            iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
            # now rewrite the src-addr
            iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2





            share|improve this answer

























            • Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.

              – rumpel
              Sep 20 '11 at 18:06











            • Go back and read my answer again. I addressed that.

              – bahamat
              Sep 20 '11 at 19:14











            • The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.

              – rumpel
              Sep 20 '11 at 19:23











            • You need to add a src option to the ip route commands to specify the correct source address.

              – David Schwartz
              Sep 23 '11 at 10:51











            • @DavidSchwartz: the POSTROUTING SNAT will take care of that.

              – bahamat
              Sep 23 '11 at 21:06















            23














            You're close.



            The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:



            sudo sysctl net.ipv4.conf.wlan0.rp_filter=0


            But I wouldn't recommend it. The more proper way is to create an alternate routing instance.



            1. The mark is necessary. Keep it.

            2. Source NAT is also necessary.

            3. The final DNAT is unnecessary, so you can remove it.

            Make sure you have the iproute package installed. If you have the ip command then you're set (which it looks like you do, but if not get that first).



            Edit /etc/iproute2/rt_tables and add a new table by appending the following line:



            200 wlan-route


            You then need to configure your new routing table named wlan-route with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.



            ip route add default via 192.168.0.1 dev wlan0 table wlan-route
            ip rule add fwmark 0x1 table wlan-route


            Your final annotated script would look like this:



            # Populate secondary routing table
            ip route add default via 192.168.0.1 dev wlan0 table wlan-route
            # Anything with this fwmark will use the secondary routing table
            ip rule add fwmark 0x1 table wlan-route
            # Mark these packets so that iproute can route it through wlan-route
            iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
            # now rewrite the src-addr
            iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2





            share|improve this answer

























            • Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.

              – rumpel
              Sep 20 '11 at 18:06











            • Go back and read my answer again. I addressed that.

              – bahamat
              Sep 20 '11 at 19:14











            • The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.

              – rumpel
              Sep 20 '11 at 19:23











            • You need to add a src option to the ip route commands to specify the correct source address.

              – David Schwartz
              Sep 23 '11 at 10:51











            • @DavidSchwartz: the POSTROUTING SNAT will take care of that.

              – bahamat
              Sep 23 '11 at 21:06













            23












            23








            23







            You're close.



            The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:



            sudo sysctl net.ipv4.conf.wlan0.rp_filter=0


            But I wouldn't recommend it. The more proper way is to create an alternate routing instance.



            1. The mark is necessary. Keep it.

            2. Source NAT is also necessary.

            3. The final DNAT is unnecessary, so you can remove it.

            Make sure you have the iproute package installed. If you have the ip command then you're set (which it looks like you do, but if not get that first).



            Edit /etc/iproute2/rt_tables and add a new table by appending the following line:



            200 wlan-route


            You then need to configure your new routing table named wlan-route with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.



            ip route add default via 192.168.0.1 dev wlan0 table wlan-route
            ip rule add fwmark 0x1 table wlan-route


            Your final annotated script would look like this:



            # Populate secondary routing table
            ip route add default via 192.168.0.1 dev wlan0 table wlan-route
            # Anything with this fwmark will use the secondary routing table
            ip rule add fwmark 0x1 table wlan-route
            # Mark these packets so that iproute can route it through wlan-route
            iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
            # now rewrite the src-addr
            iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2





            share|improve this answer















            You're close.



            The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:



            sudo sysctl net.ipv4.conf.wlan0.rp_filter=0


            But I wouldn't recommend it. The more proper way is to create an alternate routing instance.



            1. The mark is necessary. Keep it.

            2. Source NAT is also necessary.

            3. The final DNAT is unnecessary, so you can remove it.

            Make sure you have the iproute package installed. If you have the ip command then you're set (which it looks like you do, but if not get that first).



            Edit /etc/iproute2/rt_tables and add a new table by appending the following line:



            200 wlan-route


            You then need to configure your new routing table named wlan-route with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.



            ip route add default via 192.168.0.1 dev wlan0 table wlan-route
            ip rule add fwmark 0x1 table wlan-route


            Your final annotated script would look like this:



            # Populate secondary routing table
            ip route add default via 192.168.0.1 dev wlan0 table wlan-route
            # Anything with this fwmark will use the secondary routing table
            ip rule add fwmark 0x1 table wlan-route
            # Mark these packets so that iproute can route it through wlan-route
            iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
            # now rewrite the src-addr
            iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Sep 21 '11 at 11:27









            rumpel

            220126




            220126










            answered Sep 20 '11 at 15:35









            bahamatbahamat

            24.5k15090




            24.5k15090












            • Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.

              – rumpel
              Sep 20 '11 at 18:06











            • Go back and read my answer again. I addressed that.

              – bahamat
              Sep 20 '11 at 19:14











            • The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.

              – rumpel
              Sep 20 '11 at 19:23











            • You need to add a src option to the ip route commands to specify the correct source address.

              – David Schwartz
              Sep 23 '11 at 10:51











            • @DavidSchwartz: the POSTROUTING SNAT will take care of that.

              – bahamat
              Sep 23 '11 at 21:06

















            • Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.

              – rumpel
              Sep 20 '11 at 18:06











            • Go back and read my answer again. I addressed that.

              – bahamat
              Sep 20 '11 at 19:14











            • The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.

              – rumpel
              Sep 20 '11 at 19:23











            • You need to add a src option to the ip route commands to specify the correct source address.

              – David Schwartz
              Sep 23 '11 at 10:51











            • @DavidSchwartz: the POSTROUTING SNAT will take care of that.

              – bahamat
              Sep 23 '11 at 21:06
















            Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.

            – rumpel
            Sep 20 '11 at 18:06





            Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.

            – rumpel
            Sep 20 '11 at 18:06













            Go back and read my answer again. I addressed that.

            – bahamat
            Sep 20 '11 at 19:14





            Go back and read my answer again. I addressed that.

            – bahamat
            Sep 20 '11 at 19:14













            The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.

            – rumpel
            Sep 20 '11 at 19:23





            The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.

            – rumpel
            Sep 20 '11 at 19:23













            You need to add a src option to the ip route commands to specify the correct source address.

            – David Schwartz
            Sep 23 '11 at 10:51





            You need to add a src option to the ip route commands to specify the correct source address.

            – David Schwartz
            Sep 23 '11 at 10:51













            @DavidSchwartz: the POSTROUTING SNAT will take care of that.

            – bahamat
            Sep 23 '11 at 21:06





            @DavidSchwartz: the POSTROUTING SNAT will take care of that.

            – bahamat
            Sep 23 '11 at 21:06













            7














            bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.



            for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
            echo 1 > /proc/sys/net/ipv4/route/flush


            (see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)






            share|improve this answer

























            • Thanks for this answers, I too could only get bahamats solution working considering your answer.

              – Dynalon
              May 13 '14 at 8:05











            • for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.

              – Costin Gușă
              Jun 23 '14 at 15:28
















            7














            bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.



            for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
            echo 1 > /proc/sys/net/ipv4/route/flush


            (see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)






            share|improve this answer

























            • Thanks for this answers, I too could only get bahamats solution working considering your answer.

              – Dynalon
              May 13 '14 at 8:05











            • for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.

              – Costin Gușă
              Jun 23 '14 at 15:28














            7












            7








            7







            bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.



            for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
            echo 1 > /proc/sys/net/ipv4/route/flush


            (see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)






            share|improve this answer















            bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.



            for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
            echo 1 > /proc/sys/net/ipv4/route/flush


            (see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 13 '17 at 12:36









            Community

            1




            1










            answered Feb 22 '12 at 15:42









            Davide CDavide C

            7111




            7111












            • Thanks for this answers, I too could only get bahamats solution working considering your answer.

              – Dynalon
              May 13 '14 at 8:05











            • for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.

              – Costin Gușă
              Jun 23 '14 at 15:28


















            • Thanks for this answers, I too could only get bahamats solution working considering your answer.

              – Dynalon
              May 13 '14 at 8:05











            • for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.

              – Costin Gușă
              Jun 23 '14 at 15:28

















            Thanks for this answers, I too could only get bahamats solution working considering your answer.

            – Dynalon
            May 13 '14 at 8:05





            Thanks for this answers, I too could only get bahamats solution working considering your answer.

            – Dynalon
            May 13 '14 at 8:05













            for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.

            – Costin Gușă
            Jun 23 '14 at 15:28






            for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.

            – Costin Gușă
            Jun 23 '14 at 15:28












            0














            One suggestion: you should always use --sport instead of --dport in output chain.



            NATs change the dport and that will make your rule unuasble.






            share|improve this answer




















            • 2





              Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P

              – Someone
              Feb 7 '16 at 18:41















            0














            One suggestion: you should always use --sport instead of --dport in output chain.



            NATs change the dport and that will make your rule unuasble.






            share|improve this answer




















            • 2





              Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P

              – Someone
              Feb 7 '16 at 18:41













            0












            0








            0







            One suggestion: you should always use --sport instead of --dport in output chain.



            NATs change the dport and that will make your rule unuasble.






            share|improve this answer















            One suggestion: you should always use --sport instead of --dport in output chain.



            NATs change the dport and that will make your rule unuasble.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jun 24 '14 at 11:25









            Networker

            6,014103969




            6,014103969










            answered Jun 24 '14 at 9:33









            user73451user73451

            1




            1







            • 2





              Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P

              – Someone
              Feb 7 '16 at 18:41












            • 2





              Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P

              – Someone
              Feb 7 '16 at 18:41







            2




            2





            Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P

            – Someone
            Feb 7 '16 at 18:41





            Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P

            – Someone
            Feb 7 '16 at 18:41











            0














            I think below is needed:



            ip ru add from 192.168.0.2 table 3 prio 300
            ip ro add table 3 default via 192.168.0.1 dev wlan0





            share|improve this answer





























              0














              I think below is needed:



              ip ru add from 192.168.0.2 table 3 prio 300
              ip ro add table 3 default via 192.168.0.1 dev wlan0





              share|improve this answer



























                0












                0








                0







                I think below is needed:



                ip ru add from 192.168.0.2 table 3 prio 300
                ip ro add table 3 default via 192.168.0.1 dev wlan0





                share|improve this answer















                I think below is needed:



                ip ru add from 192.168.0.2 table 3 prio 300
                ip ro add table 3 default via 192.168.0.1 dev wlan0






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Jul 24 '16 at 8:15









                techraf

                4,203102141




                4,203102141










                answered Jul 24 '16 at 6:57









                user181234user181234

                1




                1



























                    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%2f21093%2foutput-traffic-on-different-interfaces-based-on-destination-port%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

                    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?