You are correct, because the auto NAT statement is higher up in the list, the return traffic from server will always hit it first and will use auto NAT. I think the best you can do is create a specific NAT entry for a port on the server and place it higher up. So, that if traffic is originating from a certain port, which typically will be only in response to client request, then use address .51. And the default will be caught by your auto NAT entry.
why use static? the auto nat rule will send the traffic to the correct source when it replies
The auto nat rule is not static but dynamic, and dynamic nat is unidirectional, so without an additional static nat rule, the server wouldn't be accessible from outside ...
I wouldn't do that with an "after-auto" manual nat rule. My solution would have been an "unidirectional" manual nat rule:
nat (outside,inside) source static any any destination static HOST_10.0.0.51 HOST_10.100.0.3 unidirectional
Manual static nat rules are bidirectional by default, but you can add the keyword "unidirectional", so that the rule will only be applied for connections initiated from outside to inside in this case. Seems to be also a solution ... But i would restrict the nat rule to a specific service, if only 1 service should be reachable from outside, for example:
object service HTTP
service tcp destination eq 80
nat (outside,inside) source static any any destination static HOST_10.0.0.51 HOST_10.100.0.3 service HTTP HTTP unidirectional
Even if i would have done it with an "after-auto" nat rule, i would have used an "unidirectional" nat rule, just because i usually restrict nat rules to the absolutely necessary ...
Btw: there may also be a solution without manual nat rules:
object network NETWORK_10.100.0.0_24
subnet 10.100.0.0 255.255.255.0
nat (any, OUTSIDE) dynamic interface
object service HTTP-SOURCE
service tcp source eq 80
object network HOST_10.100.0.3
nat (inside,outside) static interface service HTTP-SOURCE HTTP-SOURCE
I haven't tested this one, but i think, it should work. There are several "tricks" used here: first order of object nat rules:
1. static before dynamic (that is something, that is currently missing in my document about nat on ASA, i have to find time to rewrite some parts of it )
2. if the rules are the same type of nat rules: most specific objects first
3 if the rules are same type of nat rules, objects with lowest start address go first
4. if the nat rule have same type and objects have same content, use alphabetical order of object names
The first nat rule would be enough to let the second object nat rule have preference over the first object nat rule, but the second criteria would give the second object nat rule preference ... The second trick is to use not the desired service but the "answer traffic fromn that service". Since static nat rules are bidirectional by default, not only connections initiated from 10.100.0.3 to outside with source port 80 will be natted, but also connections from outside to the outside interface address of outside interface and destination port 80 ...
But as i wrote above: i haven't tested this variant (even if i'm sure, it will work as described here).
Now we have found 3 different solutions, one with an "after-auto" manual nat rulein addition to the original dynamic object nat rule, one with an unidirectional manual nat rule in the first section of nat rules and last but not least a solution with 2 different object nat rules. are there any other ideas as answer to the original requirement? I have no further ideas. Have anyone labbed those 3 solutions? Would be interesting, if all 3 really work as expected or if we made some mistakes in that 3 solutions ...