Cisco ASA Object NAT Issue

addresses etc were scrubbed.

Can you post a "show log" including the lines for that IP?

Yes in about an hour

You'll need to turn logging on the inside so that we can verify the return traffic.

Result of the command: "show log"

Syslog logging: enabled
    Facility: 20
    Timestamp logging: enabled
    Standby logging: disabled
    Debug-trace logging: disabled
    Console logging: disabled
    Monitor logging: disabled
    Buffer logging: level warnings, 2987 messages logged
    Trap logging: level warnings, facility 20, 2987 messages logged
    Permit-hostdown logging: disabled
    History logging: level warnings, 2987 messages logged
    Device ID: disabled
    Mail logging: disabled
    ASDM logging: level warnings, 2987 messages logged
88%
May 11 2013 04:58:58: %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x670E2228, sequence number= 0xCAF) from 66.249.252.2 (user= 66.249.252.2) to 184.18.219.3.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 172.21.1.155, its source as 192.168.1.190, and its protocol as icmp.  The SA specifies its local proxy as 172.21.1.0/255.255.255.0/ip/0 and its remote_proxy as 172.16.0.0/255.240.0.0/ip/0.
May 11 2013 04:59:14: %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x670E2228, sequence number= 0xCDE) from 66.249.252.2 (user= 66.249.252.2) to 184.18.219.3.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 172.21.1.155, its source as 192.168.1.190, and its protocol as icmp.  The SA specifies its local proxy as 172.21.1.0/255.255.255.0/ip/0 and its remote_proxy as 172.16.0.0/255.240.0.0/ip/0.
May 11 2013 04:59:29: %ASA-4-752010: IKEv2 Doesn't have a proposal specified
May 11 2013 04:59:29: %ASA-4-752010: IKEv2 Doesn't have a proposal specified
May 11 2013 04:59:29: %ASA-4-752010: IKEv2 Doesn't have a proposal specified
May 11 2013 04:59:29: %ASA-4-752010: IKEv2 Doesn't have a proposal specified
May 11 2013 04:59:46: %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x670E2228, sequence number= 0xD1E) from 66.249.252.2 (user= 66.249.252.2) to 184.18.219.3.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 172.21.1.155, its source as 192.168.1.190, and its protocol as icmp.  The SA specifies its local proxy as 172.21.1.0/255.255.255.0/ip/0 and its remote_proxy as 172.16.0.0/255.240.0.0/ip/0.
May 11 2013 05:00:24: %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x670E2228, sequence number= 0xD68) from 66.249.252.2 (user= 66.249.252.2) to 184.18.219.3.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 172.21.1.155, its source as 192.168.1.190, and its protocol as icmp.  The SA specifies its local proxy as 172.21.1.0/255.255.255.0/ip/0 and its remote_proxy as 172.16.0.0/255.240.0.0/ip/0.
May 11 2013 05:00:26: %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x670E2228, sequence number= 0xD6D) from 66.249.252.2 (user= 66.249.252.2) to 184.18.219.3.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 172.21.1.155, its source as 192.168.1.190, and its protocol as icmp.  The SA specifies its local proxy as 172.21.1.0/255.255.255.0/ip/0 and its remote_proxy as 172.16.0.0/255.240.0.0/ip/0.
May 11 2013 05:00:28: %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x670E2228, sequence number= 0xD74) from 66.249.252.2 (user= 66.249.252.2) to 184.18.219.3.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 172.21.1.155, its source as 192.168.1.190, and its protocol as icmp.  The SA specifies its local proxy as 172.21.1.0/255.255.255.0/ip/0 and its remote_proxy as 172.16.0.0/255.240.0.0/ip/0.
May 11 2013 05:00:31: %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x670E2228, sequence number= 0xD78) from 66.249.252.2 (user= 66.249.252.2) to 184.18.219.3.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 172.21.1.155, its source as 192.168.1.190, and its protocol as icmp.  The SA specifies its local proxy as 172.21.1.0/255.255.255.0/ip/0 and its remote_proxy as 172.16.0.0/255.240.0.0/ip/0.
May 11 2013 05:00:35: %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x670E2228, sequence number= 0xD7D) from 66.249.252.2 (user= 66.249.252.2) to 184.18.219.3.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 172.21.1.155, its source as 192.168.1.190, and its protocol as icmp.  The SA specifies its local proxy as 172.21.1.0/255.255.255.0/ip/0 and its remote_proxy as 172.16.0.0/255.240.0.0/ip/0.

I did try and hit it a few times while running this command.

it works if i use the VPN address so I know that routing, default gateway on the server etc are working and it is the correct port.

I can't find the IP 172.16.1.100 in the log data.

So, run packet-tracer:

 packet-tracer input inside tcp 8.8.8.8 4000 172.21.1.100 8000

What are the results?

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   172.21.1.0      255.255.255.0   inside

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Also did one to the outside address (nat'd)

packet-tracer input inside tcp 8.8.8.8 4000 184.18.219.2 8000

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   184.18.219.0    255.255.255.0   outside

Phase: 3
Type: ACCESS-LIST
Subtype: aaa-user
Result: DROP
Config:
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

From looking at your trace results, it seems to be a problem with your acl.  What version of IOS are you running?  in the older ones (prior to 8.3 if I remember right) you had to use the NAT'd address in the acl, whereas the newer ones used the real address the way you are.  If you're running an older acl, that could be your problem.

Disregard.  I just saw you're running ver. 9.0.  But it still looks like an issue with the acl because that's where it's being dropped in your trace. Is it possible that you need to create outbound acls for both of your interfaces as well?

Ill try, but outbound is any any on outside

I'm not sure if the implicit outbound any any doesn't go away once you apply an inbound acl to that interface.  Couldn't hurt to put an explicit one on there.

There is nothing blocking the traffic in the outbound direction (out the outside interface), that was only needed when running earlier versions of the PIX firewall.

You say that you can reach the server over the VPN tunnel, does this mean that you are trying to open for traffic that is not passing through the tunnel?  If so, have you configured Easy VPN to allow for split tunneling (this is done on the Easy VPN server).

If you run the packet tracer in ASDM and on the step that fails you will be able to click on a link that says something like "Show rule in rules table", this will take you to the rule that is blocking your traffic.  I am going to guess that it will be the Global ACL rule.

Also, your inside interface any any ACL is disabled.  Though this rule is not needed as traffic will flow freely from a high security level interface to a lower security level interface.  Since inside interface has a security level of 100 and outside has 0 this traffic should flow nicely without the ACL.  However if you decide to keep it then I would recommend enabling it, otherwise remove it all together.

Here is a diagram.

I will play with packet tracer, I'm not sure I understand the last comment.

Here is a diagram, I can access the camera server over the VPN tunnel but when I try and get to it via my ISP (from iPhone) It just times out.

I'd like you to yank the inside access-group statement for the inside_in access list and give it another shot.

Just for the purpose of testing, add a permit IP any any to the outside_access_in ACL and see if traffic starts to flow.

I added an any any to all interfaces and nothing worked. I also ran the packet tracer and it says it was successful. But it doesn't work still.

Could you post the command you ran for the packet tracer as well as the output of the trace.

If you ran the correct parameters on packet tracer and it says the traffic is permitted through the firewall, then there is nothing blocking the traffic and the problem lies elsewhere, maybe on the server.

You have:

object network obj-cam_server
 nat (inside,outside) static 0.0.0.1

Why does it show 0.0.0.1?

What is the output of "sh xlate"

thread just died.