cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9328
Views
75
Helpful
51
Replies

ASA 5520 - VPN users have no internet.

rcoote5902_2
Level 2
Level 2

Hello,

We just migrated from a Pix 515 and VPN Concentrator to an ASA 5520.  The firewall portion is working well but we are having some issue with our remote VPN.

Everything on the inside network is accessible when using remote VPN however there is no access to our DMZ or internet.  I'm sure there is something simple needed that I'm missing, and hoping someone might be able to shed some light on what is needed to allow the VPN tunnel to go back outside and into our DMZ.

The ASA is running 8.2(2)9 and ASDM 6.2(1).

Cheers,

Rob

1 Accepted Solution

Accepted Solutions

From the 172.16.68.0/24 you can PING 10.10.10.1 correct?

From the 10.10.10.0/24 you can PING 172.16.68.1 correct?

I am having a hard time now figuring out how this tunnel is up since you have PFS
enabled on the ASA but not on the PIX.

Federico.

View solution in original post

51 Replies 51

Hi,

Most likey the nat0 statements to bypass NAT for the DMZ interface, or DMZ not included in the interesting traffic.

For the internet part of the remote VPN clients, are you using Split tunneling, or should the ASA provide the Internet?

Federico.

Hi,

I'd prefer not to use split-tunneling, so I'd like the ASA to provide outside access.  I should mention also that we have a site-to-site connection that cannot access any dmz servers either.  It may be related.   Since they're using internal DNS we've had to add a hosts file for that remote sites clients to get to our main webpage with the public IP as a workaround.

Thanks,

Rob

The ASA can provide the Internet access for the remote clients with the same security permit intra-interface command as well as enabling NAT

for the VPN traffic when going to the Internet.

To be able to access the DMZ, you should have an ACL bypassing NAT for the DMZ interface and the DMZ network included in the interesting traffic (for the site-to-site).

If you can post your configuration, perhaps we can help you with the commands.

Federico.

I'd read about that command but not too sure how to configure it.  Here is my config, edited a bit but let me know if I've pulled too much out.

Thanks,

Rob

nat (dmz) 0 access-list inside_nat0_outbound
To bypass NAT for traffic between DMZ and remote VPN clients.

The ACL outside_1_cryptomap that is applied to the Site-to-Site VPN, should include
the traffic from the DMZ network to the other's side network.

same security permit intra-interface
nat (outside) 1 10.44.99.0 255.255.255.0 outside

The above commands to NAT the outside traffic from the clients to the Internet and allow
the traffic.


I believe that when doing nat (outside) you should specify all other traffic as well to match.

Federico.

Here is what I added:

nat (dmz) 0 access-list inside_nat0_outbound
access-list outside_1_cryptomap extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0
same-security-traffic permit intra-interface
nat (outside) 1 10.44.99.0 255.255.255.0 outside

Remote VPN can now access the DMZ but still no internet.

The remote site still cannot access the dmz.

Progress at least!

Thanks,

Rob

Ok,

Please check this link for providing Internet access to the remote clients on the ASA:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00805734ae.shtml

Federico.

Change this line: nat (outside) 1 10.44.99.0 255.255.255.0 outside

To: nat (outside) 1 10.44.99.0 255.255.255.0

That should allow internet access.

I changed that line as suggested - users still have no Internet.

Can you please post the current output from the following commands:

sh run same-security-traffic

sh run nat

sh run global

sh route

Federico.


FrecASA# sh run same-security-traffic
same-security-traffic permit intra-interface

FrecASA# sh run nat
nat (outside) 1 10.44.99.0 255.255.255.0
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 0 access-list inside_nat0_outbound


FrecASA# sh run global
global (outside) 1 199.216.81.20


FrecASA# sh route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 199.216.81.1 to network 0.0.0.0

S    172.16.255.80 255.255.255.240 [1/0] via 192.168.0.1, inside
S    172.16.164.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.160.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.132.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.128.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.56.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.52.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.48.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.44.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.40.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.32.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.252.240 255.255.255.240 [1/0] via 192.168.0.1, inside
S    172.16.254.240 255.255.255.240 [1/0] via 192.168.0.1, inside
S    172.16.8.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.4.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.112.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.108.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.255.144 255.255.255.240 [1/0] via 192.168.0.1, inside
S    172.16.104.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.100.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.96.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.255.176 255.255.255.240 [1/0] via 192.168.0.1, inside
S    172.16.72.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    172.16.64.0 255.255.252.0 [1/0] via 192.168.0.1, inside
C    10.10.10.0 255.255.255.0 is directly connected, dmz
S    10.3.16.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.3.32.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.16.48.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.16.52.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.16.40.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.16.44.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.3.48.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.16.32.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.3.64.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.16.72.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.3.80.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.16.64.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.3.96.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.16.112.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.16.104.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.16.108.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.3.112.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.16.96.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.16.100.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.3.128.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.3.144.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.16.128.0 255.255.252.0 [1/0] via 192.168.0.1, inside
S    10.3.160.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.3.176.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.3.192.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.3.208.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.4.208.0 255.255.240.0 [1/0] via 192.168.0.1, inside
S    10.3.224.0 255.255.240.0 [1/0] via 192.168.0.1, inside
C    192.168.0.0 255.255.255.0 is directly connected, inside
C    199.216.81.0 255.255.255.0 is directly connected, outside
S*   0.0.0.0 0.0.0.0 [1/0] via 199.216.81.1, outside

FrecASA#

Ok, configuration seems fine.

The VPN client when it connects it will receive an IP from 10.44.99.0/24

So, do the following:

When a VPN client is connected, make sure that on the client, on statistics, on route details, it says 0.0.0.0 (meaning its sending all traffic through the tunnel).

You should have under the group-policy for the tunnel-group defined split-tunneling tunnel all (as explained in the link I sent you).

Then, let's say the VPN client got its IP 10.44.99.x

On the ASA, look at ''sh xlate local 10.44.99.x'' to make sure if there's a translation to the outside IP of the ASA when trying to reach Internet.

Federico.

As Frederico indicated, along with the other changes you need this statement which seems to be missing from the configuration under your tunnel policy.

split-tunnel-policy tunnelall

Confirmed, the vpn client received the IP 10.4.99.1.

On statistics, route details - secured routes shows 0.0.0.0.

Group policy on the ASA has "Tunnel all networks".

Sh xlate local 10.4.99.1 returns: 1643 in use, 4162 most used.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: