Why isn't the VPN between two Cisco ASA 5505s working?

November 23, 2008 4:24 PM

Why isn't the VPN between two Cisco ASA 5505s working when I switch ISPs? One of the ASA 5505s is sort-of dual homed in the new configuration. The VPN appears to establish, but I can't pass traffic from one LAN to the other.

We currently have a IPSec VPN between the office and our colo across a business-class cable line. We recently got a symmetric DSL line in the office in order to improve upload speeds to the colo from the office. Ideally, we'd like to have the cable line for ordinary Internet traffic, and the DSL just for the VPN traffic to the colo.

The ASA in the office has the DSL connected to ethernet port 7, which we've set up as a separate VLAN named "colo", in addition to the standard "inside" and "outside" VLANs. This ASA has a "restricted" license so only VLANs, and traffic between "outside" and "colo" is blocked.

I set up a static route using the "colo" interface to the colo ASA. Traceroute looks correct, and I can ping through it (in fact, I can ping from behind the ASA, from one of the internal machines on the office LAN). I then did an "isakmp enable colo", and switched the interface associated with the crypto map from "outside" to "colo".

On the ASA in the colo, I changed the peer for the crypto to the IP of the DSL line. I also added a tunnel group for this IP.

The VPN establishes -- I can see it in the ADSM and through "show crypto ipsec sa" -- but I can't send traffic from one LAN to the other. Ping doesn't work. ssh from an office server to a colo server seems to start but doesn't get anywhere. Strangely, when I telnet to the ssh port of the colo server, I see the usual SSH banner, so something seems to get through.

Any ideas? I haven't really touched the access lists on either ASA, as they appear to be correct. All I'm doing is changing the IP address of the "office", albeit to a different interface/VLAN. Is this a licensing problem for the ASA?

Thanks.

posted by chengjih to Computers & Internet (4 answers total)

Try clearing your translate tables ("clear xlate") to see if that helps. Also, once the VPN is up, try the packet-tracer tool (either IOS or ASDM) to see where/whether it complains anywhere along the line.

Does the problem only manifest when changing ISPs, or is it tied to one or the other? If it's tied to changing then my guess would be the xlate tables are stale. If it's tied to one of the two ISPs then I'd look at your NAT tables to make sure they're correct for both scenarios.

Final comment -- you have support? Open a Cisco TAC. They'll clear it up in no time.
posted by devbrain at 5:48 PM on November 23, 2008

Best answer: seconding the clear xlate and also try to clear the old vpn cruft

(save a copy of your config first and make sure you have the vpn shared keys before you do this. typo'ing this will nuke chunks of your crypto config which is really annoying if you happen to do it in the middle of the business day. NOT THAT I'VE EVER DONE THAT, HONEST.)

clear cryp isa sa
clear cryp ip sa

then generate traffic and check the status of the vpns --
sh cryp is sa

debug cryp isa, debug cryp is, debug cryp events, debug cryp engine can also help shed light on things.

but yeah, if you've got support, hit the TAC up.
posted by rmd1023 at 6:05 PM on November 23, 2008

Response by poster: Thanks. It turned out to be a routing issue. The default route was left using the "outside" interface, so colo traffic got pushed out through there rather than the new "colo" interface.

Once I set static routes so that colo traffic went through "colo", I assume the ASA realized that it was supposed to wrap all that inside the VPN and send it to its destination.
posted by chengjih at 6:32 AM on November 24, 2008

hooray for fixed!

one bit of asa advice: whenever i have a really weird problem, it's usually the NAT setup.
posted by rmd1023 at 7:19 AM on November 30, 2008