internal hosts cannot access internet w/ L2L tunnel configured

Answered Question
Nov 5th, 2009

Internal hosts behind the ASA cannot access the internet with a L2L tunnel configured. The L2L tunnel is up and passing traffic properly. However, the internal hosts cannot access the internet through the ASA. I think I've got my NAT hosed up somewhere. I can't even get a statically mapped host to the internet. It might be because I am used to having a WAN IP for the outside interface that is different from the CIDR block assigned by the ISP. In this case, it is all together, with the ASA's outside interface occupying the first available address.

We were assigned CIDR range x.x.x.64/28. x.x.x.65 is my gateway and my first usable is .68, per the ISP (I guess they use .66 and .67 for internal use.) The ASA's outside interface is .68 and I'm trying to have it NAT the others. I'm PATing all internal DHCP clients, and have some static entries as well. The relevant NAT config is below. Again, all traffic is passing over the tunnel correctly, just not from inside to outside. If more info is needed, please advise.

interface outside

ip address x.x.x.68


global (outside) 2 x.x.x.69-x.x.x.77

global (outside) 1 x.x.x.78

nat (inside) 0 access-list nonat

nat (inside) 1

static (inside,outside) x.x.x.69 STATIC_NAT_EXAMPLE netmask

access-group internal in interface inside

route outside x.x.x.65 1

access-list internal permit ip any

!Remote LAN is

access-list nonat extended permit ip

Correct Answer by acomiskey about 7 years 3 months ago

Can you post a "show run sysopt"?

Try this command to enable proxy arp.

no sysopt noproxyarp outside

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.7 (3 ratings)
Panos Kampanakis Fri, 11/06/2009 - 10:58

Can you check the ACL in your crypto map?

If you want to browse the internet (not encrypted) make sure that that traffic is not matched in the crypto ACL.

I hope it helps.


cooperben Mon, 11/09/2009 - 06:10


Here is the relevant crypto ACL. Please advise.

object-group network DM_INLINE_NETWORK_1


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

crypto map outside_map 1 match address cry_acl

crypto map outside_map interface outside

Panos Kampanakis Mon, 11/09/2009 - 07:15

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

If you try to ping 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". "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.


cooperben Mon, 11/09/2009 - 09:05


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 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 > icmp: echo request

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

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

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

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

cooperben Mon, 11/09/2009 - 09:12


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 outside any

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

translate_hits = 465, untranslate_hits = 0

acomiskey Mon, 11/09/2009 - 09:25

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

cooperben Mon, 11/09/2009 - 09:40

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.

acomiskey Mon, 11/09/2009 - 10:03

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

Correct Answer
acomiskey Mon, 11/09/2009 - 10:12

Can you post a "show run sysopt"?

Try this command to enable proxy arp.

no sysopt noproxyarp outside

cooperben Mon, 11/09/2009 - 11:34

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!


This Discussion