Hi -
To make this work, it is better if we clarify our terminology. For NAT we will use "REAL" and "MAPPED" to indicate the actual server IP and the NAT'ed IP respectively. In ASA version 8.3 and later access-lists will refer to the real IP because ACLs are applied after NAT.
As you have stated the remote site does not have a firewall, so it is expected that the source IP on the packet will be the actual IP of the "Machine" (10.6.5.10).
Now that we know the parameters of the traffic we can build the NAT and rule.
object network 10.3.1.8_REAL
host 10.3.1.8
object network 10.3.1.8_MAPPED
host 172.1.1.8
object network REMOTE-HOST
host 10.6.5.10
!
nat (inside,outside) source static 10.3.1.8_REAL 10.3.1.8_MAPPED destination static REMOTE-HOST REMOTE-HOST
!
access-list outside_in extended permit ip object REMOTE-HOST object 10.3.1.8_REAL
!
access-group outside_in in interface outside
In the NAT command, we can divide it into 2 sections: source and destination. Each section tells the firewall what to do with those specific fields in the IP packet. The source portion states how the internal server's IP will be translated. The destination portion states how the external IP will be translated.
In this case, the destination IP does not actually need translation; it will be the same on both sides of the firewall. To do this we simply tell the firewall to translate the IP to itself.
NOTE: I changed the Mapped IP of the server because the configuration gets more complex if we are going to use the ASA interface IP.
In terms of testing from the remote site, it will only see the NAT IP of the server, it will never be able to access the internal IP directly. Based on the sample configuration, pings to 172.1.1.8 should work. If you run wireshark on both ends, you will see the results of the NAT translation.
PSC
