04-06-2010 01:42 PM
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
Solved! Go to Solution.
04-07-2010 03:35 PM
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.
04-06-2010 01:46 PM
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.
04-06-2010 02:03 PM
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
04-06-2010 02:13 PM
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.
04-06-2010 02:49 PM
04-06-2010 03:11 PM
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.
04-06-2010 03:36 PM
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
04-06-2010 03:56 PM
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.
04-06-2010 04:36 PM
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.
04-07-2010 08:16 AM
I changed that line as suggested - users still have no Internet.
04-07-2010 08:22 AM
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.
04-07-2010 08:43 AM
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#
04-07-2010 08:54 AM
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.
04-07-2010 09:04 AM
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
04-07-2010 09:14 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide