Two locations, internet access each via a Mikrotik:
A) Subnet 192.168.100.0/24
B) Subnet 172.21.79.0/24
Both locations have a functioning IPsec VPN, traffic between the subnets works without problems in both directions.
Now an Exchange server is to be put into operation at location B (IP 172.21.79.10), whereby this is to accept mails directly (i.e. without a POP3 connector).
Now the special feature: The MX is not to go to the WAN IP of B, but of A, i.e. incoming mails are to be routed from A via the VPN to the Exchange at location B. The IPsec is currently without L2.
Currently the IPsec is configured without L2TP. As Src. Address is the respective LAN (for Router A LAN A), as Dst. Address is the subnet of the opposite side (for Router A LAN B).
How would you implement the requirement?
Is it absolutely necessary to use L2TP (or possibly another protocol) or can you reach the goal with additional IPsec policies? How should port forwarding and routing be implemented?
You definitely need a dst-nat rule to translate the public IP of Router A to the private address of the SMTP server.
Depending on whether you need that the SMTP server knows the actual addresses of the SMTP clients (which is often required for security related analysis) or not, you either have to add another policy (or a tunnel), or it is enough to use a src-nat rule to translate the source address of the traffic to a private one matching the existing policy.
The policy to add would be (at router A, at router B it would be a mirror one of course) src-address=0.0.0.0/0 dst-address=172.21.79.10/32 protocol=tcp dst-port=25; if you need that some some SMTP clients at Router B side could access the SMTP server locally, you need to put action=none policies before (above) the latter to shadow it, such as src-address=172.21.79.10/32 dst-address=172.16.0.0/12 protocol=tcp src-port=25 action=none.
Yet another catch, there is a safety measure in RouterOS, responders seem not to accept policies with dst-address=0.0.0.0/0 requested by initiators no matter what the src-address is; the workaround is two policies, with 0.0.0.0/1 and 128.0.0.0/1 as dst-address.
I have already provided it in my previous post, which part is not clear there?
Yes, this dst-nat rule is exactly the one you need.
As for src-nat rules, you need a rule chain=srcnat dst-address=172.21.79.10 protocol=tcp dst-port=25 action=src-nat to-addresses=192.168.100.1
and you need to place it before (above) the action=masquerade one.
Maybe it is actually not port 25, as it is used for plaintext SMTP; nowadays, direct SMTPS or SMTP with mandatory STARTTLS are more popular, with appropriate ports 456 and 587, respectively.
Thanks for your helpful advice. I managed to get it running using the src-nat rule!
Nevertheless I would favour the IPsec policy way, because of - as you wrote - the security related analysis aspect. Unfortunately I did not get this running.
Action is always: encrypt / require / esp / proposal as stated above.
You wrote that there is a need to add two additional policies for 0.0.0.0/1 and 128.0.0.0/1 as dst-address. I tried it in different ways but it did not work.
Would you be so kind to provide me with a suitable CLI command and info on where to place it?
Is there anything else I should take care about?
A consecutive requirement now is how to direct outgoing SMTP traffic (connections initiated by Exchange server to dst port 25 i.e. mails by internal users the Exchange server has to deliver to recipient servers) via Router A. Currently default gateway on Exchange server is Router A. Is it possible to accomplish routing via router B only by using Mikrotik settings, i.e. not changing the default gateway within Exchange virtual machine? How would you implement this? Connection / routing marks won’t work as we don’t have IPsec interfaces. dst-nat on router B of port 25 to IP of router A won’t work as router A is not able to see the SMTP dst server address. Again using IPsec policies? Could you provide me with an example?
Try changing the level of all policies to unique. It should work with require but I’ve had cases where it didn’t.
Also, if there is an active action=fasttrack-connection rule in your firewall? Depending on the overall configuration, it may interfere with operation of these additional policies. So if there is, post the complete anonymized export (see my automatic signature below).
Maybe I’ve used wrong wording - the idea was that instead of each policy with a 0.0.0.0/0 <=> x.x.x.x/y traffic selector, you would use two, with traffic selectors 0.0.0.0/1 <=> x.x.x.x/y and 128.0.0.0/1 <=> x.x.x.x/y. But it is normally only necessary if 0.0.0.0/0 is the dst-address in the policies at responder side, which seems not to be your case.
I am afraid you got lost in what Router A and Router B are, so let me suppose that the default gateway of the Exchange server is Router B (172.21.79.x), and you want that the SMTP sessions initiated by the Exchange would be sent to the internet destinations from the public IP of router A.
Yes, again using IPsec policies, and they would look the same except you’d swap the roles of dst-port and src-port.
The current policies say “handle whatever comes from any port of any address in the internet to port 25 (465, 587) of the Exchange” (and the mirror of this), and you’d add ones saying “handle whatever comes from port 25 (465, 587) of any address in the internet to any port of the Exchange” (and the mirror of this). The former ones handle TCP connections where the Exchange acts as a TCP server listening at port 25, the latter ones handle TCP connections where the Exchange acts as a TCP client connecting to servers in the internet listening at port 25.
But you can also switch over from bare IPsec with policies to an IPsec-protected IPIP tunnel, but you’d still need to add a routing table and mangle rules at Router B to make sure that the outgoing SMTP traffic (or maybe just all traffic to other than private destinations) of the Exchange would use the tunnel to Router A rather than the local WAN of router B.