Yes. I’m a bit surprised that there are no ICMP packets in the result, but since incoming TCP connection attempts through ether6 to its leased IP address can be seen there, I’ll hope that the ICMP just scrolled up before you could catch it. You can confirm that by adding ip-protocol=icmp to the /tool sniffer command and trying again, but let’s suppose it’s not necessary.
Rather the reverse, it is much better that they are in different subnets. So the situation is actually almost the standard one with two WANs - they are in distinct subnets which just “incidentally” share the same L2 segment which is nothing to really worry about.
Hence the whole issue is just that the routing doesn’t automatically route a response through the same interface through which its triggering request came, and you have to provide a firewall and routing configuration which ensures this. The complication is that it requires to place the default route provided by the DHCP server for ether6 into a dedicated routing table, which normally requires a script to be added to the /interface dhcp-client which is ran at every change (address lease/renewal/expiry). However, given that the address you get is static, we may suppose that the gateway will be static too, and hence we can do it in a simpler way.
So do the following to quickly check that there are no other issues than this one. Enter these commands the same way like you entered the /tool sniffer … one if you can copy-paste them into the text terminal window; if you cannot, better do it the same way like you’ve entered the firewall rules (open an edit window for a script, paste it there, then run the script; you can copy-paste both parts in the correct order to the same script):
/ip route {add routing-mark=via-ether6 dst-address=0.0.0.0/0 gateway=[get [find dst-address=0.0.0.0/0 distance=2] gateway]}
This will make a copy of the route created from the DHCP response in a routing table named via-ether6.
Then, add a routing rule causing packets whose source address is the one assigned to ether6 to use that other routing table, and an exception from it for LAN destinations:
/ip route rule
add action=lookup table=main dst-address=192.168.0.0/16
add action=lookup-only-in-table table=via-ether6 src-address=[/ip address get [find interface=ether6] address]
After these two steps, the pings from outside to each public address should start being responded even with both cables connected. If this is true, we can move further to the real thing.
