When you do that, you should see both the installed-sa to count packets and bytes; if the pings from the Sophos are the only traffic and you run /ip ipsec installed-sa print detail interval=1s, you should see the packet counters in both directions to grow by one every second.
The behavior where one side can ping the other but not vice versa is a normal one for stateful firewalls - whether the packet between two addresses will pass through or not depends on which party has initiated that connection. The typical behavior is that a firewall allows connections that an “inside” client establishes towards “outside” servers (aka outbound connections), but not inbound ones. It is also normal that a VPN tunnel from a business partner is considered an “external” domain too, hence firewall rules are still applied to policy where the partner is allowed to connect and where not.
This suggests yet another possibility - since both the IPsec peers use public addresses, the SA transport packets are bare ESP ones. If all you need to make pings from Mikrotik side to Sophos side succeed is to ping from the Sophos side to the Mikrotik one first, it means that the firewall at Sophos side only accepts ESP from addresses to which it has itself sent an ESP packet before.
As for your remote access to management of the Tik - am I right to assume you access the router via the Wireguard tunnel? Or do you connect directly to the yyy.yyy.yyy.174 address using Winbox?
If everything is ok with your firewall rules (as in my example), then look at what is happening with the NAT section.
When creating a tunnel with a ‘‘other’’ router, we create a standard masquerade for our subnet and if necessary, create an additional masquerade for the other subnet (for example, video or other).
Srcnat addresses must be above Masquarade, otherwise the rules policy will work incorrectly. Srcnat will be your IP subnets and Dstnat will be Sophos remote subnets.
Then add the Sophos subnet to the ‘‘Route list’’ and specify the output (Wan). You need to pay attention to the ‘‘DH Group’’. In my case, the connection is to the Fortigate FW, yours will probably be similar. The DH on both sides must match.
I have created many tunnels this way and have no problems. In my case, the Mikrotik version everywhere is 7.16.2 I don’t know what version you have.
Of course, there is always the possibility of running Wireguard
Sorry guys im in congo and power is not always present
1 - yes i access the router via wireguard
2- made the sophos initiate the connection and reduces all the encryption and authentication to AES256 and SHA256 and DH2048 only (i also removed all static routes from or to the mikrotik 192.168.1.0/24)
3 - I only used these firewall rules - but disabling the nat didnt affect the network
The description below only deals with Wireguard and SSH/Winbox, and is aimed to illustrate how the firewall works. So you need to adjust it to your actual environment and add whatever additional accept rules are necessary for other things (like the IPsec) to work before applying the last steps. The best would be to experiment with this on a router that is on your table before using it on the one half a globe away, but it is designed in such a way that it was reasonably safe even in the latter case.
If you manage the router using Wireguard, what you have to ensure is that
the Wireguard transport packets are accepted in ip firewall filter if they arrive to the public address and listen-port via the WAN interface (example: chain=input in-interface-list=WAN protocol=udp dst-port=13231 action=accept)
the wireguard transport packets the router itself sends are accepted in ip firewall filter (this is typically ahieved by doing nothing, as there are usually no rules in filter chain output that handles them, I just mention it to make the picture complete)
the management packets for the router itself that come in via the Wireguard tunnel from the proper sourec address are accepted (example: chain=input in-interface=wg-1 src-address=wireguard.address.of.your.laptop protocol=tcp dst-port=22,8291 action=accept - this will allow SSH and Winbox connections (if these services listen on their default ports)
the response packets the router sends are accepted (again, unless you have some reasons to add rules to filter/output, ths is done by default)
Once you add those rules, you can check that they actually work without losing access - if you look at them in Winbox/WebFig or you use /ip firewall filter print stats while connected using Winbox via Wireguard, you must see the byte and packet counters of those rules to grow. If they do, it is time to add another rule, chain=input connection-state=established,related action=accept to the very beginning (top) of the input chain in filter. This rule will handle both the Wireguard transport packets and the Winbox/SSH ones that belong to already existing connections, so the “wireguard” one will only count a single packet when you re-connect Wireguard from a new address or after more than 3 minutes and the “winbox/ssh” one will only count a single packet when you initiate a new connection (you can have multiple Winbox connections at the same time). The actual purpose of that “accept established or related” rule is to accept answers to requests the router itself has sent, like DNS queries or time updates.
Once that is done, you can add a chain=input action=passthrough comment=abc123 rule to the very end (bottom) of the input chain in filter. Next, add a scheduler item: /system/scheduler/add start-time=hh:mm:ss name=recover on-event={/ip firewall filter disable [find comment=abc123]}, setting hh:mm:ss to 5 minutes in future. After those 5 minutes, you should see the run counter of the scheduler to show 1 and the rule to be disabled. If this the case, you can change the start-time again to 10 minutes in future, change the action of the rule from passthrough to drop, and disconnect Winbox and then Wireguard for 5 minutes. After 5 minutes, connect Wireguard and Wireshark again, it should go without issues. If not, wait another 5 minutes and the scheduler will disable the drop rule so you can start looking what is wrong.
