Arch Linux

Beemo

Member

Registered: 2024-12-20

Posts: 65

[Solved] Kernel forwarding in and out of the same interface?

I'm putting WireGuard on my VPS to forward all my Internet traffic. It seems that both the WireGuard and Ethernet interface will need to enable forwarding. However I worry about enabling forwarding on the Ethernet interface. Does it mean that anyone on the Internet will be able to use my VPS to forward traffic by setting their gateway to my VPS' IP? Do I need firewall rules to drop forwarding traffic that is both in and out of the Ethernet interface?
Most info I saw online says forwarding is between interfaces, but others say it's possible. Which is right?

Last edited by Beemo (2024-12-29 16:44:43)

-thc

Member

Registered: 2017-03-15

Posts: 1,066

Re: [Solved] Kernel forwarding in and out of the same interface?

I'm putting WireGuard on my VPS to forward all my Internet traffic. It seems that both the WireGuard and Ethernet interface will need to enable forwarding. However I worry about enabling forwarding on the Ethernet interface. Does it mean that anyone on the Internet will be able to use my VPS to forward traffic by setting their gateway to my VPS' IP?

Yes.

Do I need firewall rules to drop forwarding traffic that is both in and out of the Ethernet interface?
Most info I saw online says forwarding is between interfaces, but others say it's possible. Which is right?

Whatever you do with a VPS on the net - firewalling is IMHO a must.

Only allow forwarding new connections from the WireGuard interface to the ethernet interface.

Beemo

Member

Registered: 2024-12-20

Posts: 65

Re: [Solved] Kernel forwarding in and out of the same interface?

I glanced through RFC1122 and RFC1812 mentioned in IP sysctl, and I think there is no such restriction about different interfaces at least on protocol level, though even sysctl documentation itself calls the forwading option "Forward Packets between interfaces". I also couldn't find any sysctl option about turning on or off the same-interface forwarding.
Overall it's pretty murky so I guess adding some firewall rules just in case.

ip_forward - BOOLEAN
        0 - disabled (default)
        not 0 - enabled
    Forward Packets between interfaces.

we use the term "local source-routing" if the next hop will be through the same physical interface through which the datagram arrived
...
A host is permitted to perform local source-routing without restriction.

Though normally we have destination routing.

The packet is passed to the forwarder in all other cases.

P.S.
A suggestion for Arch wiki: Forwarding, masquerade and firewall policy can be set within systemd-networkd config, no need to go everywhere to turn on stuff. Putting the following in sysctl.conf is not good:

net.ipv4.ip_forward = 1  # Turns on forwarding for ALL interfaces
net.ipv[46].conf.<interface_name>.forwarding=1  # Can fail at boot, when it's applied before interface is up

Last edited by Beemo (2024-12-29 22:29:21)

Beemo

Member

Registered: 2024-12-20

Posts: 65

Re: [Solved] Kernel forwarding in and out of the same interface?

P.S. I had to shorten the title in order to mark this as solved.

cryptearth

Member

Registered: 2024-02-03

Posts: 1,859

Re: [Solved] Kernel forwarding in and out of the same interface?

to untangle to confusion: when you setup a vpn you will create a virtual NIC (a tun or tap) and the routing will then be in software between the vpn endpoint and the physical nic - so NO, no "ANYONE" can route traffic through your vpn - but only those who are able to connect to it - which, when you set it up only for yourself, should be you only
just because I know your vps ip and that it has a vpn running doesn't help me anything as long as I don't know credentials to connect to the vpn - which I recommend a-sym key pair for - but most software should also support username and password or other types of login

Beemo

Member

Registered: 2024-12-20

Posts: 65

Re: [Solved] Kernel forwarding in and out of the same interface?

I just realized this might be totally possible.
There is a configuration where a WireGuard peer / server is used like a router to reach other peers (instead of connecting them directly), and the config basically boils down to enabling forwarding on the server and route the traffic to the server.
So this is definitely possible with a WireGuard interface. Now WireGuard is slightly weird protocol-wise so I don't know if this applies to normal Ethernet interface.

p.s. example

Last edited by Beemo (2024-12-30 18:15:06)

-thc

Member

Registered: 2017-03-15

Posts: 1,066

Re: [Solved] Kernel forwarding in and out of the same interface?

to untangle to confusion: when you setup a vpn you will create a virtual NIC (a tun or tap) and the routing will then be in software between the vpn endpoint and the physical nic - so NO, no "ANYONE" can route traffic through your vpn - but only those who are able to connect to it - which, when you set it up only for yourself, should be you only
just because I know your vps ip and that it has a vpn running doesn't help me anything as long as I don't know credentials to connect to the vpn - which I recommend a-sym key pair for - but most software should also support username and password or other types of login

Do not mix up "VPN connectivity" with "network connectivity". Of course only clients with valid credentials can connect to the VPN endpoint.

After those clients are connected and the routing (wg <-> eth by WireGuard) is in place and forwarding is unrestricted everybody on the net with knowledge of the internal WireGuard client IP addresses can route packets to them (which was the initial question). Every other internet host can also be routed through that VPS (eth0 -> eth0 forwarding) but that's a bit pointless.

cryptearth

Member

Registered: 2024-02-03

Posts: 1,859

Re: [Solved] Kernel forwarding in and out of the same interface?

I question how this attack could work unless the attacker has a system within the same physical subnet to route packets directly to the servers nic via addressing it by the mac address in the ethernet frame - as anything comming from extern would rely on addressing the non-routable vpn-internal ip as destitionation ip - which obviously doesn't work
so any packet addressed to the public ip of the vps would terminate there - I don't see any way -aside from a physical local neighbor - how one could send a packet to the vps from any external network for it to get forwarded via the vpn tunnel - even if the firewall is wrongly setup to redirect/route any incoming traffic via the vpn tunnel - as the vpn client on the other side would throw it away because the destination ip doesn't match the vpn endpoint
can you explain a possible attack scenario how this could be possible without a local neighbor to abuse direct ethernet mac addressing?

Beemo

Member

Registered: 2024-12-20

Posts: 65

Re: [Solved] Kernel forwarding in and out of the same interface?

anything comming from extern would rely on addressing the non-routable vpn-internal ip as destitionation ip

everybody on the net with knowledge of the internal WireGuard client IP addresses can route packets to them

It's possible if the WireGuard interface / peer has a global (not private) address. This is common in IPv6 to give client a public IPv6 address that can accept incoming connections (unlike NAT), similar to what the tunnel brokers are doing (route64 WireGuard, he SIT).

Every other internet host can also be routed through that VPS (eth0 -> eth0 forwarding)

Actually this was I was worried about, being used as proxy to forward malicious traffic, though Idk on how it's practically done. IPv4 reverse path filtering is off by default, so they can spoof the source address as coming from my WG subnet and let the Ethernet interface forward the traffic (And because I'm doing the usual IPv4 masquerade, it will appear to have come from me).
Not sure if it's still meaningful when rp_filter is strict (they can't hide the IP but can still use the VPS as proxy).

P.S.
Plus the masquerade option in systemd-networkd is quite limited, and I can't restrict it to "source=my subnet" only. If I forward the wrong thing, dead.
EDIT: Never mind this, IPMasquerade in systemd-networkd has been IMO completely useless for 7 years. It restricts the source address as the same subnet as the Interface.

Last edited by Beemo (2024-12-30 19:14:05)

-thc

Member

Registered: 2017-03-15

Posts: 1,066

Re: [Solved] Kernel forwarding in and out of the same interface?

@cryptearth

On the physical Ethernet level you are right - without ARP you would not be able to reach the VPS server. That problem ends outside the Ethernet segment of the VPS provider.

On the VPS itself - once the "foreign" packet arrived via eth interface from outside - it's just routing/forwarding and not even in a specific direction.

But the OP asked specifically for this scenario:

You have a VPN-Server based on WireGuard located in a public IP space somewhere. You set up the client connections via keys and set the appropriate IP addresses inside the configurations. Forwarding between all interfaces is unrestricted. Connecting to the VPN endpoint (the wg interface) is only possible for valid keys.

Vector:

An attacker with inside knowledge (WireGuard's internal IP addresses, open ports on the client) can either set the default gateway to the VPN servers public IP address or set a route to the VPN's internal IPs via this public address. The attacker can ping the VPN client via VPN address and reach open ports that are bound to all addresses or the VPN address. The attacker uses the VPN "in the opposite direction".

Last edited by -thc (2024-12-30 18:56:40)