I am about to replace an old Cisco SOHO Router with a MT RB1100 and want to make sure that I get it right.

I have a /30 to the provider with a /28 routed over the /30. The Public IP's in the /28 are assigned (mapped) when needed to various private IP's in some /24 and /22 private subnets. All other IP's in the private /24 are natted to the Public /30.

The Cisco didn't care which Public IP's went to which subnets or addresses as they were done with one rule for each mapping as below.
Even though the above appears to be only source address translation, clients on the internet were able to access a server on the private IP.

What I think I need for the MikroTik is below. I think that the mapped srcnat rules need to appear before the masquerade rule and the dstnat rules must be after masquerade for everything to work properly. The only benefit that I can see for netmap is that it offers a contiguous range of IP address mapping but you still need both srcnat and dstnat netmap rules. With individual and scattered target private IP's I cannot see any point in using netmap, unless I am missing something.
If the client on 207.x.y.3 is running a server behind the client's natted router (with port forwarding), I am wondering about the use of hairpin nat. It may be needed behind the client router where I have no control, but what if another client (client B) tries to access the server from client A? Client B can either have a public IP assigned (mapped) or wind up natted on the /30. Am I going to need some form of hairpin nat for the internal private IP's?

I would welcome any comments if you know about something I should watch out for, if you think I have it wrong or missed something, or even if you think I have it right.

Does this rule eliminate the need for hairpin nat?

Hairpin NAT only matters on the same subnet. Customer A and customer B are on different subnets, so there is no need for hairpin NAT.

Incidentally, your Cisco router wouldn't have translated traffic between customer A and customer B, either. You're not using virtual NAT interfaces, so you had a "ip nat inside" statement on the customer facing interface, and "ip nat outside" on the ISP facing interface. Only packets that cross those boundaries would have had NAT applied to them, and traffic between customers wouldn't have crossed the boundary. Since you didn't have it before you very likely don't need hairpin NAT now.

What you have looks good. Just one minor point: it doesn't matter where the destination NAT rules are in relation to the source NAT rules. The two are unrelated. NATing happens in chains - a packet comes into the router, and destination NAT is consulted (nearly) immediately, rule by rule as it appears in the dstnat chain. This also dynamically undoes all source NAT in the other direction. Then the packet is routed through the router, and source NAT rules are applied one by one as they appear in the srcnat chain. This also undoes all source NAT in the other direction.

As an example for things being undone in the other direction:

Customer A sends a packet sourced from 192.168.10.7 to 8.8.8.8 on the Internet. The packet enters the router. None of the destination NAT rules match (dst-address is 8.8.8.8), so nothing is done. The packet is routed through the router. It leaves the router through any interface, and the source NAT rules are checked. The one for src-address=192.168.10.7 matches, so the source address of the packet is rewritten to 207.x.y.2. The packet is put on the wire and makes its way through the Internet to 8.8.8.8, which replies, and sends a packet back. The reply packet enters the router. The router recognizes it as part of a connection it applied source NAT to, so dynamically (without a rule matching) the opposite of the previous source NAT action is applied, and the destination address of 207.x.y.2 is rewritten to 192.168.10.7. The packet is routed through the router and before leaving it source NAT rules are evaluated. None matches so no source NAT action is applied.

Hope that helps.

This wiki manual article is probably the single most important one of them all: http://wiki.mikrotik.com/wiki/Manual:Packet_Flow

It explains all the little details of how a packet is processed through the router.

Thanks for your comments fewi

I did the swap and the nat rules seem to be ok, but I did run into some other problems. I forgot about the relay setting in the dhcp server and had a couple of AP's down for a while. I wound up putting in three dhcp servers, two with relay settings, all drawing from the same IP pool and it works. I have more changes to make to clean that up.

The Cisco wasn't set up to log much weird stuff on the network, but it was easy for the MikroTik to log. Perhaps it was the swap that is causing some of the weirdness. I am getting all kinds of private subnet addresses that don't belong on the network. I was only able to trace and contact one customer so far, and all that was required was a reboot of their home router to clear the problem.

I now know that I have a rogue dhcp server on one tower but it will take a bit more effort to trace because the MikroTik can only see the MAC address of the AP in bridge mode, and not beyond.