Route all eth1 traffic over VPN












0















I have 3 NIC in my system: eth0 (192.168.1.54), eth1(192.168.1.55), wg0 (VPN, 192.168.99.1)



I'm looking for a way to route all eth1 traffic (tcp and udp) over wg0 (Wireguard VPN).



What I am trying to achieve is that on my phone/tablet/apple tv/etc I set eth1 address as Router, so all traffic should be redirected trough VPN.



On the remote side (it's a VPS) I have eth0 (main internet) and wg0 (192.168.99.2).



All what I currently did is that I successfully set up Wireguard interfaces on the both side (I can ping each other).



Route table:



default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.54
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.55
192.168.99.0/24 dev wg0 proto kernel scope link src 192.168.99.1









share|improve this question














bumped to the homepage by Community 13 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.




















    0















    I have 3 NIC in my system: eth0 (192.168.1.54), eth1(192.168.1.55), wg0 (VPN, 192.168.99.1)



    I'm looking for a way to route all eth1 traffic (tcp and udp) over wg0 (Wireguard VPN).



    What I am trying to achieve is that on my phone/tablet/apple tv/etc I set eth1 address as Router, so all traffic should be redirected trough VPN.



    On the remote side (it's a VPS) I have eth0 (main internet) and wg0 (192.168.99.2).



    All what I currently did is that I successfully set up Wireguard interfaces on the both side (I can ping each other).



    Route table:



    default via 192.168.1.1 dev eth0 onlink 
    192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.54
    192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.55
    192.168.99.0/24 dev wg0 proto kernel scope link src 192.168.99.1









    share|improve this question














    bumped to the homepage by Community 13 mins ago


    This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.


















      0












      0








      0


      1






      I have 3 NIC in my system: eth0 (192.168.1.54), eth1(192.168.1.55), wg0 (VPN, 192.168.99.1)



      I'm looking for a way to route all eth1 traffic (tcp and udp) over wg0 (Wireguard VPN).



      What I am trying to achieve is that on my phone/tablet/apple tv/etc I set eth1 address as Router, so all traffic should be redirected trough VPN.



      On the remote side (it's a VPS) I have eth0 (main internet) and wg0 (192.168.99.2).



      All what I currently did is that I successfully set up Wireguard interfaces on the both side (I can ping each other).



      Route table:



      default via 192.168.1.1 dev eth0 onlink 
      192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.54
      192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.55
      192.168.99.0/24 dev wg0 proto kernel scope link src 192.168.99.1









      share|improve this question














      I have 3 NIC in my system: eth0 (192.168.1.54), eth1(192.168.1.55), wg0 (VPN, 192.168.99.1)



      I'm looking for a way to route all eth1 traffic (tcp and udp) over wg0 (Wireguard VPN).



      What I am trying to achieve is that on my phone/tablet/apple tv/etc I set eth1 address as Router, so all traffic should be redirected trough VPN.



      On the remote side (it's a VPS) I have eth0 (main internet) and wg0 (192.168.99.2).



      All what I currently did is that I successfully set up Wireguard interfaces on the both side (I can ping each other).



      Route table:



      default via 192.168.1.1 dev eth0 onlink 
      192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.54
      192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.55
      192.168.99.0/24 dev wg0 proto kernel scope link src 192.168.99.1






      linux routing vpn






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Dec 15 '17 at 15:23









      user66638user66638

      1012




      1012





      bumped to the homepage by Community 13 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







      bumped to the homepage by Community 13 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
























          1 Answer
          1






          active

          oldest

          votes


















          0














          You don't need two Ethernet interfaces. Define a host route via 192.168.1.1 to the public IP of the VPN server, and point the default route to the remote end of the tunnel (192.168.99.2). Make the default route on the other devices on your LAN point to 192.168.1.54. Remember to enable packet forwarding on your PC (sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1).



          EDIT: You cannot achieve the solution you are looking for with IPv4 classic routing, since classic routing is only concerned with where a packet is going, not its history, like which interface it was received on, or the source address. You will have to use Policy Routing to be able to classify packets based on the interface they were received on. Based on this classification you can then use an alternate routing table for routing, which, for example, defines a default route through your VPN tunnel.



          To use policy routing, you should add an entry (vpn) to /etc/iproute2/rt_tables:



          #
          # reserved values
          #
          255 local
          254 main
          253 default
          0 unspec
          #
          # local
          #
          1 vpn


          This gives the name vpn to routing table number 1.



          Next, add the following policy rule:



          ip rule add unicast iif eth1 table vpn


          This rule effectively says "if the packet comes in on interface eth1, use routing table vpn".



          You can check the rules with ip rule show:



          ip rule show
          0: from all lookup local
          32765: from all iif eth1 lookup vpn
          32766: from all lookup main
          32767: from all lookup default


          The rules are applied in ascending order, until a rule matches. If a packet is received on interfave eth1, rule 32765 matches, else the next rules are tried.



          You can now add routes to the vpn routing table. For example, to add a default route to your tunnel:



          ip route add default dev wg0 via 192.168.99.2 table vpn


          To print the vpn routing table, use



          ip route show table vpn


          Now, I haven't been able to actually test this, so there may be errors or some details missing. For more information on policy routing, see https://www.policyrouting.org or https://linux-ip.net.






          share|improve this answer


























          • Can you be a little bit more specific about routing? I have two interface, because there are other services running on this server (.54) which must be not affected in any way. "Define a host route" you mean I should create a static routing in my router (1.1) to the remote side 99.2? I can create a static routing for whole network only 99.0/24.

            – user66638
            Dec 15 '17 at 21:30











          • Point the default route to the remote end of the tunnel (192.168.99.2). --> I want to redirect only the eth1 traffic, not the whole network on the server.

            – user66638
            Dec 15 '17 at 21:52











          • Packet forwarding is based on routes, not interfaces. Routing tables are per host. Using basic routing, any packet received on any interface is subject to a routing decision based on the destination address. Please give more detail on what you want to achieve. Policy based routing might be the solution to your problem.

            – Johan Myréen
            Dec 16 '17 at 11:24











          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%2f411081%2froute-all-eth1-traffic-over-vpn%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









          0














          You don't need two Ethernet interfaces. Define a host route via 192.168.1.1 to the public IP of the VPN server, and point the default route to the remote end of the tunnel (192.168.99.2). Make the default route on the other devices on your LAN point to 192.168.1.54. Remember to enable packet forwarding on your PC (sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1).



          EDIT: You cannot achieve the solution you are looking for with IPv4 classic routing, since classic routing is only concerned with where a packet is going, not its history, like which interface it was received on, or the source address. You will have to use Policy Routing to be able to classify packets based on the interface they were received on. Based on this classification you can then use an alternate routing table for routing, which, for example, defines a default route through your VPN tunnel.



          To use policy routing, you should add an entry (vpn) to /etc/iproute2/rt_tables:



          #
          # reserved values
          #
          255 local
          254 main
          253 default
          0 unspec
          #
          # local
          #
          1 vpn


          This gives the name vpn to routing table number 1.



          Next, add the following policy rule:



          ip rule add unicast iif eth1 table vpn


          This rule effectively says "if the packet comes in on interface eth1, use routing table vpn".



          You can check the rules with ip rule show:



          ip rule show
          0: from all lookup local
          32765: from all iif eth1 lookup vpn
          32766: from all lookup main
          32767: from all lookup default


          The rules are applied in ascending order, until a rule matches. If a packet is received on interfave eth1, rule 32765 matches, else the next rules are tried.



          You can now add routes to the vpn routing table. For example, to add a default route to your tunnel:



          ip route add default dev wg0 via 192.168.99.2 table vpn


          To print the vpn routing table, use



          ip route show table vpn


          Now, I haven't been able to actually test this, so there may be errors or some details missing. For more information on policy routing, see https://www.policyrouting.org or https://linux-ip.net.






          share|improve this answer


























          • Can you be a little bit more specific about routing? I have two interface, because there are other services running on this server (.54) which must be not affected in any way. "Define a host route" you mean I should create a static routing in my router (1.1) to the remote side 99.2? I can create a static routing for whole network only 99.0/24.

            – user66638
            Dec 15 '17 at 21:30











          • Point the default route to the remote end of the tunnel (192.168.99.2). --> I want to redirect only the eth1 traffic, not the whole network on the server.

            – user66638
            Dec 15 '17 at 21:52











          • Packet forwarding is based on routes, not interfaces. Routing tables are per host. Using basic routing, any packet received on any interface is subject to a routing decision based on the destination address. Please give more detail on what you want to achieve. Policy based routing might be the solution to your problem.

            – Johan Myréen
            Dec 16 '17 at 11:24
















          0














          You don't need two Ethernet interfaces. Define a host route via 192.168.1.1 to the public IP of the VPN server, and point the default route to the remote end of the tunnel (192.168.99.2). Make the default route on the other devices on your LAN point to 192.168.1.54. Remember to enable packet forwarding on your PC (sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1).



          EDIT: You cannot achieve the solution you are looking for with IPv4 classic routing, since classic routing is only concerned with where a packet is going, not its history, like which interface it was received on, or the source address. You will have to use Policy Routing to be able to classify packets based on the interface they were received on. Based on this classification you can then use an alternate routing table for routing, which, for example, defines a default route through your VPN tunnel.



          To use policy routing, you should add an entry (vpn) to /etc/iproute2/rt_tables:



          #
          # reserved values
          #
          255 local
          254 main
          253 default
          0 unspec
          #
          # local
          #
          1 vpn


          This gives the name vpn to routing table number 1.



          Next, add the following policy rule:



          ip rule add unicast iif eth1 table vpn


          This rule effectively says "if the packet comes in on interface eth1, use routing table vpn".



          You can check the rules with ip rule show:



          ip rule show
          0: from all lookup local
          32765: from all iif eth1 lookup vpn
          32766: from all lookup main
          32767: from all lookup default


          The rules are applied in ascending order, until a rule matches. If a packet is received on interfave eth1, rule 32765 matches, else the next rules are tried.



          You can now add routes to the vpn routing table. For example, to add a default route to your tunnel:



          ip route add default dev wg0 via 192.168.99.2 table vpn


          To print the vpn routing table, use



          ip route show table vpn


          Now, I haven't been able to actually test this, so there may be errors or some details missing. For more information on policy routing, see https://www.policyrouting.org or https://linux-ip.net.






          share|improve this answer


























          • Can you be a little bit more specific about routing? I have two interface, because there are other services running on this server (.54) which must be not affected in any way. "Define a host route" you mean I should create a static routing in my router (1.1) to the remote side 99.2? I can create a static routing for whole network only 99.0/24.

            – user66638
            Dec 15 '17 at 21:30











          • Point the default route to the remote end of the tunnel (192.168.99.2). --> I want to redirect only the eth1 traffic, not the whole network on the server.

            – user66638
            Dec 15 '17 at 21:52











          • Packet forwarding is based on routes, not interfaces. Routing tables are per host. Using basic routing, any packet received on any interface is subject to a routing decision based on the destination address. Please give more detail on what you want to achieve. Policy based routing might be the solution to your problem.

            – Johan Myréen
            Dec 16 '17 at 11:24














          0












          0








          0







          You don't need two Ethernet interfaces. Define a host route via 192.168.1.1 to the public IP of the VPN server, and point the default route to the remote end of the tunnel (192.168.99.2). Make the default route on the other devices on your LAN point to 192.168.1.54. Remember to enable packet forwarding on your PC (sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1).



          EDIT: You cannot achieve the solution you are looking for with IPv4 classic routing, since classic routing is only concerned with where a packet is going, not its history, like which interface it was received on, or the source address. You will have to use Policy Routing to be able to classify packets based on the interface they were received on. Based on this classification you can then use an alternate routing table for routing, which, for example, defines a default route through your VPN tunnel.



          To use policy routing, you should add an entry (vpn) to /etc/iproute2/rt_tables:



          #
          # reserved values
          #
          255 local
          254 main
          253 default
          0 unspec
          #
          # local
          #
          1 vpn


          This gives the name vpn to routing table number 1.



          Next, add the following policy rule:



          ip rule add unicast iif eth1 table vpn


          This rule effectively says "if the packet comes in on interface eth1, use routing table vpn".



          You can check the rules with ip rule show:



          ip rule show
          0: from all lookup local
          32765: from all iif eth1 lookup vpn
          32766: from all lookup main
          32767: from all lookup default


          The rules are applied in ascending order, until a rule matches. If a packet is received on interfave eth1, rule 32765 matches, else the next rules are tried.



          You can now add routes to the vpn routing table. For example, to add a default route to your tunnel:



          ip route add default dev wg0 via 192.168.99.2 table vpn


          To print the vpn routing table, use



          ip route show table vpn


          Now, I haven't been able to actually test this, so there may be errors or some details missing. For more information on policy routing, see https://www.policyrouting.org or https://linux-ip.net.






          share|improve this answer















          You don't need two Ethernet interfaces. Define a host route via 192.168.1.1 to the public IP of the VPN server, and point the default route to the remote end of the tunnel (192.168.99.2). Make the default route on the other devices on your LAN point to 192.168.1.54. Remember to enable packet forwarding on your PC (sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1).



          EDIT: You cannot achieve the solution you are looking for with IPv4 classic routing, since classic routing is only concerned with where a packet is going, not its history, like which interface it was received on, or the source address. You will have to use Policy Routing to be able to classify packets based on the interface they were received on. Based on this classification you can then use an alternate routing table for routing, which, for example, defines a default route through your VPN tunnel.



          To use policy routing, you should add an entry (vpn) to /etc/iproute2/rt_tables:



          #
          # reserved values
          #
          255 local
          254 main
          253 default
          0 unspec
          #
          # local
          #
          1 vpn


          This gives the name vpn to routing table number 1.



          Next, add the following policy rule:



          ip rule add unicast iif eth1 table vpn


          This rule effectively says "if the packet comes in on interface eth1, use routing table vpn".



          You can check the rules with ip rule show:



          ip rule show
          0: from all lookup local
          32765: from all iif eth1 lookup vpn
          32766: from all lookup main
          32767: from all lookup default


          The rules are applied in ascending order, until a rule matches. If a packet is received on interfave eth1, rule 32765 matches, else the next rules are tried.



          You can now add routes to the vpn routing table. For example, to add a default route to your tunnel:



          ip route add default dev wg0 via 192.168.99.2 table vpn


          To print the vpn routing table, use



          ip route show table vpn


          Now, I haven't been able to actually test this, so there may be errors or some details missing. For more information on policy routing, see https://www.policyrouting.org or https://linux-ip.net.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Dec 16 '17 at 16:13

























          answered Dec 15 '17 at 20:40









          Johan MyréenJohan Myréen

          7,74711524




          7,74711524













          • Can you be a little bit more specific about routing? I have two interface, because there are other services running on this server (.54) which must be not affected in any way. "Define a host route" you mean I should create a static routing in my router (1.1) to the remote side 99.2? I can create a static routing for whole network only 99.0/24.

            – user66638
            Dec 15 '17 at 21:30











          • Point the default route to the remote end of the tunnel (192.168.99.2). --> I want to redirect only the eth1 traffic, not the whole network on the server.

            – user66638
            Dec 15 '17 at 21:52











          • Packet forwarding is based on routes, not interfaces. Routing tables are per host. Using basic routing, any packet received on any interface is subject to a routing decision based on the destination address. Please give more detail on what you want to achieve. Policy based routing might be the solution to your problem.

            – Johan Myréen
            Dec 16 '17 at 11:24



















          • Can you be a little bit more specific about routing? I have two interface, because there are other services running on this server (.54) which must be not affected in any way. "Define a host route" you mean I should create a static routing in my router (1.1) to the remote side 99.2? I can create a static routing for whole network only 99.0/24.

            – user66638
            Dec 15 '17 at 21:30











          • Point the default route to the remote end of the tunnel (192.168.99.2). --> I want to redirect only the eth1 traffic, not the whole network on the server.

            – user66638
            Dec 15 '17 at 21:52











          • Packet forwarding is based on routes, not interfaces. Routing tables are per host. Using basic routing, any packet received on any interface is subject to a routing decision based on the destination address. Please give more detail on what you want to achieve. Policy based routing might be the solution to your problem.

            – Johan Myréen
            Dec 16 '17 at 11:24

















          Can you be a little bit more specific about routing? I have two interface, because there are other services running on this server (.54) which must be not affected in any way. "Define a host route" you mean I should create a static routing in my router (1.1) to the remote side 99.2? I can create a static routing for whole network only 99.0/24.

          – user66638
          Dec 15 '17 at 21:30





          Can you be a little bit more specific about routing? I have two interface, because there are other services running on this server (.54) which must be not affected in any way. "Define a host route" you mean I should create a static routing in my router (1.1) to the remote side 99.2? I can create a static routing for whole network only 99.0/24.

          – user66638
          Dec 15 '17 at 21:30













          Point the default route to the remote end of the tunnel (192.168.99.2). --> I want to redirect only the eth1 traffic, not the whole network on the server.

          – user66638
          Dec 15 '17 at 21:52





          Point the default route to the remote end of the tunnel (192.168.99.2). --> I want to redirect only the eth1 traffic, not the whole network on the server.

          – user66638
          Dec 15 '17 at 21:52













          Packet forwarding is based on routes, not interfaces. Routing tables are per host. Using basic routing, any packet received on any interface is subject to a routing decision based on the destination address. Please give more detail on what you want to achieve. Policy based routing might be the solution to your problem.

          – Johan Myréen
          Dec 16 '17 at 11:24





          Packet forwarding is based on routes, not interfaces. Routing tables are per host. Using basic routing, any packet received on any interface is subject to a routing decision based on the destination address. Please give more detail on what you want to achieve. Policy based routing might be the solution to your problem.

          – Johan Myréen
          Dec 16 '17 at 11:24


















          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%2f411081%2froute-all-eth1-traffic-over-vpn%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

          Entries order in /etc/network/interfaces

          新発田市

          Grub takes very long (several minutes) to open Menu (in Multi-Boot-System)