Hi,

I need a little help. I have a Mikrotik CCR router with interface that has several public IP's. I also have DST-NAT rules (port forward) where i use public IP's and port forward (DST-NAT) external ports to internal server. I need to achieve that a return packet is sent with SRC IP = public IP that packet came in first place.
https://imgur.com/a/YAAyNTw

As you can see in the Wireshark example i have packet comming from 31.217.20.96 and it is sent to 194.152.192.156. Return packet is sent through default gateway and not with 194.152.192.156 as SRC IP.

Any advice?

You need to mark the connection / routing coming in on that interface in Mangle

Then create a route out using the routing mark, e.g.:

First, thank you for trying to help, but i don't think suggested solution will work for me. Let me try to describe the situation:
I have CCR router with several public IP's (one subnet). That several public IP's all have the same gateway.
When some client sends packet to my network, ho send's it to 194.152.192.156:16666. This is forwarded (DST-NAT) to 10.10.11.X:9002. I need this server to forward packet's back to router and back to client. The local server 10.10.11.x now uses default gateway and sends packet back to client with 194.152.192.154 as source IP and not 194.152.192.156 as the client expects.
Both Public IP's have the same gateway.

Is there a static port number the server replies on? If so, then try above your normal NAT / Masquerade rule:
or maybe a one to one NAT:

If the return packet is direct reply, as it seems to be, conntrack should take care of this automatically. There must be something unusual what is not apparent from provided description. Maybe a config export would help...

I agree with CZFan reply.

If you mark connection (connection tracking have to be enable: ip firewall connection tracking set enabled=yes), all packets in this connection will be marked.
With this connection mark you mark packet with routing mark.
With this routing mark, you say to mikrotik which wan connection use.

Packet from 10.10.11.x is not new, its is a reponse to dst-nat. So it is marked with connection mark and with routing mark. So it will be send using the right mikrotik interface.

First, thank you for trying to help, but i don't think suggested solution will work for me. Let me try to describe the situation:
I have CCR router with several public IP's (one subnet). That several public IP's all have the same gateway.
When some client sends packet to my network, ho send's it to 194.152.192.156:16666. This is forwarded (DST-NAT) to 10.10.11.X:9002. I need this server to forward packet's back to router and back to client. The local server 10.10.11.x now uses default gateway and sends packet back to client with 194.152.192.154 as source IP and not 194.152.192.156 as the client expects.
Both Public IP's have the same gateway.

If the return packet is direct reply, as it seems to be, conntrack should take care of this automatically. There must be something unusual what is not apparent from provided description. Maybe a config export would help...

That also went through my mind, but I am not that knowledgeable on Mikrotik yet and thought maybe Mikrotik does not work like that.

It's basic functionality. If packet is reply for connection established from outside (even though it's not true connection with udp, but conntrack see it as such), then it will get the right source address (same as outside client used as destination) automatically.

Connection and route marking is required for multiple WANs, and it's only for choosing the right path, addresses will be correct even without it (it's just that the right address sent the wrong way can't succeed). But from the description it doesn't sound as two WANs, only one with more addresses.

Hi,

I need a little help. I have a Mikrotik CCR router with interface that has several public IP's. I also have DST-NAT rules (port forward) where i use public IP's and port forward (DST-NAT) external ports to internal server. I need to achieve that a return packet is sent with SRC IP = public IP that packet came in first place.
https://imgur.com/a/YAAyNTw

As you can see in the Wireshark example i have packet comming from 31.217.20.96 and it is sent to 194.152.192.156. Return packet is sent through default gateway and not with 194.152.192.156 as SRC IP.

Any advice?

Like other participants, I agree that your requirement is the actual way, how DST NAT and connection tracking are supposed to work.
SRC-NAT should be necessary only for outgoing connection, that are initiated by internal server.
Could it be that you have masquerade somewhere without defining in\out interfaces (ip addresses)? That might cause interesting effects.

Could it be that you have masquerade somewhere without defining in\out interfaces (ip addresses)? That might cause interesting effects.

It should not, because the chains of the NAT table are only consulted for the initial packet of each connection (connection-state=new). So even if a masquerade rule made the server see the request as coming from the router's LAN IP instead of the client's IP, the server would respond to the router's address and connection tracking would "un-src-nat" the destination, same like it "un-dst-nat's" the source if dst-nat was applied on the connection.

But it's like in the joke about the fallen concrete bridge where cement says "don't blame me, I wasn't there at all" - packet 873118 goes from port 11034 to port 16666, but packet 873120 goes to port 11034 but from port 63268. So the connection tracking cannot recognize that the two packets belong to the same connection (if they actually do which is questionable), and thus anything that relies on connection tracking, i.e. both NAT and connection marking, doesn't work.

So @ivugrinec, the first thing is to find out whether the packets actually do belong to the same connection at application level, and if they do, whether there is a way to make the server respond from the port on which it listens. If they do belong to the same connection but you cannot make the server respond from the same port, you'll need to record the address of the client to an address list logically attached to the IP address to which the request comes, and use a src-nat rule to set the right IP address to the first packet of the server->client flow which will be treated as a separate connection. As none of the connections will be "confirmed" (because the connection tracking will see only packets in one direction), shorter timeouts will apply.

And if several client connections may come from the same address, it is even more funny because the address-list-timeout will have to be long enough so that the client address would still be available in the list when the first response packet comes, but short enough that if another connection from the same remote address comes to a different local address, it would already be out of the previous list. If this is the case, enjoy the tuning process .

I need new glasses... or brain. I mean, I saw the ports, but if for some reason the reply packet wasn't handled by conntrack as such, and used another srcnat rule, the source port is not guaranted to stay unchanged, so it didn't look completely impossible. But internal server using different source port and thus creating new "connection" is the most simple explanation.