ASA with default config (almost) will not pass traffic

Unanswered Question
Mar 30th, 2007

I have a brand new configuration. I made the fewest possible modifications for testing. Here are the only changes I made:

Added an IP (+mask) to the outside and inside interface.

Added a nat (inside) 0 0

Added a global (outside) PUBLIC_IP

Added a default route (0 0) to outside.

Did a no shutdown on inside and outside.

Then I put a client on the inside (with an appropriate IP).

I have NO ACLs. Security level inside is 100 and outside is 0.

I fired up the asdm and made it model the packet flow from my inside host to an outside web server's IP address (port 80). Checkmarks everywhere: Packet is allowed!

But while the client can ping the inside interface of the ASA, it cannot connect to the web (with IPs since DNS is not yet configured).

What should I be checking next (besdies the resale value of a slightly used ASA)?

BTW, I'm running the latest 7.2(2) with asdm 5.2.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
vitripat Fri, 03/30/2007 - 10:39

Not sure how your nat configuration looks like. Ideally, if you run "show run nat", it should yeild-

nat (inside) 1 0 0

show run global:

global (outside) 1 interface

From the ASA itself, test if you are able to ping the default Gateway IP and a public IP on internet, such as 4.2.2.2. If ASA can reach internet, then with above nat/global commands in, inside hosts should also be able to reach internet. If possible, please provide the outputs of following commands-

show run route

showr run nat

show run global

show run interface

You can also enable buffer logging for sometime to troubleshoot and check the syslogs-

logging buffer 7

logging on

Check the logs using command "show logg".

Hope that helps.

Regards,

Vibhor.

professorguy Fri, 03/30/2007 - 11:09

Here's the info. As you can see, I can see the outside network from the ASA (the ping and tracer). And I can see the inside network from the ASA (the ping to 10.200...).

But the inside host cannot see the web.

--------------------------

ciscoasa(config)# sho run route

route outside 0.0.0.0 0.0.0.0 1

ciscoasa(config)# show run nat

nat (inside) 1 0.0.0.0 0.0.0.0

ciscoasa(config)# show run global

global (outside) 1 netmask 255.255.255.240

ciscoasa(config)# sho run interface

!

interface GigabitEthernet0/0

nameif outside

security-level 0

ip address 255.255.255.240

!

interface GigabitEthernet0/1

nameif inside

security-level 100

ip address 10.200.1.1 255.255.255.0

ciscoasa(config)# tracer 64.72.8.16 <-- a web site

Type escape sequence to abort.

Tracing the route to 64.72.8.16

1 0 msec 0 msec 0 msec

2 1x.2x.1x.1 0 msec 10 msec 0 msec

3 1x.1x.3x.7x 0 msec 10 msec 10 msec

4 1x.1x.40.162 10 msec 10 msec 10 msec

5 1x.1x.5.53 10 msec 20 msec 10 msec

6 1x.1x.10.22 10 msec 20 msec 10 msec

7 1x.1x.3.109 10 msec 20 msec 10 msec

8 192.205.33.54 40 msec 30 msec 40 msec

9 64.215.24.178 20 msec 30 msec 40 msec

10 64.72.31.73 50 msec 40 msec 50 msec

. . . .

ciscoasa# ping

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

ciscoasa# ping 10.200.1.101

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.200.1.101, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

------------------------

vitripat Fri, 03/30/2007 - 11:14

Can you try these commands-

no global (outside) 1 netmask 255.255.255.240

global (outside) 1 interface

clear xlate

Now check if you are able to access internet. If this thing works, it might indicate an issue with the public IP being used earlier and you may need to get in touch with ISP to get the arp cache cleared on the ISP router or verify if that IP actually belongs to you.

Hope that helps.

Regards,

Vibhor.

professorguy Fri, 03/30/2007 - 11:31

I tried that and no such luck. Besides, I want 1 address which can be the target of VPN peers (the outside interface ip) and a different address for inside clients to use on the internet.

However, you bring up a good point--I didn't think of the upstream device's cache. I have used several different IPs while testing this device on my ISP's router. So any caching there has got to be seriously munged.

Now I happen to have some control over my ISP's router (how many of you can say the same?) so I can power cycle it, but that would be disruptive to our production network (off another port of the same router). I would rather let any cache timeout. They use a Cisco 3550--how long before the arp cache on my test port is gone?

acomiskey Fri, 03/30/2007 - 11:45

but you can ping the isp router from the asa, and if you pat'd to the outside interface and it still didnt work, you could probably rule out arp problem right?

professorguy Fri, 03/30/2007 - 12:48

Correct. Since the ping and tracer was able to get the packets back from the internet to the outside asa interface through my ISP router, the router must know the correct location of that public ip address. Therefore, I'd say that is not the source of the problem.

On Monday I will remove the switch between my inside client and the asa. It was passing the pings aimed at the asa OK (which is on the same subnet as the client), but perhaps packets for the outside (on a different subnet) get lost in the switch. Although I don't have high hopes since the switch has a default-gateway which is the IP of the asa inside interface.

Let's take it up next week.

professorguy Tue, 04/03/2007 - 05:48

OK, got rid of the inside switch and put the client directly on the inside interface and voila, it can see the internet (without DNS so far).

So there're switch setting problems. I will mess with them to get the client on a vlan access port, and connect a trunk with that vlan native (so the packets will not be tagged on the trunk) to the firewall.

If that doesn't work, I'll post another topic.

Actions

This Discussion