ASA 5520 - VPN users have no internet.

[rcoote5902_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

[Federico Coto Fajardo]

Seems there's no XLATE created for the VPN client.

Are you trying to open a browser to get out to the Internet from the client?

What's the client DNS server?

Can you also PING 4.2.2.2 from the client to see if its succesful? (To discard a DNS problem).

Federico.

[rcoote5902_2]

Clients are using internal DNS, nslookup works but pings do not:

nslookup 4.2.2.2 - vnsc-bak.sys.gtei.net

ping 4.2.2.2

Request timed out.

Request timed out.

Request timed out.

Request timed out.

[rcoote5902_2]

Alright, I'm embarrassed now.

I fat-fingered the nat entry: nat (outside) 1 10.44.99.0 255.255.255.0

It should have been 10.4 not 10.44

Added:

no nat (outside) 1 10.44.99.0 255.255.255.0
nat (outside) 1 10.4.99.0 255.255.255.0

And it works.

Lots of points all around and thanks for all the help, and patience.

Now all that remains is my site-to-site connection that cannot access the DMZ.  Any thoughts there?

[Federico Coto Fajardo]

199.216.81.1

The above IP is the default gateway for the ASA.

Can the VPN clients PING that IP?

This will let us know if the VPN clients terminate the tunnel on the ASA, their traffic is decrypted and then sent back out the outside interface to the next-hop.

Is this gateway under your control?

Does it has a route back to the ASA pointing to the pool of VPN addresses?

Federico.

[Federico Coto Fajardo]

Do the following:

access-list dmz_nat0_outbound extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0

nat (dmz) 0 access-list dmz_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

Assuming 172.16.68.0/22 is the remote's Site-to-Site LAN.

If you have already a nat (dmz) 0 access-list statement, just adjust it to include the above line.

Federico.

[rcoote5902_2]

I already have:

nat (dmz) 0 access-list inside_nat0_outbound

access-list inside_nat0_outbound extended permit ip 172.16.128.0 255.255.252.0 172.16.68.0 255.255.252.0
access-list inside_nat0_outbound extended permit ip any 10.4.99.0 255.255.255.0

access-list outside_1_cryptomap extended permit ip 172.16.128.0 255.255.252.0 172.16.68.0 255.255.252.0
access-list outside_1_cryptomap extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0

I added:

access-list inside_nat0_outbound extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0

The remote site cannot browse or ping the dmz server (10.10.10.11).

[Federico Coto Fajardo]

My questions will be...

The dmz network 10.10.10.0/24 has its default gateway as the ASA?

If not, there should be a route to 172.16.128.0/22 pointing to the ASA.

Federico.

[rcoote5902_2]

Yes, the dmz network uses the dmz interface of the ASA (10.10.10.1) as the default gateway.

[Federico Coto Fajardo]

Enter the command:

management  access-dmz

See, if you can PING from the ASA to the other side.

ping dmz x.x.x.x

x.x.x.x --> should be an live IP from the other side of the tunnel.

Also, the other side has a route to 10.10.10.0/24 to send it through the tunnel?  As they have it for your INSIDE LAN?

Federico.

[rcoote5902_2]

Here are the results:

FrecASA(config)# management-access dmz

FrecASA(config)# ping dmz 172.16.69.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.69.1, timeout is 2 seconds:
?!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/20/20 ms

I've also attached the config for the remote site PIX relevant to the VPN connection.

[Federico Coto Fajardo]

It worked.

The only thing missing to make this working is to allow the traffic to the remote site in the ACL applied to the DMZ.

access-list dmz_acl

Try it and it should work fine.

Federico.

[rcoote5902_2]

I tried opening up the dmz_acl to try that but it doesn't appear to work.  Here is the config:

access-list dmz_acl extended permit icmp 10.10.10.0 255.255.255.0 172.16.0.0 255.255.0.0
access-list dmz_acl extended permit icmp 10.10.10.0 255.255.255.0 10.3.0.0 255.255.0.0
access-list dmz_acl extended permit tcp 10.10.10.0 255.255.255.0 172.16.0.0 255.255.0.0 eq www
access-list dmz_acl extended permit tcp 10.10.10.0 255.255.255.0 10.3.0.0 255.255.0.0 eq www
access-list dmz_acl extended permit ip any any

access-group dmz_acl in interface dmz

[Federico Coto Fajardo]

Ok,

We are trying to accomplish the VPN connection between the DMZ 10.10.10.x and the remote network 172.16.69.x

We know that we can PING 172.16.69.x from the ASA's DMZ IP.

The ACL on the DMZ is now permitting the traffic.

Try sending traffic again and check the following command on the ASA:

sh cry ips sa

You should see two IPsec security associations created for the traffic flowing between those networks (one outgoing and one incoming).

Check also the packets encapsulated/decapsulated so that you can see for example that you're sending traffic but not receiving anything back.

Let me know.

Federico.

[rcoote5902_2]

We can ping only when setting management-access to the dmz interface.  Without it, the pings fail.

I posted the results of the two pings (with and without management-access) and the sh cry ips sa.

Rob

[Federico Coto Fajardo]

From the file that you attached, I see the security association created between 10.10.10.0/24 and 172.16.68.0/24

and the packets are being sent and received fine.

The fact that you can PING from the ASA's DMZ IP (when having the management access-dmz command), means there's communication between both networks correctly.

Let's do a test between two hosts (10.10.10.x and 172.16.68.x)

Try to PING and let me know the default gateway for both (and check on the sh cry ip sa) if you see the packets encrypted/decrypted incrementing everytime).

Federico.