Pix 515 to ASA 5520 Migration - No outside traffic...

Unanswered Question
Mar 27th, 2009


We're in the process of migrating over to an ASA 5520 from a Pix 515. We've made several attempts and so far none have been successful.

I've used the pix to asa migration too and combed thoroughly through the resultant config and everything looks good, however the cutover never works. We're using the exact same IP's and simply moving the inside and outside cables to the new inside and outside ports on the ASA - and then restarting our router.

From the ASA I cannot ping to the internet if I specify to use the inside interface. I can ping both inside and outside addresses normally however.

Any help on where to start looking for an answer would be appreciated. I'm not sure how to debug the traffic going across the ASA.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jon Marshall Fri, 03/27/2009 - 10:43

Have you tried internet access from behind the inside interface of the ASA ie. from a client machine ?

Testing ping from the inside interface to outside is never a good test of connectivity.

What happens from a client behind the ASA, can you

1) connect to a URL

2) connect to IP address

If not could you post a sanitised config


rcoote5902_2 Fri, 03/27/2009 - 13:14

Thanks, I did the extended ping from the inside interface as a test after not being able to surf or ping from a client machine.

Trying to surf from a client machine results in the generic "page cannot be displayed".

I'll attach a scrubbed config...let me know if you see anything we can change. The routing has been omitted as well, but it's identical to what was on the pix.

Jon Marshall Fri, 03/27/2009 - 13:58

Okay, config looks okay to me.

What is the default-gateway of the inside clients ?

When you try to bring up a web page from a client does the traffic reach the ASA.

You mention that you are reloading the router but what about inside devices ie.

if the default-gateway of the clients is the ASA inside interface then all their arp caches will point to the old pix mac-address.

if the default-gateway of the inside clients is a L3 device inside your network then what about it's arp table needing updating.


rcoote5902_2 Fri, 03/27/2009 - 14:20

All clients are configured to use our router as the default gateway. The router has ip route pointing to the inside interface of the PIX/ASA.

The PIX/ASA has route outside pointed to our ISP's router.

I'd assume rebooting the router would update it's ARP table...but it's something to check. We're going to try again here in a couple of minutes.

Jon Marshall Fri, 03/27/2009 - 14:21

Actually you don't need to reboot the router, just use this command from the enable prompt

router# clear ip arp


rcoote5902_2 Fri, 03/27/2009 - 14:47

Just a note, the ISP has a Cisco 3350 Switch as the access router...would I need to contact my ISP to have them make some changes?

Jon Marshall Fri, 03/27/2009 - 14:53

I'm not clear on your topology setup but you should clear any arp tables that may have cached the old pix mac-address.


rcoote5902_2 Fri, 03/27/2009 - 15:47

Some days I'm not clear on it either, I sort of inherited it. :)

Here's a rough sketch. I updated the arp on our Wan router and is still didn't work. I can't get into the ISP's managed device obviously but I'm wondering if that isn't an issue.

From the ASA I can ping the ISP's 3550, but still no internet.

rcoote5902_2 Mon, 03/30/2009 - 07:03

Well it's spring break here so I have a week to get this running while school is out. Any further help would be awesome.

souvik.mazumdar Mon, 03/30/2009 - 07:18


Have u configured the revers routes in ur asa towards ur internal router. or the ASA inside address is in the same subnet as the internal users.

Also if u r having public ip in ur exter interface of ASA u can use that for your nat global configuration also.


rcoote5902_2 Mon, 03/30/2009 - 19:04

Ok let me pose another question...once we have the ASA in place, what can we do to pinpoint where the issue is?

souvik.mazumdar Mon, 03/30/2009 - 23:04


u can run capture in ASA to check if traffic from hosts are coming to ASA or not destined for internet.


a.alekseev Tue, 03/31/2009 - 02:54

no global (outside) 1 xxxxxxxxxxx netmask xxxxxxxxx

global (outside) 1 interface

rcoote5902_2 Tue, 03/31/2009 - 07:34

We actually don't use the same IP on the outside interface as our global NAT address, so that wouldn't work for us.

vmilanov Tue, 03/31/2009 - 08:39


First, about the pings - have managed to ping the default gateway IP, without specifying source interface? This will source your pings with the IP address of the outside interface.

If you are not successful with this, ask your ISP about any MAC ACL or port security applied on the 3550's interface, on which the ASA is connected.

Also, I don't think sourcing the pings with the inside's ip is the same as a traffic arrived at the inside interface. This is locally generated traffic and it traverses cpu-to-interface rather than interface-to-interface. Thus it would leave the ASA just having source ip of the inside, but w/o traversing any NAT statements. A better test would be to try a telnet connection from your router, to lets say www.google.com on port 80, and post here the ASA output from the 'show xlate' and 'show connections' commands. A good practice at that time would be to have debug level logging enabled, either on the monitor or the console, or the buffer, so you can see what happened actually.



rcoote5902_2 Tue, 03/31/2009 - 09:39

Ok I'm attaching both the PIX config and the converted ASA config as well as a topology map showing how our Internet traffic is routed.

An example traceroute:

C:\>tracert <A HREF="javascript:newWin('http://www.google.com')">www.google.com</A>

Tracing route to <A HREF="javascript:newWin('http://www.l.google.com')">www.l.google.com</A> []

over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms

2 1 ms 1 ms 1 ms host-199-216-81-1.sturgeon.ab.ca []

3 * * * Request timed out.

4 7 ms 6 ms 6 ms ra2so-ge3-2-77.cg.bigpipeinc.com []

The 3550 Switch labelled A is a managed device owned by Alberta SuperNet - who provides our WAN services between schools. Our Internet traffic goes through that device but it provides no layer 3 services for net traffic, it's all passed onto our ISP further upstream.

Both SuperNet and our ISP have said nothing is set on their side that would prevent us from a cutover - MAC security or ACLs.

We're really stumped. I'm hoping someone can shed some light on this puzzle. I'm not really a WAN/Security expert but everything I've read about moving from PIX to ASA should be rather simple. My hair is getting grayer. :)

vmilanov Tue, 03/31/2009 - 15:52

Hi again,

The topology you have posted represents the physical one, which does not match the logical interconnections.

For example, it is not clear how the inside networks have been routed:

- many vlnas to the router, and it routes intervlan, or

- a switch on the path is doing L3 switching.

I saw the asa config, it looks to me ok, although I have not compared it to the pix one if they match completly. As you have posted the output of a tracert from a host somewhere behind the router works fine ;-).

As I mentioned before, try a telnet connection to a internet host on port 80, and post here the output of the 'show xlate' and show connections' asa commands.



Also, please, be more specific what exactly is not working.

rcoote5902_2 Tue, 03/31/2009 - 21:08

Our router does inter vlan routing.

The switch (3550) does not provide any layer 3 routing for the internet connection, it is just a conduit.

rcoote5902_2 Wed, 04/01/2009 - 07:45


Using the packet tracer in the ASDM the traffic appears to be failing due to NAT.

The packet tracer shows this as the config that is causing the drop:


nat (inside) 1

match ip inside any outside any

dynamic translation to pool 1 (

translate_hits = 971, untranslate_hits = 74

The NAT config on the ASA:

global (outside) 1 netmask

nat (inside) 1

The NAT config on the PIX:

global (outside) 1

nat (inside) 1 0 0

Where is the problem??

vmilanov Thu, 04/02/2009 - 06:42


Missed translation hits might be caused by the static entries you have, because they would be different translation entries.

It might be a problem with the proxy-arp functionality.

To be sure that it is properly configured issue:

show running-config sysopt

In the output you should not have 'sysopt noproxyarp outside'. But it's the default setting. Just check it for sure.

Otherwise, if the above looks OK, try to replace the global with nat to the interface ip and see if that way things would work:

no global (outside) 1 netmask

global (outside) 1 interface

clear xlate

If it seems to you a bug, try to move to higher version, 8.0(4) for example.





This Discussion