How to route traffic from ethernet interface to another?

Question

                 ---------------------------------
                 |                               |
                 |                               |
-----> eth2 (WAN)  --------> WG0-->------->----->  eth0 LAN 192.168.220.2
   192.168.14.7  |       |                       |
                 |       |   eth2 to eth1        |  
                 |       ->---->---------->----->  eth1 LAN  192.168.50.2
                  --------------------------------

I have a machine that has 3 ethernet interfaces and 1 wireguard client interface wg0.

eth2 (WAN) 192.168.14.7 (internet traffic comes from here)
eth0 (LAN) 192.168.220.2
eth1 (LAN) 192.168.50.2

wg0 (wireguard client) 10.125.146.2

My device works as wireguard client with wg0. Wireguard server is on VPS. I already forward traffic with iptables from wg0 to eth0 lan. So my laptop connected to eth0 192.168.220.2 with public IP from wg0.

If I connected my another laptop to eth1 the public IP is from wg0 too. I don't want it. I want to connect another laptop to eth1 192.168.50.2 without IP from wg0. I want eth1 to have the public IP that comes from eth2 WAN.

Is it possible to do that?

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.14.1    0.0.0.0         UG    204    0        0 eth2
10.125.146.0    0.0.0.0         255.255.255.0   U     0      0        0 wg0
169.254.0.0     0.0.0.0         255.255.0.0     U     202    0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     203    0        0 eth1
192.168.14.0    0.0.0.0         255.255.255.0   U     204    0        0 eth2
192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.220.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

ip route

default via 192.168.14.1 dev eth2 proto dhcp src 192.168.14.7 metric 204 
10.125.146.0/24 dev wg0 proto kernel scope link src 10.125.146.2 
169.254.0.0/16 dev eth0 scope link src 169.254.50.120 metric 202 
169.254.0.0/16 dev eth1 scope link src 169.254.231.124 metric 203 
192.168.14.0/24 dev eth2 proto dhcp scope link src 192.168.14.7 metric 204 
192.168.50.0/24 dev eth1 proto kernel scope link src 192.168.50.2 
192.168.220.0/24 dev eth0 proto kernel scope link src 192.168.220.2 

ip rule show

0:  from all lookup local
32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
32767:  from all lookup default

ip -4 -br addr

lo               UNKNOWN        127.0.0.1/8 
eth0             UP             192.168.220.2/24 169.254.50.120/16 
eth1             UP             192.168.50.2/24 169.254.231.124/16 
eth2             UP             192.168.14.7/24 
wg0              UNKNOWN        10.125.146.2/24 

ip route show table 51820

default dev wg0 scope link 

ip route show table main

default via 192.168.14.1 dev eth2 proto dhcp src 192.168.14.7 metric 205 
10.125.146.0/24 dev wg0 proto kernel scope link src 10.125.146.2 
169.254.0.0/16 dev eth0 scope link src 169.254.50.120 metric 202 
192.168.14.0/24 dev eth2 proto dhcp scope link src 192.168.14.7 metric 205 
192.168.50.0/24 dev eth1 proto kernel scope link src 192.168.50.2 linkdown 
192.168.220.0/24 dev eth0 proto kernel scope link src 192.168.220.2 

Answer 1

Your eth2 IP address starts with 192.168, which means it is not a public IP in the first place. Your eth2 interface must be connected to a router, firewall or some other NAT-capable device that holds the only non-VPN public IP address in this group of network segments.

Your system has some advanced routing rules in effect, most likely created by the Wireguard VPN.

0:  from all lookup local                      <- default rule
32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main                   <- default rule
32767:  from all lookup default                <- default rule

The number in the leftmost column is the priority of the routing rule specified on each line.

• The rule with priority 0 is standard, and essentially means: "any traffic addressed to this system's own addresses will be processed locally using the appropriate source address."
• Priority 32764 line means: "for everything else, use the standard main routing table but ignore the default gateway entry." This rule seems to handle basically all traffic that is not going to the default gateway.
• Priority 32765 line means: "any traffic that has not been marked with fwmark 0xca6c will be processed using routing table 51820." This most likely means any traffic that is going to go out through the default gateway but has not yet been processed through Wireguard.
• Priority 32766 is another default rule, basically saying "for anything that's not been successfully routed up to this point, use the standard main routing table as-is." When Wireguard is active, this will be used only for the encrypted Wireguard traffic towards the VPS Wireguard server.
• Priority 32767 is yet another default rule, sending anything that was not covered by the main routing table to processing through another table named default, which will normally be empty unless some custom post-processing is required.

Both your route -n and ip route commands display the main routing table. You can verify this by using the full form of the ip route command: ip route show table main.

It would also be necessary to see the output of ip route show table 51820 in order to fully understand how Wireguard affects the routing.

If you want the device(s) plugged into eth1 to bypass the Wireguard VPN and use the non-VPN public IP, you would have to configure three things:

• you would have to find a way to configure a routing rule for outgoing traffic from network 192.168.50.0/24 in such a way that the Wireguard client will not override it. Without knowing the output of ip route show table 51820 I don't think I can suggest any exact commands here.
• you would have to configure the router to which your eth2 is connected with the equivalent of ip route add 192.168.50.0/24 via 192.168.14.7, so it will know that behind your device is another network segment. Otherwise it will not know what to do with any responses to connections initiated by any device plugged into your eth1, and will just reject them.
• you would have to configure the router to which your eth2 is connected to also perform NAT for the 192.168.50.0/24 network segment. You might be lucky and find out that the router will NAT all private 192.168.. network segments by default. Or not.

If the router is not configurable by you, or if the router is a consumer-grade device that is not flexible enough to be configured that way, doing this using routing will be impossible; see below.

---

An alternative approach, that would probably be more reliable, easier to understand and troubleshoot, and essentially independent of the ability to configure the router would be:

1. Get a network switch with the appropriate speed rating, and one extra network cable. Unless you have additional requirements, a cheap non-manageable 5-port switch should be fine.
2. Disconnect the WAN cable from the eth2 interface of your device and plug it into the first port of the switch.
3. Connect the new network cable to the second port of the switch and plug the other end of the cable to eth2 of your device.
4. Disconnect the other laptop from eth1 of your device, and plug it to the third port of the switch.
5. Done.

If the router has unused network ports you can use, you won't even need the switch: just plug the "eth1 laptop" directly to the router.

Obviously, any variation of this solution will make the "eth1 laptop" get a 192.168.14.* address from the router, and will effectively eliminate the 192.168.50.0/24 network segment altogether. The eth1 interface of your device would be left unused.

Also, if there was any serious security requirements to keep the VPN traffic separated from the non-VPN traffic, this would be the only type of solution I would recommend.

---

If the traffic to the "eth1 laptop" must pass through your device, but you cannot configure the router upstream of your eth2, then you might consider bridging the eth1 and eth2 network interfaces instead of futilely trying to solve this with routing.

Your device's default gateway would then be associated with the bridge device instead of the individual eth2 interface, and you would be able to use ebtables for filtering traffic to the "eth1 laptop" much like iptables in the routing case. The separate 192.168.50.0/24 network segment would still be eliminated, and the "eth1 laptop" would get its local IP address from the router's 192.168.14.0/24 network segment.

However, I don't know if the Wireguard client will work in a system that is configured for bridging. I don't see why it shouldn't, but if the client is programmed to prevent your VPN from "leaking", doing what you want (whether by routing or bridging) would look like an intentional "leak" for Wireguard.

---

I also briefly considered and rejected a solution that would involve a double NAT. Personally I find those tend to trade a minor convenience right now to an unknowable amount of troubleshooting pain later. That's a bad trade. Just say "no".