Ok, I've searched the forums (hence picking the best Subject title), read the topics, tried the rules, studied the rules, tried variations of them, read what links I can find on it... I think I now sort of understand the problem, however my issue might not be as simple as the others for which these have worked, therefore I'm starting this topic with my configuration in the hopes someone can assist me, and that future users with a similar setup will find it useful.

With that out of the way, firstly my setup summary:

2 LANs separated from each other, 192.168.1.0/24 and 192.168.2.0/24, they must be seperate.
2 WANs (currently, pretty soon 3, perhaps a 4th later), with one WAN using two ethernet ports with pppoe, and the other WAN is just ethernet with a DHCP client.
1 Empty Bridge Interface (The Mikrotik documentation says that this is the recommended way to assign IPv4 addresses to the RB that aren't specific to one interface, so decided this was the best solution as to where to define my public /27 range for my multi-connection WAN)

Now, everything is working as I'd hoped, except of course (like others) when attempting to access servers using the public IP from either of the two LANs for servers in either.
Lan1 Client - > Lan1 Server
Lan1 Client - > Lan2 Server
Lan2 Client - > Lan2 Server
Lan2 Client - > Lan1 Server

As I'm using multiple IPs, I'm therefore using SRC-NAT on the multiple IP WAN to ensure all outbound traffic comes from a specific IP (except for some services, such as SMTP that instead go out from one of the others in the range), for the other WAN it's a dynamic IP so I just use masquerade for that one.

I've used articles on the Wiki to setup typical filter rules, there's an allow for simply TCP and UDP, once I've got everything sorted, I'll begin to tighten this down and remove the all-tcp and all-udp rules.

In my NAT, I have dst-nat rules for my various servers and services, using the Dst. Address as the one I want from the /27 range. Further down, I then have my Src-NAT rules for setting the IP's that connections come from, firstly specific ones for services from some servers, eg SMTP servers, then a specific IP for the dual ISP connection, then just an ordinary masquerade for the DHCP ISP.

I know there's Split DNS etc. but in a multi-lan, multi-wan it's a headache, and as many have pointed out, this "just works" in commercial home routers.

I'm trying to work out a way to find what's happening (or not), I've tried Torch, Packet Sniffer, PS shows a connection from the local client to the Public IP, but then nothing else.

My log doesn't show it's being dropped, I'm a bit hesitant to post my rules up here... I was hoping there's a tool to track whats going on with a connection in the RB to work out what's going wrong.

Please post your rules. We can't really assist "theories" of what you think should work, and your actual rule set.

If you need to, substitute the IPs with YYY, ZZZ, etc.., and indicate which is which in your configuration.

ah huh, ok, think I found the added complication, was a "Default Route" Rule, basically anything no yet Connection or Packet marked, is then marked to go out my preferred heavy usage ISP by using a Packet/Routing Mark. It was sending this out there as well.

setting up a log rule for dst nat and src nat, just to see if that would help work it out... I saw it was going out my DHCP ISP connection eth....

Hmm...

I do have "default rules", these are (ISP1 is the dual port connection):

add action=mark-packet chain=prerouting comment=\
"Mark Packet: LAN -> ISP2 (Default Route)" connection-mark=no-mark \
disabled=no new-packet-mark=ISP2 \
packet-mark=no-mark passthrough=yes src-address-list=LANs

add action=mark-packet chain=prerouting comment=\
"Mark Packet: LAN -> ISP3 (Default Route)" connection-mark=no-mark \
disabled=yes new-packet-mark=ISP3 \
packet-mark=no-mark passthrough=yes src-address-list=LANs

add action=mark-packet chain=prerouting comment=\
"Mark Packet: LAN -> ISP1 (Default Route)" connection-mark=no-mark \
disabled=yes new-packet-mark=ISP \
packet-mark=no-mark passthrough=yes src-address-list=LANs

Now, ISP3 isn't connected yet, and obviously can only have ONE Default route, so the other disabled, but I switch it by switching which of these is enabled/disabled (or changing order). The important change I made (which also made to the others, but as they're disabled at the moment won't make a difference, but for future ref), is this below:

add action=mark-packet chain=prerouting comment=\
"Mark Packet: LAN -> ISP2 (Default Route)" connection-mark=no-mark \
disabled=no dst-address-list="!ISP1 Range" new-packet-mark=ISP2 \
packet-mark=no-mark passthrough=yes src-address-list=LANs

Might need to refine this a bit... perhaps a rule before hand to connection mark anything from LAN to ISP1 Range, as once it then has a connection mark, it won't be picked up by the Default Route.

Anyway, with that obscurity out of the way, I do see something happening when I apply some of the rules as others have.

Problem is.. it doesn't quite work out how I want... I found that:
LAN1 Server -> Lan1 Server by it's Public WORKED
LAN1 Server -> Lan2 Server by it's Public WORKED

Effecively fixing it for that specific server going to the range... which isn't quite the right fix.

So, a bit more experiementing...

Here's the rules:

add action=dst-nat chain=dstnat comment="NAT: TS Server (RDP)" disabled=no dst-address=x.x.x.222 dst-port=3389 protocol=tcp to-addresses=192.168.0.3

add action=dst-nat chain=dstnat comment="NAT: TS Server 2 (RDP)" disabled=no dst-address=x.x.x.212 dst-port=3389 protocol=tcp to-addresses=192.168.1.3

So you can see the two lans, now trying to access the servers by their own Public IP or each others (yes I know to RDP itself can use it's LAN IP, loopback, etc. etc. this is just for testing/example).

The x.x.x.x range is attached to a bridge, with the RB IP of x.x.x.201.

I believe this whole problem is that client makes a connection to the public IP but gets a response from the Server LAN IP, to fix it we need to get the response coming back from the Public IP the Client is expecting.

I guess there's no easy one rule solution... I get the feeling I need a SRC-Nat rule for each of these, like this:

add action=src-nat chain=srcnat comment="SNAT: TS Server (RDP)" disabled=no dst-address-list=LANs dst-port=3389 protocol=tcp src-address=192.168.0.3 to-addresses=x.x.x.222

LANs is an address list that contains 192.168.0.0/24 and 192.168.1.0/24

This appears to work, adding one of these per rule, above the existing rule.
What I don't quite understand is why this isn't a problem externally, but it is internally ??
Going to be a pain adding all these SRC-NAT rules...

I'm told Connection Tracking is the magic that enables this clever two way translation using just a DST-NAT rule.

Without it, you'd need SRC-NAT rules to allow external connections to get responses from your Local servers.

What I don't quite understand is why it's different externally, than if the source is from a local attached source. Obviously there is a difference, it's coded as such, but perhaps this can be changed?

Am I right, or is something else upsetting connection tracking from being able to correctly re-translate?

What I see happening is:

Lan1 Client (192.168.0.1) - > Lan1 Server Public IP (x.x.x.212 on Empty Bridge on RB) Then
Lan1 Server Local IP (192.168.0.10) - > Lan1 Client (192.168.0.1)

Which it isn't expecting and ignores it, though.. I'm not 100% sure that this is what hapenning, it could also be that the request hits the IP on the bridge and just goes into limbo, perhaps?

Ok.. I thought that rule fixed it, but it only applies seems to apply when communicating between the servers, if it's another client, it doesn't work...

back to the drawing board...

Ok, more days of fiddling and....

I have two masquerade rules, one for each lan, pretty basic just Masq for the ether out interface.

Then, I have a "Default Route" rule, to send any un-matched traffic (from the LANs, but NOT going to the IP Range) out through the best ISP/WAN for unknown/heavy connections.

With the masq rules in place, I noticed in logging that my connection was going through this default rule... sending it out to the internet when the request is from one lan to another (even by public IP, it should just loop and not actually go out to the internet). So, I added a condition for Dst. Address Type !local (local being traffic going TO the actual RB's IPs) and voila, it appears to be working.

I need to check from a 3rd client when I get home, but looks promising. I guess be careful with you "Routing"-ish rules, they can and will mess up your NAT rules.

After this, I also discovered I didn't need the SRC-NAT rules I had made, which is excellent.