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

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

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

wg0 (wireguard client)

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 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 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         UG    204    0        0 eth2   U     0      0        0 wg0     U     202    0        0 eth0     U     203    0        0 eth1   U     204    0        0 eth2   U     0      0        0 eth1   U     0      0        0 eth0

ip route

default via dev eth2 proto dhcp src metric 204 dev wg0 proto kernel scope link src dev eth0 scope link src metric 202 dev eth1 scope link src metric 203 dev eth2 proto dhcp scope link src metric 204 dev eth1 proto kernel scope link src dev eth0 proto kernel scope link src 

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 
eth0             UP    
eth1             UP    
eth2             UP    
wg0              UNKNOWN 

ip route show table 51820

default dev wg0 scope link 

ip route show table main

default via dev eth2 proto dhcp src metric 205 dev wg0 proto kernel scope link src dev eth0 scope link src metric 202 dev eth2 proto dhcp scope link src metric 205 dev eth1 proto kernel scope link src linkdown dev eth0 proto kernel scope link src 

1 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 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 via, 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 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 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 network segment would still be eliminated, and the "eth1 laptop" would get its local IP address from the router's 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".

  • I appreciate your wide answer . Thank you very much!! First of all, do you want to update any more information to upload? I already post the command ip route show table 51820 and now I am going to update in my question with ip route show table 51820 . Do you want to change the IP address of eth1? I am willing to do everything you want. My router is a raspberry that I use it such as router. My english not very well. Do you suggest the first part of you answer to solve my problem or second with network switch? Thank you! Nov 7, 2023 at 13:30
  • The first part explains the requirements to solve the problem the way you intended, and why it requires configuring the upstream router too, which could be difficult or impossible. The second part with the network switch is how to solve the problem in a different way: I think it would be the easiest and most reliable way. The third part is a third way to solve the problem if you have other requirements that make the second solution not work for you.
    – telcoM
    Nov 7, 2023 at 13:42
  • So, recommended solution is the second part with network switch? This is very easy for me. The third part I already did it in the past with other machine to bridge two interfaces. Please, tell me. the first part must be avoid because is to difficult and has one more nat? Nov 7, 2023 at 13:56
  • Yes. The first part: a double NAT could cause other problems in the future and should be avoided. To avoid a double NAT, you must also be able to configure the router or else the solution will not work. Configuring a consumer-grade router to do the needful may be impossible. If the router is not yours to configure (locked by internet provider), it will be impossible for sure.
    – telcoM
    Nov 7, 2023 at 14:07
  • Would you like to explain what other problems in the future will cause NAT? My main router is mine not ISP and It has NAT there. I am able to handle it. Nov 8, 2023 at 8:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .