MikroTik

Hi

i have a problem with wiregaurd, most of times when peers try to establish a connection to the server they receive this error:
"Receiving keepalive packet from peer 1"
until i disable related interface and then enable it again in Peers window.

you can see log file:


2022-04-06 08:29:20.967534: [MGR] Starting at boot WireGuard/0.5.3 (Windows 10.0.19044; amd64)
2022-04-06 08:29:21.772478: [MGR] Starting UI process for user ‘Mx@MEHRDADHP’ for session 1
2022-04-06 14:01:49.153321: [TUN] [MxServer] Starting WireGuard/0.5.3 (Windows 10.0.19044; amd64)
2022-04-06 14:01:49.153321: [TUN] [MxServer] Watching network interfaces
2022-04-06 14:01:49.157002: [TUN] [MxServer] Resolving DNS names
2022-04-06 14:01:49.157002: [TUN] [MxServer] Creating network adapter
2022-04-06 14:01:49.806482: [TUN] [MxServer] Using existing driver 0.10
2022-04-06 14:01:49.819450: [TUN] [MxServer] Creating adapter
2022-04-06 14:01:51.596104: [TUN] [MxServer] Using WireGuardNT/0.10
2022-04-06 14:01:51.695205: [TUN] [MxServer] Enabling firewall rules
2022-04-06 14:01:50.757179: [TUN] [MxServer] Interface created
2022-04-06 14:01:51.705490: [TUN] [MxServer] Dropping privileges
2022-04-06 14:01:51.706002: [TUN] [MxServer] Setting interface configuration
2022-04-06 14:01:51.706513: [TUN] [MxServer] Peer 1 created
2022-04-06 14:01:51.711243: [TUN] [MxServer] Monitoring MTU of default v4 routes
2022-04-06 14:01:51.711243: [TUN] [MxServer] Interface up
2022-04-06 14:01:51.716022: [TUN] [MxServer] Setting device v4 addresses
2022-04-06 14:01:51.882560: [TUN] [MxServer] Monitoring MTU of default v6 routes
2022-04-06 14:01:51.882560: [TUN] [MxServer] Setting device v6 addresses
2022-04-06 14:01:51.882560: [TUN] [MxServer] Sending handshake initiation to peer 1 (217.182.230.10:1994)
2022-04-06 14:01:51.995401: [TUN] [MxServer] Receiving handshake response from peer 1 (217.182.230.10:1994)
2022-04-06 14:01:51.995401: [TUN] [MxServer] Keypair 1 created for peer 1
2022-04-06 14:01:52.071084: [TUN] [MxServer] Startup complete
2022-04-06 14:02:02.403846: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:02:12.645862: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:02:23.527350: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:02:33.764654: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:02:44.639689: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:02:54.873890: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:03:05.118515: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:03:16.007498: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:03:26.880474: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:03:37.763780: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:03:48.648032: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:03:52.375007: [TUN] [MxServer] Sending handshake initiation to peer 1 (217.182.230.10:1994) [HERE I disable/enable the INTERFACE]
2022-04-06 14:03:52.470375: [TUN] [MxServer] Receiving handshake response from peer 1 (217.182.230.10:1994)
2022-04-06 14:03:52.470375: [TUN] [MxServer] Keypair 2 created for peer 1
2022-04-06 14:03:52.470375: [TUN] [MxServer] Sending keepalive packet to peer 1 (217.182.230.10:1994)
2022-04-06 14:04:03.366682: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:04:18.640586: [TUN] [MxServer] Retrying handshake with peer 1 (217.182.230.10:1994) because we stopped hearing back after 15 seconds
2022-04-06 14:04:18.640586: [TUN] [MxServer] Sending handshake initiation to peer 1 (217.182.230.10:1994)
2022-04-06 14:04:18.745233: [TUN] [MxServer] Receiving handshake response from peer 1 (217.182.230.10:1994)
2022-04-06 14:04:18.745233: [TUN] [MxServer] Keypair 1 destroyed for peer 1
2022-04-06 14:04:18.745233: [TUN] [MxServer] Keypair 3 created for peer 1
2022-04-06 14:04:18.745233: [TUN] [MxServer] Sending keepalive packet to peer 1 (217.182.230.10:1994)
2022-04-06 14:04:18.852471: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:06:15.775617: [TUN] [MxServer] Shutting down
2022-04-06 14:06:15.890089: [MGR] [MxServer] Tunnel service tracker finished
2022-04-06 14:07:33.348723: [TUN] [MxServer] Starting WireGuard/0.5.3 (Windows 10.0.19044; amd64)
2022-04-06 14:07:33.348723: [TUN] [MxServer] Watching network interfaces
2022-04-06 14:07:33.350802: [TUN] [MxServer] Resolving DNS names
2022-04-06 14:07:33.352465: [TUN] [MxServer] Creating network adapter
2022-04-06 14:07:33.818171: [TUN] [MxServer] Using existing driver 0.10
2022-04-06 14:07:33.837318: [TUN] [MxServer] Creating adapter
2022-04-06 14:07:35.724298: [TUN] [MxServer] Using WireGuardNT/0.10
2022-04-06 14:07:35.817100: [TUN] [MxServer] Enabling firewall rules
2022-04-06 14:07:34.845536: [TUN] [MxServer] Interface created
2022-04-06 14:07:35.833448: [TUN] [MxServer] Dropping privileges
2022-04-06 14:07:35.833935: [TUN] [MxServer] Setting interface configuration
2022-04-06 14:07:35.834940: [TUN] [MxServer] Peer 1 created
2022-04-06 14:07:35.836529: [TUN] [MxServer] Monitoring MTU of default v4 routes
2022-04-06 14:07:35.837529: [TUN] [MxServer] Setting device v4 addresses
2022-04-06 14:07:35.836529: [TUN] [MxServer] Interface up
2022-04-06 14:07:35.973189: [TUN] [MxServer] Sending handshake initiation to peer 1 (217.182.230.10:1994)
2022-04-06 14:07:36.054099: [TUN] [MxServer] Monitoring MTU of default v6 routes
2022-04-06 14:07:36.054099: [TUN] [MxServer] Setting device v6 addresses
2022-04-06 14:07:36.072090: [TUN] [MxServer] Receiving handshake response from peer 1 (217.182.230.10:1994)
2022-04-06 14:07:36.072090: [TUN] [MxServer] Keypair 1 created for peer 1
2022-04-06 14:07:36.143749: [TUN] [MxServer] Startup complete
2022-04-06 14:07:36.185496: [TUN] [MxServer] Receiving keepalive packet from peer 1 (217.182.230.10:1994)
2022-04-06 14:08:06.442426: [TUN] [MxServer] Shutting down
2022-04-06 14:08:06.556427: [MGR] [MxServer] Tunnel service tracker finished
2022-04-06 14:09:00.761208: [TUN] [MxServer] Starting WireGuard/0.5.3 (Windows 10.0.19044; amd64)
2022-04-06 14:09:00.761208: [TUN] [MxServer] Watching network interfaces
2022-04-06 14:09:00.765170: [TUN] [MxServer] Resolving DNS names
2022-04-06 14:09:00.765170: [TUN] [MxServer] Creating network adapter
2022-04-06 14:09:01.312059: [TUN] [MxServer] Using existing driver 0.10
2022-04-06 14:09:01.336526: [TUN] [MxServer] Creating adapter
2022-04-06 14:09:02.834761: [TUN] [MxServer] Using WireGuardNT/0.10
2022-04-06 14:09:02.935219: [TUN] [MxServer] Enabling firewall rules
2022-04-06 14:09:01.939680: [TUN] [MxServer] Interface created
2022-04-06 14:09:02.953402: [TUN] [MxServer] Dropping privileges
2022-04-06 14:09:02.953917: [TUN] [MxServer] Setting interface configuration
2022-04-06 14:09:02.954431: [TUN] [MxServer] Peer 1 created
2022-04-06 14:09:02.956517: [TUN] [MxServer] Monitoring MTU of default v4 routes
2022-04-06 14:09:02.956517: [TUN] [MxServer] Interface up
2022-04-06 14:09:02.977717: [TUN] [MxServer] Setting device v4 addresses
2022-04-06 14:09:03.008413: [TUN] [MxServer] Sending handshake initiation to peer 1 (217.182.230.10:1994)
2022-04-06 14:09:03.152842: [TUN] [MxServer] Receiving handshake response from peer 1 (217.182.230.10:1994)
2022-04-06 14:09:03.152842: [TUN] [MxServer] Keypair 1 created for peer 1
2022-04-06 14:09:03.269794: [TUN] [MxServer] Monitoring MTU of default v6 routes
2022-04-06 14:09:03.269794: [TUN] [MxServer] Setting device v6 addresses
2022-04-06 14:09:03.487860: [TUN] [MxServer] Startup complete
2022-04-06 14:09:25.451728: [TUN] [MxServer] Shutting down
2022-04-06 14:09:25.537838: [MGR] [MxServer] Tunnel service tracker finished


can you help me ?

Could be a mismatch in allowed addresses on one of the peers. They may not overlap !

Please post config of Mikrotik device (if that's the one serving wireguard to your Win client) so we can review.
Terminal
/export file=<anynameyouwish>
Review file for any left-overs of sensitive info and post between [Code] quotes.

But I am guessing here.
So you may also need to provide a bit more info on what is running where and how.

1. Network diagram
2. Mikrotik config /export file=anynameyouwish

and
3. detail the wireguard requirements
a. which is the server and which are the peers
b. wireguard settings for the peers....
c. detail which users need access to which services............

viewtopic.php?t=182340

... which is the server and which are the peers

touchy slip of the tongue ... they're all peers, dear Watson.

my server is in France and i am using this server as a vpn server.

Wiregaurd port is 1994, firewall rules are correct and in fact my config is simple.

its my server config:
and its for one of Peers:

As suspected.
Your allowed addresses overlap on the peers-definition of your Mikrotik device.

192.168.200.2/24 is the same as 192.168.200.3/24 as far as network address is concerned.

Should be like this:

/interface wireguard peers
add allowed-address=192.168.200.2/32 comment="My Mobile" endpoint-port=1994 \
interface=wireguard persistent-keepalive=25m public-key=\
"key1"
add allowed-address=192.168.200.3/32 comment="My Laptop" endpoint-port=1994 \
interface=wireguard persistent-keepalive=25m public-key=\
"key2"
add allowed-address=192.168.200.4/32 comment="My PC" endpoint-port=1994 \
interface=wireguard persistent-keepalive=25m public-key=\
"key3"
add allowed-address=192.168.200.5/32 comment=Saeed endpoint-port=1994 \
interface=wireguard persistent-keepalive=25m public-key=\
"key4"

I would also suggest to set keep-alive to 25.
That's seconds, not MINUTES.

my server is in France and i am using this server as a vpn server.

I ask for clarity for this very reason. The above text is gibberish and confuses the terms.
WHat WIREGUARD DEVICE is teh SERVER for the initial CONNECTION.

I am going to assume the France device is the wireguard Server.
and of course I am must be wrong because on the first peer I see this...........

add allowed-address=192.168.200.2/24 comment="My Mobile" endpoint-port=1994 \
interface=wireguard persistent-keepalive=25m public-key=\
"rQBcd3oa0fGFOGT/7opcVpikKdDSIyzbmUkO+OtjQT0="

The SERVER does not keep alive the peer its the other way around so this must not be the Wireguard server........
Hence confused again and too tired to deal with such inconsistencies at the moment.

Agree if indeed this is the WG server that all the PEER allowed IPs should reflect the address /32 and not /24

no the keep alives are not required on the WG settings !!!!!!!!!!

This is rather bizarre for input chain rules.........
/ip firewall filter
add action=accept chain=input comment=Winbpx dst-port=1993 protocol=tcp
add action=accept chain=input comment=VPN dst-port=\
1993,1945,1994,500,4500,1701 protocol=udp
add action=accept chain=input dst-port=1993,1945,1994,1723 protocol=tcp

There are no forward chain rules??
Also not clear where the incoming wireguard traffic is going.........
Edit- okay its internet bound traffic.

The wireguard address of mobile peers themselves, at the mobile device, should normally be set at /32 as well NOT /24.

no the keep alives are not required on the WG settings !!!!!!!!!!

They are for peers behind NAT (and especially CGNAT).

i set all prefixes to /32, until now everything is good.

my server is mikrotik cloud version on OVH datacenters, incoming traffic is going to the gateway (internet).

now i have another question, i want to exclude some network addresses from goings trough wiregaurd tunnel, can you help me ?

thank you so much, all of you.

This is rather bizarre for input chain rules.........
/ip firewall filter
add action=accept chain=input comment=Winbpx dst-port=1993 protocol=tcp
add action=accept chain=input comment=VPN dst-port=\
1993,1945,1994,500,4500,1701 protocol=udp
add action=accept chain=input dst-port=1993,1945,1994,1723 protocol=tcp

There are no forward chain rules??
Also not clear where the incoming wireguard traffic is going.........
Edit- okay its internet bound traffic.

you right, openvpn port is 1993 and winbox is 1993 too, i must change one of them.

now i have another question, i want to exclude some network addresses from goings trough wiregaurd tunnel, can you help me ?

Don't add those addresses in the allowed addresses, then.
Or narrow down the allowed range, split it up in one or more parts, so the addresses you want to exclude, are not allowed ... thus excluded.
Or use FW rules. Maybe easier.

More then one way to skin that cat.

Maybe best you clarify in detail what should not be allowed to pass where.
A simple drawing perhaps ?

no the keep alives are not required on the WG settings !!!!!!!!!!

They are for peers behind NAT (and especially CGNAT).

exactly! they are settings for and ON PEER devices, NOT peer settings on the MT server ;-PP

Not necessarily. The goal is to keep connection through NAT or firewall open, and whether it's done by packets from one side of the other doesn't matter.

now i have another question, i want to exclude some network addresses from goings trough wiregaurd tunnel, can you help me ?

Don't add those addresses in the allowed addresses, then.
Or narrow down the allowed range, split it up in one or more parts, so the addresses you want to exclude, are not allowed ... thus excluded.
Or use FW rules. Maybe easier.

More then one way to skin that cat.

Maybe best you clarify in detail what should not be allowed to pass where.
A simple drawing perhaps ?

i want all traffic go trough tunnel except these networks: 192.168.80.0/24, 172.17.17.0/24

Not necessarily. The goal is to keep connection through NAT or firewall open, and whether it's done by packets from one side of the other doesn't matter.

I agree that its possible but if the peer is behind NAt or CGnat or something else will it still work?? or trying to reach back to a laptop at a coffee shop?
The Op may turn the laptop on or off or the tunnel off and on etc........and its really the laptop that should keep the tunnel alive.

Don't add those addresses in the allowed addresses, then.
Or narrow down the allowed range, split it up in one or more parts, so the addresses you want to exclude, are not allowed ... thus excluded.
Or use FW rules. Maybe easier.

More then one way to skin that cat.

Maybe best you clarify in detail what should not be allowed to pass where.
A simple drawing perhaps ?

i want all traffic go trough tunnel except these networks: 192.168.80.0/24, 172.17.17.0/24

Wait a second here.......... We described an MT server in France that you had several mobile devices attached that would use the internet of the MT through the wireguard tunnels.
Where do these subnets NEW ones 192.168.80.0/24 and 172.17.17.0/24 come from?? Where are they located??

@anav: When connection is open and needs just some packets flowing to keep open, direction of packets doesn't matter. But I think you're right, if it's mobile device, keepalives from server are not ideal, because if device connects from one place, server will be sending keepalives to there "forever" (I don't know if there's some timeout and it gives up after long enough silence from the other side; possibly could be, but I don't remember seeing it mentioned anywhere) until device connects again from somewhere else.

@anav: When connection is open and needs just some packets flowing to keep open, direction of packets doesn't matter. But I think you're right, if it's mobile device, keepalives from server are not ideal, because if device connects from one place, server will be sending keepalives to there "forever" (I don't know if there's some timeout and it gives up after long enough silence from the other side; possibly could be, but I don't remember seeing it mentioned anywhere) until device connects again from somewhere else.

That was my concern, and the unknown behaviour of the MT side when no connection etc................

i want all traffic go trough tunnel except these networks: 192.168.80.0/24, 172.17.17.0/24

Wait a second here.......... We described an MT server in France that you had several mobile devices attached that would use the internet of the MT through the wireguard tunnels.
Where do these subnets NEW ones 192.168.80.0/24 and 172.17.17.0/24 come from?? Where are they located??

these networks are related to our office local network, if i connect to vpn then i cant access to these networks

@anav: When connection is open and needs just some packets flowing to keep open, direction of packets doesn't matter. But I think you're right, if it's mobile device, keepalives from server are not ideal, because if device connects from one place, server will be sending keepalives to there "forever" (I don't know if there's some timeout and it gives up after long enough silence from the other side; possibly could be, but I don't remember seeing it mentioned anywhere) until device connects again from somewhere else.

That was my concern, and the unknown behaviour of the MT side when no connection etc................

For me this was already logical.
Hence my comment in post 10 above.

Wait a second here.......... We described an MT server in France that you had several mobile devices attached that would use the internet of the MT through the wireguard tunnels.
Where do these subnets NEW ones 192.168.80.0/24 and 172.17.17.0/24 come from?? Where are they located??

these networks are related to our office local network, if i connect to vpn then i cant access to these networks

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

@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???

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 ... alculator/

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!".

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.

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.

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

viewtopic.php?t=180838

but modified for your particular needs.
which means add input chain rules and forward chain rules as necessary.

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