Wireguard multiple interfaces not working at the same time

[Dm1]

Connection tracking ensures that replied packets of incoming connection are router through the same interface. In my case wg1 is an incoming connection from a remote peer.

[lleachii]

@Dm1

Connection tracking ensures that replied packets of incoming connection are router through the same interface. In my case wg1 is an incoming connection from a remote peer.

Yes...I know what Connection Tracking is.

What I'm telling you is:

• You setup 2 WGs
• You incorrectly route all traffic through X
• You SEND a packet to the endpoint on tunnel Y
• It will be received at the remote end as long as you don't have an endpoint address set
• Endpoint Y is free to send the reply packet!
• You likely are not blocking for this, and remember you allowed 0.0.0.0/0 anyways. So connection tracking worked, it did come back on the same Interface!
• Even though you allowed 0.0.0.0/0, it doesn't matter, as I said before, I believe you made a route loop over the Internet (via your VPN).

Hope this helps you understand.

[Dm1]

• You incorrectly route all traffic through X

Well, that's what I really wanted

• You SEND a packet to the endpoint on tunnel Y

Y is a remote incoming connection though physical WAN, it's also behind NAT. It initiates connection through my physical WAN and because of connection tracking my wireguard reply should also go through it, not VPN. And as I said it works like this for FTP and HTTP services (they fail on physical WAN without connection tracking, but routed and working correctly when it's enabled) and doesn't work for wireguard. I can't understand the difference between incoming wireguard handshake and incoming passive FTP connection. Please help me to get it right

[lleachii]

@Dm1

Well, that's what I really wanted

Are you saying you do want WG1 to use WG0?

• If so, don't make a /32 route to endpoint-WG1.

@Dm1

Y is a remote incoming connection though physical WAN, it's also behind NAT. It initiates connection through my physical WAN and because of connection tracking my wireguard reply should also go through it, not VPN.

• This is why you WILL make a route to the endpoint via WAN. So that both WG interfaces use the real WAN to connect.

@Dm1

I can't understand the difference between incoming wireguard handshake and incoming passive FTP connection. Please help me to get it right

I'm sorry you're having issues understanding.

Perhaps you aren't recalling that a Wireguard interface is merely encrypted UDP traffic. So if you accidentally send Y traffic over X, you have to make a route for the IP of Y via WAN to fix that. Wireguard will receive the UDP packet, as long as the keys and allowed IPs are correct. You are responsible for routing the the UDP packets properly. Also recall, that once you initiated the UDP outbound, the reply packet is allowed.

[Dm1]

You're right! I've completely forgot that wireguard is UDP only protocol, that's the obvious difference to above mentioned HTTP and FTP services, which are working fine with this kind of setup.

[Dm1]

@lleachii

This is why you WILL make a route to the endpoint via WAN. So that both WG interfaces use the real WAN to connect.

But what if remote endpoint is behind a NAT with a dynamic IP? How to manage this case?

[lleachii]

@Dm1

But what if remote endpoint is behind a NAT with a dynamic IP? How to manage this case?

@lleachii

BTW, if wg1's peer (seems to be point-to-point and not a VPN provider) is behind a firewall, make sure the remote end has a keepalive.

At least one endpoint must have:

• a static IP and/or DDNS name
• an open UDP port

This is your "server endpoint" in Wireguard terminology; and I surmise that's the OpenWrt device we've been working with. I suggest the endpoint behind the firewall use an option persistent_keepalive '25'

For more information, see: https://www.wireguard.com/quickstart/#nat-and-firewall-traversal-persistence

[Dm1]

Yeah, I know about keepalive and that remote peer behind NAT is using 25. But it's not server endpoint, it's a client for wg1.

Server is OpenWRT router we are talking about, which has a static IP on WAN for incoming connections and outgoing wg0 VPN connection to the second remote endpoint server for default route.

It looks like this:

[ client endpoint behind NAT ] ---> [ (wg1) OpenWRT router with static IP (wg0) ] ---> [ VPN server endpoint with static IP ]

config interface 'wg0'
	option proto 'wireguard'
	list addresses '10.0.0.4/32'
	option private_key 'PRIVATE_KEY'
	option listen_port '55656'
	option metric '4'

config wireguard_wg0
	option public_key 'PUBLIC_KEY'
	option route_allowed_ips '1'
	option endpoint_host 'master.server.com'
	option persistent_keepalive '0'
	list allowed_ips '10.0.0.3/32'
	list allowed_ips '0.0.0.0/0'
	option endpoint_port '55655'

config interface 'wg1'
	option proto 'wireguard'
	list addresses '10.0.0.1/32'
	option private_key 'PRIVATE_KEY2'
	option listen_port '55655'
	option metric '1'

config wireguard_wg1
	option public_key 'PUBLIC_KEY2'
	option route_allowed_ips '1'
	list allowed_ips '10.0.0.2/32'
	list allowed_ips '172.17.1.0/24'
	option persistent_keepalive '0'

[lleachii]

@Dm1

But it's not server endpoint, it's a client.

Correct, I know. I just said that:

@lleachii

BTW, if wg1's peer (seems to be point-to-point and not a VPN provider) is behind a firewall, make sure the remote end has a keepalive.

@lleachii

I suggest the endpoint behind the firewall use an option persistent_keepalive '25'

@Dm1

Server is OpenWRT router we are talking about, which has a static IP on WAN for incoming connections and outgoing wireguard VPN connection to the second remote endpoint as default route.

We just covered all of this...are you still having an issue?
Obviously, the server doesn't need a keep alive, then - only clients

[Dm1]

@lleachii

We just covered all of this...are you still having an issue?

Well, you showed me the right direction to solve this issue. I've just made clear what I'm trying to achieve, because you wrote that remote endpoint needs a static IP, but in my case it didn't

Thanks for help! Now I understand why it doesn't work for me now and how to fix this.

[lleachii]

@Dm1

because you wrote that remote endpoint needs a static IP, but in my case it didn't

I did not. I said the SERVER needs a static IP and/or hostname. And as i said:

@lleachii

I surmise that's the OpenWrt device we've been working with

So, the remote endpoint would be the CLIENT, and hence need a keepalive.

Hope that clears any confusion.

@Dm1

Thanks for help! Now I understand why it doesn't work for me now and how to fix this.

[Dm1]

This was routable loopback problem described in OpenWRT documentation here: https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3#the_routable_loopback_self

That is why local wireguard fails when port forwarded services are working fine. Forwarded services are routed correctly through corresponding interface, but wireguard as a router originated traffic is always using default route. But routable loopback can also force the same behaviour for local services, such as wireguard in my case.

If wireguard had interface binding this problem would not exist, but for now it always uses source address based on default route.

[lleachii]

@Dm1

If wireguard had interface binding this problem would not exist, but for now it always uses source address based on default route.

What do you mean by this???

Are you saying that you also changed your lo address???

And that you're using the loopback as the DST of a PORT FORWARD TO THE WG's UDP INTERFACE!?!?

(You know, you could have just opened input on WAN, you don't need to port forward thru interfaces on your router.)

Also, if you're referring to binding pings, do the following command or add to sysctrl file:

echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr

I surmise you're referring to a misunderstanding of the encrypted traffic, though.

[Dm1]

Are you saying that you also changed your lo address???

Well, this is one of the possible ways to solve this problem. It has it's benefits, no need for static routing to make incoming connection from remote endpoint to work in this case. I don't care about its IP address any more.

Are you saying that you also changed your lo address???

In case there is nothing to break with such a configuration, why not?

And that you're using the loopback as the DST of a PORT FORWARD TO THE WG's UDP INTERFACE!?!?

I don't need this. It's wireguard with multiwan configuration needs such hacks to work properly, because it can't be bind to proper interface.

Also, if you're referring to binding pings, do the following command or add to sysctrl file

I don't think this will help in my case.

I surmise you're referring to a misunderstanding of the encrypted traffic, though.

Wireguard sends encrypted data over UDP, but UDP headers are not encrypted, connection can be routed how I want. Encryption changes nothing in this case.

You suggested one of the possible ways to deal with this:

config route
	option interface 'wan'
	option target 'REMOTE_PEER_IP/32'
	option gateway 'WAN_GATEWAY'

Wireguard handshakes successfully with such static routing. Nothing else needs to be changed. But the problem is that this configuration has its flaws, REMOTE_PEER_IP may change and wireguard will fail again. I've just found more universal way to tell wireguard how to work properly.

And of course, if wireguard had support interface binding, it'd just tell it to work on physical WAN only and had no such problems.