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):
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!
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.
@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.