More importantly are you saying that at the MT DEVICE (client) and where the server is found, that it has two peers in its Wireguard Settings
peer1 = server
peer2 =mobile client (this would be impossible unless it is okay for the exchange of public keys will make this work!! ??? THIS IS THE LINK I HAVE BEEN MSSING!!!
arrgg makes no sense cannot have peer to peer like this both are clients my bad…
okay my original thoughts were correct you verbalized them differently as usual LOL
Another riddle, to help me understand firewall rule required at the VPS Serer, what if the VPS server was an MT device,
Assuming drop rules, would you need any firewall rules for the relay of mobile client traffic from laptop to MT server to MTClient (camera)
If it was two separate wg interfaces it would be clear to me how to apply firewall rules to relay…
add chain=forward action=accept in-interface=wg1 out-interface=wg2 src-address=mobile client IP.
So what you are saying is that at the VPS linux if it was an MT device would need something like this that looks almost SILLY. (as interfaces are the same)
add chain=forward action=accept in-interface=wg0 out-interface=wg0 src-address=mobile client IP ???
So in the end, to have a relay function is perfectly reasonable by only using ONE WG interface.
This works as long as we realize that each peer to peer connection is separate and that traffic that arrives from one end to an MT RELAY device, is considered now LOCAL and thus why
a. We need a firewall rule as bizarre as it seems at the RELAY device, to ensure traffic then re-enters the tunnel for the next leg.
add chain=forward action=accept in-interface=wg-name out-interface=wg-name src-address=mobile client.
b. We need an IP route for the destination traffic (like the allowed IP on the mobile client which matched and selected traffic outbound from the user at the mobile client) and this traffic is now local to the RELAY device, and thus has to go through the same process/configuration → to match and select ‘local’ traffic we have to include the destination address in
i; allowed IPs for the Relay device (allocated to the peer where we are relaying the traffic too)
ii; create an IP route for that traffic (for destination IP to enter WG interface)
IP address 192.168.0.20/24 gives client connected route to whole 192.168.0.0/24 subnet, i.e. all 192.168.0.x addresses. So it knows where to find server (.1), camera’s WG client (.10), even some future cameras (.11, .12, …), etc. It’s WG subnet and if it’s /24, then all devices should (in most cases) have IP addresses with /24. It’s slightly different for allowed IPs, server/VPS should have 192.168.0.x/32 for each peer, because they each have only one IP address from this subnet and have no reason to use others. But clients should have 192.168.0.0/24, because server can relay to them traffic from all other peers, so it needs to be allowed.
And yes, on server/VPS, traffic between peers will match in-interface=wg0 out-interface=wg0, there’s nothing wrong with that, that’s what happens, both incoming and outgoing interface is WG.
Got it, understood, where required the allowed IPs needs to be specific but the iP address need not be fixed for mobile clients that have ADDRESS assigned within the Wireguard parameters.
As for the other issue SAME interface at the Relay device in the firewall rule makes sense.
It mirrors a solution I had proposed for a similar relay but using TWO wireguard interfaces.
The key is that each connection is peer to peer so at the relay site, the traffic should be considered having exited the tunnel and now needs a route and firewall permission to rententer the next tunnel.
hence why allowed IP at originating mobile client (aka the destination IP) is then added to the end client device in its peer settings at the relay device, and why also at the relay device one needs to create a route for that destination IP with the applicable wg interface gateway.
What is really cool is the sense that the one tunnel solution is more efficient because this rule works for both directions!
in-interface=wg0 out-interface=wg0 src-address=192.168.0.20/32
whereas in my dual tunnel Relay example (iphone to relay device, out different tunnel (aka 3rd party VPN provider) I need two firewall rules at the MT RElay device.
one to allow iphone to 3rd party VPN, one to allow response from 3rd party VPN to iphone
in-interface=wg-local1 out-interface=wg-local2 src-address=IPof IPhone
in-interface=wg-local2 out-interface=wg-local2 src-address=IPof IPhone
Until you realize that this rule with all three conditions makes sense for only one direction, then it becomes less cool. 
Dont follow you at all…
Traffic all the way along has one source address, that of the mobile client (be it iphone or laptop).
so that part of the rule is fine… if there was another mobile client involved, then
you would create a source address list at the RELAY Device,
Return traffic to the mobile client (ipad, laptop) after hitting the camera server at the MT client end, hits the RELAY device at the same wireguard interface!!
Therefore the rule is valid in both directions… it will come out the interface, it will have destination traffic for mobile client, the IP route for the mobile client on the SERVER will see that it has to go to the wg interface, the firewall rule will allow it and the return traffic will get peer matched and selected to the mobile client and be on its merry way.
Where is the issue…
Don’t overthink it. 
If you say “works for both directions”, I’d expect that device A can initiate connections to device B, and also device B can initiate connection to device A. So .20->.10 and .10->20. And it would be true if you had only in/out-interface=wg0. But if there’s also src-address=192.168.0.20/32, then it allows connections only from .20.
Your nitpickyness is annoying and sometime infuriating ( I swear you are trying to give me an ulcer - then i realized sometimes I am as vague LOL but not out of spite, or lazyness but because I dont know any better ;-PP) I didnt mean to imply it works both ways for ALL traffic, but ONLY for the finite example I was discussing, which was a mobile laptop remote client accessing a camera server hosted on a remote MT client, both with WG to the VPS server (RELAY device). Clearly this traffic retains its source IP as 192.168.0.20/32 during its phucking travels…
Thus in-interface=wg0 out-interface=wg0 src-address=192.168.0.20/32 is VALID if the traffic pops out of the tunnel at the RELAY device from either the originating mobile client or the return traffic pops out of the tunnel at the RELAY device from the MT client…
My comment was, simply how convenient compared to the other example where I use two separate wireguard interfaces and then one needs two separate firewall rules at the SERVER.
To make you happy, then simply dont use a source address with that rule and then any traffic coming out of the tunnel can go back in the tunnel in terms of firewall scrutiny and then it would be truly two way for all. I suppose the IP routes and allowed IPs (routing squared) would be enough to direct the traffic correctly but I prefer to use the firewall for its intended purpose (impose admin control and limit traffic to only that which is required).
In any case I have adjusted the main article text based on your input/minor almost trivial concerns and at some point will get to the examples.
Well, you don’t have to have two separate firewall rules if you have two WG interfaces … just create interface list and use that in FW rule …
That is another option of course… Which I believe I had already mentioned in a previous post but a reminder is always nice!
However what you say is valid for the SAME WG interface, not two distinct wg interfaces unless you go ALL in with the following LOL
Unless you mean
add chain=forward in-interface-list=WG-interfaceS out-interface-list=WG-interfaceS source-address-list=MultipleSources ( catches all )
Few things about that:
You hit the nail on the head, tough love, or better tough instructing. The more accurate and clear I am the quieter you are! Why dont I seem to learn that lesson LOL.
All good info when I get to the examples, I keep tweaking the article so do pop in from time to time to let me know anything else that bugs you…