Let me try to explain my situation. I have a load balancer server, which balances traffic over a set of pre-defined SMTP servers.
Host A (the client) connects to Balancer B which sends the request to Cluster-Node C. Since Balancer B uses IP masquarading, it looks to Cluster-Node C as if the request came directly from Host A, so it sends its replies to Host A.
Host A -> Balancer B: clients makes a request on port 25 to the load balancer
Balancer B -> Cluster-Node C: load balancer connects the client to the actual node
Cluster-Node C -> Host A: the node connects back, directly to the client
The answer of Cluster-Node C should actually go back to Balancer B, instead of Host A.
Here's the tricky part: all servers reside on the same subnet. If I change the Cluster-Nodes to a new subnet, I can give them the gateway of Balancer B, and it would work, as requests are sent over the gateway.
Host A: 10.0.0.10 Balancer B: 10.0.0.20 Cluster-Node C: 10.0.0.30
Is there a way to force all outgoing connections on Cluster-Node C (10.0.0.30) to be sent to Balancer B (10.0.0.20), no matter what the originating (in this case, masquarated) IP was?
For starters, your initial assessment is incorrect. Masquerading effectively replaces the IP address of the original sender with the IP address of the router. This results in a situation where the targeted host (in your case the cluster node) will respond back to that address. The router will de-masquerade the packet (i.e. replace its own IP address with the original one) and feed the packet back into its routing engine. This is also known as SNAT and is commonly used to provide computers on a LAN with access to the Internet.
Or, to put it right here: Cluster node C does NOT send the reply back to host A, it sends its replies to Balancer B (that is, if your SNAT or masquerading is configured properly).
In a subnet where all hosts are connected to the same subnet directly (which is the situation you are describing) there is no way to force all outgoing connections from one host to a particular other host. In essence this would violate the definition of a subnet (all hosts in the subnet can be reached without routing).
If your particular setup doesn't work then the most likely reason is that your routing isn't set up correctly. A lot of people forget that not only do they need to provide a route for the traffic in the forward direction, you also need to make sure that there is a valid route for the return traffic.
However, you should be able to figure all of this out quite easily using tcpdump.