• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 332
  • Last Modified:

Outside interface drops 90% of packets after adding third interface

I've got a 5505 ASA that I'm trying to add a second outside port to. Currently it has an inside, and outside port like most ASA setups. I'm trying to 'dual home' the ASA so our VPN users can be moved to the new port's IP and then the first port can be disconnected. I tried adding the port straight in, but it had two issues.

1) I could not ping the gateway of the device connected to that new port.
2) The outside port that worked 100% just before starts losing 80-90% of all packets. It basically becomes unusable.

I removed the second port and everything went back to normal.

Any ideas? I need to get the VPN users moved over the next week before that second T1's contract is up.
  • 2
1 Solution
John MeggersNetwork ArchitectCommented:
You're running into routing and state issues.  You won't be able to use both outside ports at the same time, the redundant interface feature on the ASA is an active / standby type of arrangement.  You'll need to do a cutover.  My suggestion would be to shut the second outside interface for now.  Whenever you can schedule a maintenance window, do some testing by enabling the new and disabling the original interfaces, to make sure your configuration works.  Do that as many times as you need to work out the details, then schedule the cutover.  Just keep one or the other outside interfaces shut down.
jmpsandiegoAuthor Commented:
That's the problem. We don't have the resources to do that kind of a cutover. Each of these remote routers has to be managed via the LAN ports, which nothing but IP phones and printers are connected to. Unfortunately when they were sent out by the previous tech, they didn't bother to enable admin access over the WAN. It's a really annoying and confusing setup.

Any way to get around this? Or am I really just stuck with it being this way?

I tried to copy the VPN settings from one ASA to another and I attempted to put the 2nd ASA on the new connection but it wanted nothing to do with that. I couldn't get the VPN to connect on the newer ASA.
John MeggersNetwork ArchitectCommented:
The cutover shouldn't be that big of a deal for internal users, but agreed, it's probably a bigger deal for VPN connections.  Having the second ASA makes things a bit easier in some ways but more difficult in others.  Any way you slice it, though, it's still likely to involve some amount of down time for each of the VPN connections.  

When you say the second ASA wanted nothing to do with that, are you saying the VPN connections wouldn't connect?  It's not as simple as copying the configuration over to the other ASA, but depending on the number of tunnels, it shouldn't be an enormously big deal either.  How many VPN tunnels are we talking about?  For a 5505 at the head end, I hope not very many.  

Here's one trick that might help:  If you simply "show run" on the ASA, the VPN pre-shared keys are obscured, as in:

tunnel-group VPN_Group ipsec-attributes
 pre-shared-key *****

If you instead type "more system:running-config" the display includes those obscured PSKs in clear text.  As in:

tunnel-group VPN_Group ipsec-attributes
 pre-shared-key abcde12345

Very handy if you're not sure what PSK was used for a VPN tunnel.

If you keep things on the existing ASA, you should only need to change the peer statements on the remote peers; the config on the head-end ASA should stay the same (except for where the crypto map is applied), as will the ACLs, ISAKMP, transforms, etc. on both ends.  You will have to change the global statement (outside of the NAT configuration) to the new interface.  Your static default will change to the new ISP address, and DNS will likely change.  But I can't think of a whole lot more than that. Save an archive of all your existing configurations so you can reload and reboot if necessary.  But once you've started the migration, basically there's really no partial effort -- you're in it for the whole deal.  Let everyone know when you're going to make the change, preferably late at night.  You can pre-stage your VPN configurations in text files to just copy and paste (include your "no" statements at the beginning in the proper order).  Hate to say it, but this is where experience is key, and this is why consultants that can help with this kind of thing earn their money.  Good luck, and hope this helps.  
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now