ASA 5520 - VPN users have no internet.

Answered Question
Apr 6th, 2010

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

I have this problem too.
0 votes
Correct Answer by Federico Coto F... about 6 years 9 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (16 ratings)
Loading.
Federico Coto F... Tue, 04/06/2010 - 13:46

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.

rcoote5902_2 Tue, 04/06/2010 - 14:03

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

Federico Coto F... Tue, 04/06/2010 - 14:13

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.

rcoote5902_2 Tue, 04/06/2010 - 14:49

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

Federico Coto F... Tue, 04/06/2010 - 15:11

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.

rcoote5902_2 Tue, 04/06/2010 - 15:36

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

Jennifer Halim Tue, 04/06/2010 - 16:36

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.

Federico Coto F... Wed, 04/07/2010 - 08:22

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.

rcoote5902_2 Wed, 04/07/2010 - 08:43


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#

Federico Coto F... Wed, 04/07/2010 - 08:54

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.

slmansfield Wed, 04/07/2010 - 09:04

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

rcoote5902_2 Wed, 04/07/2010 - 09:14

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.

Federico Coto F... Wed, 04/07/2010 - 09:19

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 Wed, 04/07/2010 - 09:22

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 Wed, 04/07/2010 - 09:28

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 F... Wed, 04/07/2010 - 09:30

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 F... Wed, 04/07/2010 - 09:35

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 Wed, 04/07/2010 - 09:49

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 F... Wed, 04/07/2010 - 09:53

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 Wed, 04/07/2010 - 09:55

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

Federico Coto F... Wed, 04/07/2010 - 10:02

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 Wed, 04/07/2010 - 10:15

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.

Attachment: 
Federico Coto F... Wed, 04/07/2010 - 10:36

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 Wed, 04/07/2010 - 10:52

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 F... Wed, 04/07/2010 - 10:59

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 Wed, 04/07/2010 - 11:12

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 F... Wed, 04/07/2010 - 12:03

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.

rcoote5902_2 Wed, 04/07/2010 - 12:18

Host: 172.16.69.1 (172.16.68.0/22 network)

Default gateway: 172.16.68.1

Ping 10.10.10.11

Request timed out.

Host: 10.10.10.11 (10.10.10.0/24 network)

Default gateway: 10.10.10.1

Ping 172.16.69.1

Request timed out.

sh cry ips sa results:

Before the first ping:

    Crypto map tag: outside_map, seq num: 1, local addr: 199.216.81.254

      access-list outside_1_cryptomap extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0

      local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)

      remote ident (addr/mask/prot/port): (172.16.68.0/255.255.252.0/0/0)

      current_peer: 68.151.96.239

      #pkts encaps: 7402, #pkts encrypt: 7402, #pkts digest: 7402

      #pkts decaps: 3822, #pkts decrypt: 3822, #pkts verify: 3822

      #pkts compressed: 0, #pkts decompressed: 0

      #pkts not compressed: 7402, #pkts comp failed: 0, #pkts decomp failed: 0

      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

      #send errors: 0, #recv errors: 0

      local crypto endpt.: 199.216.81.254, remote crypto endpt.: 68.151.96.239

First ping:

    Crypto map tag: outside_map, seq num: 1, local addr: 199.216.81.254

      access-list outside_1_cryptomap extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0
      local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (172.16.68.0/255.255.252.0/0/0)
      current_peer: 68.151.96.239

      #pkts encaps: 7402, #pkts encrypt: 7402, #pkts digest: 7402
      #pkts decaps: 3826, #pkts decrypt: 3826, #pkts verify: 3826
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 7402, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 199.216.81.254, remote crypto endpt.: 68.151.96.239

Second ping, going the other way:

    Crypto map tag: outside_map, seq num: 1, local addr: 199.216.81.254

      access-list outside_1_cryptomap extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0
      local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (172.16.68.0/255.255.252.0/0/0)
      current_peer: 68.151.96.239

      #pkts encaps: 7402, #pkts encrypt: 7402, #pkts digest: 7402
      #pkts decaps: 3826, #pkts decrypt: 3826, #pkts verify: 3826
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 7402, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 199.216.81.254, remote crypto endpt.: 68.151.96.239

Federico Coto F... Wed, 04/07/2010 - 12:26

Ok,

Let's figure out what's happening exactly:

Configure the following on the ASA:

access-list INSIDE permit ip host 10.10.10.11 host 172.16.69.1

access-list INSIDE permit ip any any

access-group INSIDE in interface inside

Then, send traffic from 10.10.10.11 to 172.16.69.1

When you do a ''sh access-list INSIDE'' you should see hitcounts on the first line.

If that line does not increment, sorry to insist but please check the default gateway for 10.10.10.11

If the line increments, then we'll check why those packets are not being sent through the tunnel.

Federico.

rcoote5902_2 Wed, 04/07/2010 - 12:44

It does not increment.  Here is the ping and default gateway from 10.10.10.11:

Pinging 172.16.69.1 with 32 bytes of data

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Windows IP Configuration

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   IP Address. . . . . . . . . . . . : 10.10.10.11
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.10.10.1

Federico Coto F... Wed, 04/07/2010 - 13:05

I am sorry, I made a mistake:

Do the following:

no access-list INSIDE permit ip host 10.10.10.11 host 172.16.69.1

no access-list INSIDE permit ip any any

no access-group INSIDE in interface inside

And include the first line on the DMZ ACL to be this:

access-list dmz_acl line 1 permit ip host 10.10.10.11 host 172.16.69.1

Do the same test please.

Federico.

rcoote5902_2 Wed, 04/07/2010 - 13:38

Don't be sorry!  You are my hero right now helping me with this.

I removed the old acl and added as the first line the 10.10.10.11 to 172.16.69.1 to dmz_acl.

That hitcount does increment when pinging from 10.10.10.11 to 172.16.69.1.

Federico Coto F... Wed, 04/07/2010 - 14:02

What it seems right now, is that the traffic from 10.10.10.11 is reaching the ASA, passing thru, now let's see if it is matched against the NONAT rule.

Do a ''clear xlate local 10.10.10.11''

Check the ''sh xlate local 10.10.10.11'' when connecting through the VPN.

What I want is to check if traffic from 10.10.10.11 to 172.16.69.1 is being NATed by the ASA or it is bypassing NAT (so that it can be sent through the tunnel).

Federico.

rcoote5902_2 Wed, 04/07/2010 - 14:19

I did a clear and then a sh xlate local 10.10.10.11 on the ASA:

Global 199.216.81.7 Local 10.10.10.11

I'm not sure how you want me to check the sh xlate local when connecting through the vpn?

Federico Coto F... Wed, 04/07/2010 - 14:24

What I want is to check if the traffic from 10.10.10.11 going to 172.16.69.1 is being NATed.

Do the following:

sh xlate local 10.10.10.11 detail

After sending traffic to 172.16.69.1

This will show if the traffic is going or not going through NAT when trying to reach its destination.

Federico.

rcoote5902_2 Wed, 04/07/2010 - 14:28

I set up a persistent ping from 10.10.10.11 to 172.16.69.1 and then did as you say "sh xlate local 10.10.10.11 detail" on the ASA:


FrecASA# sh xlate local 10.10.10.11 detail
651 in use, 4162 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
       r - portmap, s - static
NAT from dmz:10.10.10.11 to outside:199.216.81.7 flags s

rcoote5902_2 Wed, 04/07/2010 - 14:31

And here's the sh loc 10.10.10.11:

FrecASA# sh xlate local 10.10.10.11 detail
790 in use, 4162 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
       r - portmap, s - static
NAT from dmz:10.10.10.11 to outside:199.216.81.7 flags s

FrecASA# sh loc 10.10.10.11
Interface dmz: 1 active, 3 maximum active, 0 denied
local host: <10.10.10.11>,
    TCP flow count/limit = 37/unlimited
    TCP embryonic count to host = 0
    TCP intercept watermark = unlimited
    UDP flow count/limit = 4/unlimited

  Conn:
    UDP dmz 10.10.10.11:2208 inside 172.16.55.1:88, idle 0:00:12, bytes 2556, flags -
    UDP dmz 10.10.10.11:2207 inside 172.16.55.1:88, idle 0:00:12, bytes 1592, flags -
    UDP dmz 10.10.10.11:138 inside 172.16.131.33:138, idle 0:01:33, bytes 184, flags -
    UDP dmz 10.10.10.11:137 inside 172.16.131.33:137, idle 0:01:26, bytes 909, flags -
    TCP dmz 10.10.10.11:3700 inside 172.16.131.1:8194, idle 0:00:35, bytes 109719, flags UIOB
    TCP dmz 10.10.10.11:3696 inside 172.16.131.13:443, idle 0:02:48, bytes 672619, flags UIOB
    TCP dmz 10.10.10.11:3682 inside 172.16.131.253:139, idle 0:00:24, bytes 40543, flags UIOB
    TCP dmz 10.10.10.11:80 inside 172.16.34.111:1504, idle 0:00:12, bytes 85267, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.49.33:2121, idle 0:00:20, bytes 33402, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.49.33:2120, idle 0:00:16, bytes 34181, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.49.33:2119, idle 0:00:20, bytes 37893, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.49.33:2118, idle 0:00:16, bytes 2817857, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.49.33:2117, idle 0:00:20, bytes 84879, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.49.33:2114, idle 0:00:20, bytes 119413, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.34.67:2223, idle 0:00:24, bytes 7255, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.34.67:2222, idle 0:00:20, bytes 48496, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.41.13:2071, idle 0:00:26, bytes 2902, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.41.13:2070, idle 0:00:30, bytes 3550, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.41.13:2069, idle 0:00:30, bytes 4042, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.41.13:2067, idle 0:00:30, bytes 44556, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.33.16:2114, idle 0:00:47, bytes 5418, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.33.16:2113, idle 0:00:49, bytes 49340, flags UIO
    TCP dmz 10.10.10.11:80 inside 10.3.18.90:49165, idle 0:00:38, bytes 13814, flags UfFrIO
    TCP dmz 10.10.10.11:80 inside 10.3.18.90:49164, idle 0:00:25, bytes 8389, flags UfFrIO
    TCP dmz 10.10.10.11:80 inside 10.3.18.90:49163, idle 0:00:38, bytes 28152, flags UfFrIO
    TCP dmz 10.10.10.11:80 inside 10.3.18.90:49162, idle 0:00:10, bytes 4714, flags UfFrIO
    TCP dmz 10.10.10.11:80 inside 10.3.18.90:49161, idle 0:00:00, bytes 353487, flags UfrIO
    TCP dmz 10.10.10.11:80 inside 10.3.18.90:49160, idle 0:00:19, bytes 79752, flags UfFrIO
    TCP outside 142.166.193.65:60295 dmz 10.10.10.11:80, idle 0:00:37, bytes 7596, flags UIOB
    TCP outside 142.166.193.65:60294 dmz 10.10.10.11:80, idle 0:00:37, bytes 2179, flags UIOB
    TCP outside 142.166.193.65:60293 dmz 10.10.10.11:80, idle 0:00:42, bytes 3679, flags UIOB
    TCP outside 142.166.193.65:60288 dmz 10.10.10.11:80, idle 0:00:37, bytes 14180, flags UIOB
    TCP outside 142.166.193.65:60287 dmz 10.10.10.11:80, idle 0:00:06, bytes 19689, flags UIOB
    TCP outside 142.166.193.65:60286 dmz 10.10.10.11:80, idle 0:00:37, bytes 5157, flags UIOB
    TCP dmz 10.10.10.11:3389 inside 172.16.130.67:56031, idle 0:00:00, bytes 158859, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.101.22:2791, idle 0:10:55, bytes 47078, flags UIO
    TCP dmz 10.10.10.11:445 inside 172.16.33.170:1494, idle 0:00:16, bytes 3406, flags UIO
    TCP dmz 10.10.10.11:80 inside 172.16.73.48:1821, idle 0:30:34, bytes 27760, flags UIO
    TCP dmz 10.10.10.11:445 inside 172.16.45.56:2466, idle 0:00:21, bytes 2724286, flags UIO
    TCP dmz 10.10.10.11:445 inside 172.16.130.58:1406, idle 0:00:06, bytes 103884465, flags UIO
    TCP dmz 10.10.10.11:445 inside 172.16.131.3:1518, idle 0:00:07, bytes 123319641, flags UIO
Interface inside: 187 active, 325 maximum active, 0 denied
Interface outside: 268 active, 1382 maximum active, 0 denied

Federico Coto F... Wed, 04/07/2010 - 14:35

Traffic is permitted by the ASA, is not being NATed (but is not being encrypted so it's not sent through the tunnel).

The problem is why is not being encrypted?

In order to resolve it, please post the current ''sh run'' from your ASA (is possible from the PIX as well)

Thank you,

Federico.

Jennifer Halim Wed, 04/07/2010 - 14:35

Check if you have icmp inspection, if not, please add the following:

policy-map global_policy
class inspection_default

     inspect icmp

Federico Coto F... Wed, 04/07/2010 - 15:12

I would do this:

no access-list inside_nat0_outbound extended permit ip 10.10.10.0 255.255.255.0 172.16.68.0 255.255.252.0
no nat (dmz) 0 access-list inside_nat0_outbound
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

To completely isolate the inside and dmz traffic.

Let's try again.

Federico.

rcoote5902_2 Wed, 04/07/2010 - 15:27

Ok I made those changes, not seeing anything different.  Pings both ways time out.

Correct Answer
Federico Coto F... Wed, 04/07/2010 - 15:35

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.

Federico Coto F... Wed, 04/07/2010 - 19:41

I checked the configuration again.

I would like to know if you can PING:

From the 172.16.68.0/24 you can PING 10.10.10.1

From the 10.10.10.0/24 you can PING 172.16.68.1

Basically from either network reaching the inside IP of the other side of the tunnel endpoint.

Let me know if both PINGs are succesful.

Federico.

rcoote5902_2 Thu, 04/08/2010 - 07:11

No, I cannot ping the gateways of the other network from either 172.16.68.0/22 or 10.10.10.0/24

Federico Coto F... Thu, 04/08/2010 - 13:08

Try to PING again, but remember that you should have these commands:

management access-dmz --> On the ASA

management access-inside --> On the PIX

Federico.

rcoote5902_2 Thu, 04/08/2010 - 17:05

Alright, the good news is - it works.

The bad news, I had to blow out the config on both sides (we'd had a contractor code the tunnel for us initially and I don't think he really had a clue) and reconfigure it from scratch.  Removing the PFS was one thing I made sure of because it didn't make any sense to me after you mentioned it that it was set on the ASA but not the firewall.  I'm not even sure that old PIX supports PFS so I just eliminated it.

Federico you are so patient and helpful, thank you so much for all your support with this.  I learned a lot.

Cheers,

Rob

Actions

This Discussion

Related Content