Wireguard stops routing when restarting the interface connection

mschae · August 14, 2019, 11:26am

Hey there,

I switched back to OpenWRT yesterday, as hardware I am using a Fritz!Box 4040, which works like a charm. I am running 18.06.04 which I downloaded from the Fritz!Box device page.

One problem I have is with Wireguard tho: I have the most classic szenario (I think) where remote devices connect to my home LAN via Wireguard.
After setting everything up via LEDE the wireguard interface wasn't working ("Network device not present"). A restart fixed this. I then set up peers, which again required me to restart the router.
After detecting a configuration error with one of my peers this morning I (remotely) fixed the issue and restarted the interface. This caused my remote clients to loose connection to anything (the lan, the wireguard interface, ...). The handshake works and I receive keepalive packets, but pinging either a LAN IP or the Wireguard Interface's IP results in timeouts. I am guessing that a restart of my router will fix this (again), although I can't verify as I cannot access the router anymore...

Here is the relevant part of my config (my LAN is on the 10.222.0.1/24 subnet):

My OpenWRT Router's config:

config interface 'wireguard'
	option proto 'wireguard'
	option private_key 'XXX'
	option listen_port '51820'
	list addresses '10.222.200.1/24'

config wireguard_wireguard
	option public_key 'XXX'
	list allowed_ips '10.222.200.2/24'
	option route_allowed_ips '1'
	option persistent_keepalive '25'
	option description 'XXX'

config wireguard_wireguard
	option public_key 'XXX'
	list allowed_ips '10.222.200.3/24'
	option route_allowed_ips '1'
	option persistent_keepalive '25'
	option description 'XXX'

config wireguard_wireguard
	option description 'XXX'
	option public_key 'XXX'
	list allowed_ips '10.222.200.4/24'
	option route_allowed_ips '1'
	option persistent_keepalive '25'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan wireguard'

config rule
	option enabled '1'
	option target 'ACCEPT'
	option src 'wan'
	option proto 'udp'
	option dest_port '51820'
	option name 'Allow Wireguard inbound'

My client config:

[Interface]
PrivateKey = XXX
Address = 10.222.200.3/24

[Peer]
PublicKey = XXX
AllowedIPs = 10.222.0.1/16
Endpoint = XXX:51820

Any ideas what would cause connectivity to be lost when I change the configuration/restart the interface?

Thanks

lleachii · August 14, 2019, 2:08pm

@mschae, welcome to the community!

Change to /32, the rest of whole network is not on the other end of those three peers.

See: https://www.wireguard.com/#cryptokey-routing

mschae · August 14, 2019, 2:31pm

Thanks so much @lleachii!

Just so I understand correctly: I can't ping LAN or WG Server IPs because the WG Interface on the router drops my packages, correct? Are they being dropped because the last entry overwrites the formet two? Because from my understanding while the /24 subnet is clearly a mistake, it should still allow packages from that subnet with the correct signature. Or am I missing something else?

I wasn't aware the allowed_ips are part of the cryptographic protocol, thanks for enlightening me!

Cheers

lleachii · August 14, 2019, 2:41pm

I'm not sure what you mean. You misconfigured your peers - that's why they don't work. Simple.

I don't see an entry that "overwrites the former two"...and I have 0 clue what you mean.

Your router is addressed 10.222.200.1/24, so it's mathematically impossible that: 10.222.200.2, 10.222.200.3 and 10.222.200.4 also have a /24 space on them. I'm not sure what logic you're using to come to the overwriting conclusion.

You need to look more at the Cryptokey Routing page:

In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list.

This is what we call a Cryptokey Routing Table : the simple association of public keys and allowed IPs.

...

Because all packets sent on the WireGuard interface are encrypted and authenticated, and because there is such a tight coupling between the identity of a peer and the allowed IP address of a peer, system administrators do not need complicated firewall extensions, such as in the case of IPsec, but rather they can simply match on "is it from this IP? on this interface?", and be assured that it is a secure and authentic packet. This greatly simplifies network management and access control, and provides a great deal more assurance that your iptables rules are actually doing what you intended for them to do.

mschae · August 14, 2019, 2:56pm

@lleachii Let me take a step back and explain why I am still asking questions even though you pointed out my mistake: I am trying to better understand wireguard and its behaviour. If you don't feel like (or don't have the time) to further explain just le me know, I'd understand.

Before I had peers "two" and "three" on different subnets (10.222.0.3/24 and 10.222.0.4/24 respectively). So peer one (10.222.200.2/24) was the only one on the "correct" tunnel subnet and it worked (packages weren't dropped). Despite the interface having the address 10.222.0.1/24.

Now by "fixing" peers "two" and "three" to all being on the 10.222.200.0/24 subnet I messed it up. Now I am trying to understand what wireguard does:

Does it only allow one peer on one subnet and therefore only accepts the last peer's subnet (that's what I meant with overwriting).
Does is simply discard the peers as they are misconfigured (in which case I'm surprised the handshake works).
Is something else going on?

So TL;DR: I understand what I did wrong. I understand how to fix it. Thanks for that! Now I am trying to understand what behaviour my mistake caused.

lleachii · August 14, 2019, 4:24pm

That's a valid configuration; and BTW, mentioned nowhere in the original post above. You can have IPs from other subnets at the far end of a Layer 3 tunnel.

Not sure why you use terms "fixing" since it wasn't broken.

From setting up a test, I did notice something interesting - this may help you understand:

#in /etc/config/network

config interface 'test'                                                    
        option proto 'wireguard'                                         
        option private_key 'xxxxxxx='
        option listen_port '22222'                                       
        list addresses '10.222.0.1/24'                                     
                                                                         
config wireguard_test                         
        option public_key 'xxxxxxx=' 
        list allowed_ips '10.222.0.2/24'

Produced:

root@OpenWrt:~# wg
interface: test
  public key: xxxxxxx=
  private key: (hidden)
  listening port: 22222

peer: xxxxxxx=
  endpoint: 10.xxx.xxx.xxx:57476
  allowed ips: 10.222.0.0/24
  latest handshake: 39 seconds ago
  transfer: 1.29 MiB received, 21.32 MiB sent

(Notice the allowed IPs.)

system · August 24, 2019, 4:24pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.