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.
ip address x.x.x.68 255.255.255.240
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 10.10.10.0 255.255.255.0
static (inside,outside) x.x.x.69 STATIC_NAT_EXAMPLE netmask 255.255.255.255
access-group internal in interface inside
route outside 0.0.0.0 0.0.0.0 x.x.x.65 1
access-list internal permit ip 10.10.10.0 255.255.255.0 any
!Remote LAN is 192.168.10.0/24
access-list nonat extended permit ip 10.10.10.0 255.255.255.0 192.168.10.0 255.255.255.0
Solved! Go to Solution.
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.
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 22.214.171.124 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 126.96.36.199". "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.
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 188.8.131.52 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 > 184.108.40.206: icmp: echo request
2: 10:58:23.803043 802.1Q vlan#2 P0 x.x.x.69 > 220.127.116.11: icmp: echo request
3: 10:58:29.303084 802.1Q vlan#2 P0 x.x.x.69 > 18.104.22.168: icmp: echo request
4: 10:58:34.803287 802.1Q vlan#2 P0 x.x.x.69 > 22.214.171.124: icmp: echo request
It appears that there does not seem to be any return traffic?
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.