these networks are related to our office local network, if i connect to vpn then i cant access to these networks
For me this was already logical.
Hence my comment in post 10 above.
Windows Client ?
Remove tick in “Block Untunneled Traffic” (Kill-switch)
When ticked: ALL traffic goes through the tunnel when using 0.0.0.0/0, no exception.
When unticked, traffic for which a local route exists (like local network), gets preference before being sent through the tunnel.
@holvoetn - interesting, not sure what you are getting at ref windows and ticks, did you leave the windows open and ticks are getting inside your house???
This is simply a case of masked intentions.
We know the allowed IPs of 0.0.0.0/0 means internet access and to wireguard interfaces as well by default.
However we didnt know that at least for one of the peers the idea was to get off the wireguard train and not go to the internet.
SO at the wireguard server in France, whilst stuffing your face with a baguette virtually sadly…
you need to add ensure that the peer is allowed to the LAN subnet in question. LETS SAY 0.4 in your example…
add chain=forward action=accept in-interface=wireguard src-address=192.168.200.4/32 dst-address=192.168.80.0/24
add chain=forward action=accept in-interface=wireguard src-address=192.168.200.4/32 dst-address=172.17.17.0/24
I am assuming the default ROUTE created by the IP wireguard interface address will suffice for return traffic back to the client from these subnets.
(DAC) dst-address=192.168.200.0/24 gateway=wireguard table=main
You’re so funny it hurts 
OP problem is not about what happens in France. It’s what happens in Iran.
Local traffic for local network needs to STAY there. Not go to France. That’s too late then.
So his client needs to be adjusted to do that.
If it’s a Windows client, disable the kill switch.
AND/OR (not sure how this logical operator needs to be set here …)
construct the allowed addresses in such a way that at the end ONLY those 2 subnets are NOT allowed to enter the tunnel (hence stay local). Not an easy task…
That’s how I understood the requirement. But it would help if the requirements were made a bit more clear using a bit more words…
SWEET …
Using this tool, it can be CALCULATED 
https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/
AllowedIPs = 0.0.0.0/1, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6, 172.0.0.0/12, 172.16.0.0/16, 172.17.0.0/20, 172.17.16.0/24, 172.17.18.0/23, 172.17.20.0/22, 172.17.24.0/21, 172.17.32.0/19, 172.17.64.0/18, 172.17.128.0/17, 172.18.0.0/15, 172.20.0.0/14, 172.24.0.0/13, 172.32.0.0/11, 172.64.0.0/10, 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.168.0.0/18, 192.168.64.0/20, 192.168.81.0/24, 192.168.82.0/23, 192.168.84.0/22, 192.168.88.0/21, 192.168.96.0/19, 192.168.128.0/17, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3
And 192.168.80.0/24, 172.17.17.0/24 will stay local then …
Not sure what you are getting at…
But in this case the allowed IPs is 0.0.0.0/0 which means any public IP out there, plus the subnets he wants to reach at the French Server Site. In this case the subnets are included so no need to try and get overly fancy~!~
Its easy and it works AND NOT PRONE TO ERRORS in entry
Finally use firewall rules if necessary where applicable to ensure users coming through wireguard go to where they are supposed to go.
As stated previously use IP routes and blackhole to block outgoing internet traffic destined for non-public addresses!!!
Neat link though!! It would be more appropriate if the OP said I want to users to be able to access ONLY the following subnets and not all of them…
Can you come up with a better, clearer example of where this might be advantageous? I would like to add it to my wireguard article with such an example…
As indicated in my post.
EVERYTHING gets from the client side injected into the tunnel EXCEPT those 2 subnets.
Those stay local for client.
Which is, as I understand, what OP wants to achieve.
Perhaps in case its you who misunderstood then…
The OP wants to from his client peer laptop to connect to the server in France via wireguard.
He wants to access the internet through his connection to France (not locally) and in addition he wants to access some subnets existing off the mikrotik in France.
The reason for both of our confusion is that in his config for France he never put in those subnets so we didnt know they existed. Rather unfair if you ask me.
/ip address
add address=xxx.xx2.230.10 interface=ether1 network=x.xx.65.254
add address=192.168.200.1/24 interface=wireguard network=192.168.200.0
where are they ???
++++++++++++++++++++++++++++++++++
If its the reverse he has not indicate a LOCAL OFFICE PEER, so if has one that is connecting to the SERVER in FRANCE, and if its a mikrotik device,
then he needs to come clean and give us that config as well. If its not a mikrotik device, then not our problem LOL…
OR thirdly
information left out and he is making assumptions we know whats going on without a network diagram or full knowledge.
As @Znevna once said: “Check yer peers!”.
xxx.xx2.230.10 is server address in France and x.xx.65.254 is the GW. 192.168.200.1/24 is the ip address for wiregaurd interface, i dont know its useful in my case or not
Hello again guys
i tried uncheck kill switch and procustodibus.com solution, both works.
forward chain is not working for my case, that two networks are connected to client not server, they must separate their ways at client side.
That is a client issue then and not germane to Mikrotik.
yes exactly.
and i need help for protecting my mikrotik. can you introduce some security rules for my firewall ? the only rule i know is for bogons addresses
https://forum.mikrotik.com/viewtopic.php?t=180838
but modified for your particular needs.
which means add input chain rules and forward chain rules as necessary.
Thank you all 