Let’s say we have an OSPF network like the attached where all routers can route between each other, link subnets are private and not NATed, loopback addresses are public.
We can ping DNS and the internet from R4 when we specify the source addresses as one of the public loopbacks:
> ping bbc.com src-address=4.4.4.4
Is there an equivalent for:
/tool e-mail send
Many thanks for reading
There is the generic solution of putting a preferred source address in your routes, either static or via route filters.
Set the preferred source address to your loopback address in a route filter you use when receiving routes.
Of course this topology will still cause problems, because router-generated ICMP traffic will not be routeable.
Is a src-nat rule saying
/ip firewall nat
add chain=srcnat action=src-nat to-addresses=4.4.4.4 dst-address-list=my-mail-server protocol=tcp port=25
an acceptable solution?
Where the /ip firewall address-list would hold a static item list=my-mail-server address=mail.server.fqdn and would maintain a dynamic item with the IP number to which that fqdn currently resolves?
Thanks for the replies,
Sorry if my diagram isn’t too clear. I’ve added PPPoE clients who get a mix of public and private, NATed addresses. The default routes on the routers will change if a link goes down.
Also, if I srcnat will that then NAT my clients to the loopback address too?
@pe1chl, could you expand your solution please? I’ve not used route filters before 
The action=src-nat assigns the new src-address from the pool specified in to-addresses, it does not care about the address assigned to the outgoing interface or even whether the addresses are assigned to any interface on Mikrotik. This is different from action=masquerade which always uses the address assigned to the interface through which the connection to be src-nated is routed out.
It is up to you what additional conditions you add to the rule. BTW I knew forgot something, chain=output is missing in the rule. And chain=output only processes packets sent by the Mikrotik itself, so even clients sending e-mails via the very same smtp server are unaffected by that rule.
Just add a routing filter in the the ospf-in chain without any matching criteria and set the Action to “set pref src.” with the local loopback address on each router.
When you look in the IP routes you will see the pref. src in all routes received via OSPF.
(which should include your default route)
When it does not work right away, after adding the filter disable and enable it.
Still I would advise to set a forward rule in R1 for traffic routed to internet with a 10.0.0.0/8 source address, that drops and logs this traffic.
Watch the logs to see what it catches and try to solve those issues. I think there will be issues with ICMP messages, you could consider
to src-nat outgoing ICMP with a 10.0.0.0/8 src address to the main external address of R1.
Thnks for the replies. I’ll try and work these solutions out 