PK,

Here is the relevant crypto ACL. Please advise.

object-group network DM_INLINE_NETWORK_1

network-object 192.168.10.0 255.255.255.0

access-list cry_acl extended permit ip 10.10.10.0 255.255.255.0 object-group DM_INLINE_NETWORK_1 log errors

crypto map outside_map 1 match address cry_acl

crypto map outside_map interface outside

So traffic should not match the crypto ACL, that looks ok.

If you try to ping 4.2.2.2 you should see an xlate being built (sh xlate" for the static that you have. Do you see that?

If yes, try to do a capture on the ASA outside "cap capout int outside match ip host xxx.69 host 4.2.2.2". "sh cap capout" will show you the pings going out and if there are responses.

Check if the issue is that we don't see return traffic.

PK

PK,

I do see 'global x.x.x.69 Local STATIC_NAT_EXAMPLE' when I issue the 'sh xlate' command.

Then, after setting up the capture per your instructions, I ping 4.2.2.2 from the statically NAT'd host, and see the following in sh cap capout:

1: 10:58:18.764166 802.1Q vlan#2 P0 x.x.x.69 > 4.2.2.2: icmp: echo request

2: 10:58:23.803043 802.1Q vlan#2 P0 x.x.x.69 > 4.2.2.2: icmp: echo request

3: 10:58:29.303084 802.1Q vlan#2 P0 x.x.x.69 > 4.2.2.2: icmp: echo request

4: 10:58:34.803287 802.1Q vlan#2 P0 x.x.x.69 > 4.2.2.2: icmp: echo request

It appears that there does not seem to be any return traffic?

PK,

FYI -- Regarding NAT, this is the relevant 'sh nat' output, showing successful translations for internal hosts to outside, as well as our static host to outside:

match ip inside host STATIC_NAT_EXAMPLE outside any

static translation to x.x.x.69

translate_hits = 79, untranslate_hits = 0

match ip inside 10.10.10.0 255.255.255.0 outside any

dynamic translation to pool 1 (x.x.x.78)

translate_hits = 465, untranslate_hits = 0

Doesn't look like x.x.x.69 is getting routed back to the ASA.

I would try this instead to confirm.

global (outside) 1 interface

After issuing that command, all non-staticially translated hosts can connect. However, the static hosts still cannot.

Is this a routing issue for me to take up with my ISP? Their gateway at .65 could be trying to reach these addresses directly as opposed to forwarding them all to the outside interface of the ASA.

Sorry I missed the part of your post where you have no transport network between the ASA and the ISP.

The sysopt noproxyarp was enabled on the outside interface. After issuing the command 'no sysopt noproxyarp outside' connectivity was restored for all hosts behind the ASA.

This makes sense, as the ASA has to proxy all ARP requests sent to it by the gateway for the hosts behind it that are translated. I guess I never thought to check this, and had disabled it by default for security during initial setup.

Thanks Acomiskey and PK for your contributions!