Odd one here. I have IPSEC tunnel up between two Mikrotik 951’s that have latest RouterOS (upgraded with stable version today) I can ping from LAN interface of one side to LAN interface of the other and vice-versa. I cannot ping beyond the Mikrotik LAN interface of either side when going thru tunnel. I have my nat statements above the Masquerade I have a Windows server on each side that needs to communicate with each other and I have confirmed the FW is disabled on both. Other devices within the same subnet get a response. Scratching my head What to look for?
Firewall rules, nat rules, maybe ipsec policies… Hard to say. Logging rules in mangle postrouting will help you find out at which end the packets get dropped.
My fast shot is that in the forward chain of filter, you drop everything that comes in via WAN without an exception for what came in via WAN but encrypted in IPsec transport packets.
When posting, please do post complete configurations. It took me some time to find out that ether1 and ether5 are WAN interfaces at Mission and Sutter, respectively, especially as you’ve named the firewall chains hooked to them “customer”.
But my blind shot was correct. First a bit of theory - when using policy-based IPsec routing, no virtual interfaces are created, so the payload packets decrypted and decapsulated from the received IPsec transport ones are still seen by the IP firewall as coming in via the same interface through which the transport ones carrying them have arrived. So at Mission, the transport packet comes in via ether1 and gets to firewall chain input which lets it in. The IPsec stack decrypts and decapsulates the payload packet from it and sends it to the firewall again; as the destination address of this payload packet is none of the router’s own addresses, the payload one gets handled by firewall chain forward. And there, you send anything that came in via ether1 to chain customer, which prevents any new connections to be established because it drops any packets which do not belong to already established (or related) ones. Hence the packets attempting to initiate new connections (like ping requests) get dropped there.
So if you don’t plan to fine-control the traffic between the Mission LAN subnet and the Sutter LAN subnet using any firewall rules, it is enough to add a match condition ipsec-policy=in,none to the action=drop chain=customer rules at both machines to make it work.
OK, You are correct. It would just make sense to post all since I have already given most of the security related info anyways. I will keep that in mind. I appreciate the theory tremendously. It helps fill in some gray areas in my understanding! I went ahead and added ipsec-policy=in,none to the action=drop chain=customer on both sides but I still cannot ping across from server to server in one direction. I receive responses from Sutter MT (sourcing from .1) to Mission MT Lan (.1) and Server .254 but still no responses from Sutter server to Mission server. I do receive responses from Mission Server .254 to Sutter server .254
Run /tool sniffer quick ip-protocol=icmp at both Mikrotiks while pinging in the failing direction. You should see whether the ping request makes it to the LAN interface at the responding side through the tunnel, whether the server really responds, and whether the response makes it to the requesting side. I cannot see anything else wrong in the configuration.
Found it. Bonehead move on my part. The screen is so small that I only disabled the Domain and Private FW, not the public on the Mission Win10 machine. Thank You for your attention to detail! [SOLVED]
Forgive me. Was away on a project and I finally am “Out of Jail” So sorry to not communicate for so long and abandon our communication. I am trying to send you a PM but I am not sure why I cannot. Can you contact via Slack again? I would like to offer you something to ponder.