Wireguard provide settings Allowed IPs and Route Allowed IPs.
My lan is 192.168.20.1/24 and wg0 iface ip is 192.168.9.1/24. Allowed IPs are 192.168.9.6/32 (for remote wg0 iface) and 192.168.30.0/24 (for remote lan).
It works fine.
But now I need to allow any IPs in wg tunnel, but still routing only mentioned abow IPs.
(it is for correct communication between two igmpproxys in local and remote lan; igmpproxy add requireed routes automatically).
If I allow any IPs in wg0 and disable Route Allowed IPs both igmpproxys work fine (and mulicast udp stream routing as expected), but no access to remote lan and remote wg0.
I tried to add static routes using my local LUCI->Routing->Add Static IPv4 Routes (route to remote wg0 and remote lan) but in some reasone it does not work (try only one route: Iface = lan, Target = 192.168.30.0/24, Gateway 192.168.9.1, table = main).
How add static route to remote lan and wg0? (with LUCI)
You don't need to specify any gateway since WireGuard interfaces technically are point-to-point interfaces. In particular you shouldn't use an IP address of the OpenWrt router as gateway on the router itself!
I think it is impossible, due to I need packets with dst 192.168.30.0/24 be routed not just to wg0, but to proper remote peer (192.168.9.6), connected to my wg0 (I have 5 remote peers connected to wg0, 192.168.9.2...6).
So, I must use Allowed IPs and enable 'Route Allowed IPs'.
In this case multicast traffic will be dropped by wg
That should work as long as you made a route via the WG tunnel. I have a WG interface with mutiple peers (with various unique subnets reachable thru each of them), I simply make the route for the WG Interface, and the traffic goes to the correct peer.
Did you add the SRC subnet to that peer's allowed IP configuration at the remote end?
If Im setting local and remote Allowed IPs correctly (to point each other subnet, with route allowed ips enabled) then everithing work great except multicast stream: it received at remote wan, routed to remote wg and then dropped in wg tunnel because 224.0.0.0/4 not in Allowed IPs.
So my question is actually as follows: how to allow multicast IPs in WG and do not route it?
I cannot just add 224.0.0.0/4 to allowed ips because allowed ips must be routed but routing 224.0.0.0/4 will conflict with igmpproxy auto-added routing rules (I tested).
Perhaps you can explain why you want multicast over a tunnel - and we'll be better able to assist you.
You may want to use an Ethernet-based protocol thru the tunnel (e.g. Ethernet-over-IP), or a VPN solution that allows Layer 2 tunneling (e.g. OpenVPN).
It actually can work. See my first post: if allowed ips is 0.0.0.0/0 and route allowed ipsis disabled, multicast packets will not be dropped by remote wg0 and will appear as input on local wg0. I tested. It works.
remote wg0 disabled Route Allowed IPs: IP 224.0.0.0/4 (igmpproxy will route).
I need to route multicast traffic from remote wan to local lan. Thats what I need. To proxy igmp I install igmpproxy in local lan and remote lan and configured it.
I cannot connect networks on L2 level and OpenVPN is very slow on my router xiamir R3Gv1 (2-3 MB/s vs 9-10MB/s for WG)
(I really don't understand what all the routing/Allowed IPs for 224.0.0.0/4 means - unless you're posting it to simply disagree.)
Yes - somewhat unrelated to the actual multicast. In fact, if you're running igmpproxy, you usually don't setup/re-cofigure multicast - so this extra step is confusing me. That's what you're proxying (i.e. multicast traffic across interfaces - that use IGMP to subscribe to it).
To make multicast working I disable Route Allowed IPs. In this case all other communication (unicast) between subnets stops working.
Wireguard will drop any packets which are not in Allowed IPs. It will not work.
routing/Allowed IPs are Wireguard settings for peer.
Yes, you are right, igmpproxy does all the job: It automatically add/delete multicast routing rules when igmp join/leave received and resend them to upstream network. igmpproxys are configured to route multicast this way: remote wan > remote wg0 > local wg0 > local lan.
The only problem is that remote wg0 drops multicast IPs (224.0.0.0/4) because it is not in 'Allowed IPs' settings for remote peer.
Yea, I'm not sure if you're telling me a problem or you're confirming that you indeed turned off unicast routes. Disabling route allowed IPs has the behavior you describe (hence I asked you what's the problem).
I'd have to test this, I just don't understand what you mean. Sorry. It really seems like you're removing the Allowed IPs and subsequently wondering why they don't work. To be clear:
also, recall multicast IPs are not valid SRC addresses (multicast IPs are destination addresses - so I'd have to test to see how this affects multicast thru Wireguard)
allowed_ips filters based on the source IP of the packet. Multicast packets usually carry the regular unicast IP of their source, which is not in the 224/4 range, and it must be allowed.
The routing table(s) is based on the destination IP of a packet. route_allowed_ips is a convenience to identify possible source IPs, then install routes to send returning packets through the wireguard tunnel. This is part of the netifd script, not the kernel module. This is not necessary for multicast as there are no returning packets.
By default, Wireguard interfaces do not have the MULTICAST flag set, which will probably prevent multicasting through them.
You can set the multicast flag also via UCI for wireguard device (not the interface). I do this to enable dynamic routing protocols which use multicast.
Edit: PS: using just a dynamic routing protocol while disable the route IP option and just set /0 and ::0 as allowed ips also solves a lot of issues regarding the use of static routes but that be out of topic.
I created additional wg interface wg1 for local and remote hosts, connected them. In wg1Allowed IPs add 0.0.0.0/0 for both. Disabled Route Allowed IPs. Reconfigured igmpproxy,
Now unicast traffic routed via wg0, and multicast traffic routed via wg1.
Are you sure? It looks like it is based on destanetion IP, not source.
Thats why to communicate with remote subnet 192.168.30.0/24 you should add 192.168.30.0/24 to your local wg1 settings Allowed IPs for remote peer.
Ah that's news for me that it's now a default. With 22 I had to set it explicit.
Yes of course, that's why I said it's (for me) easier to just allow all traffic and use filters on the dynamic routing and firewall rules where needed.
Sorry gentlemen, I was terribly wrong.
You were right: Allowed IPs is about src, not dest as I thought.
However, if you try to send packet via wg tunnel with dest not in your local wg0's Allowed IPs (but src is in remote wg0's Allowed IPs) it will fail with error: Required key not available
For example:
root@OpenWrt:~# ping -I wg0 3.4.5.6
PING 3.4.5.6 (3.4.5.6): 56 data bytes
ping: sendto: Required key not available
Required key not available ... Can happen when you have a route directing traffic to the WireGuard interface, but that interface does not have the target address listed in its AllowedIPs configuration.
I beliave target address is dest, not src and this dst is blocked by local Alowed IPs.
also, recall multicast IPs are not valid SRC addresses (multicast IPs are destination addresses - so I'd have to test to see how this affects multicast thru Wireguard)