how can AnyConnect users get to remote site via ASA-hosted IPSec tunnel?

[accudataa]

We have a pair of ASA 5510s in an active/passive HA configuration. Remote users connect via AnyConnect and access resources in our corporate site. We also have three IPSec site-to-site VPNs to link our datacenter sites with the corporate site.

We now want some users to be able to access the datacenter sites when connected via AnyConnect. Right now, they have to connect to a client on the corporate network, usually via MS terminal services, then connect to one of the datacenter hosts. We want traffic to be routed directly from their remote client to one or more of the datacenters.

One additional catch is that we'd like to implement datacenter access via a group policy, so that only certain AnyConnect clients can connect to the datacenters.

We've already enabled intra-interface traffic, because we don't allow them split tunneling, and Internet access also goes through the ASA when remote users are connected.

Some network parameters:

corporate network: trusted/24 (192.168.10.0/24)

AnyConnect users: VPN/24 (192.168.4.0/24)

datacenter A: DC-A/24 (192.168.20.0/24)

datacenter B: DC-B/24 (192.168.21.0/24)

datacenter C: DC-C/24 (192.168.22.0/24)

The connection profile for the DC A VPN has trusted/24 and VPN/24 as the local networks, DC-A/24 as the remote network. There is a corresponding cryptomap/ACL entry. I have a NAT-exempt rule on the external (public Internet) interface with a source of VPN/24 and destination of DC-A/24.

Right now, I get no connectivity to DC-A when connected via Anyconnect. If I run the packet tracer within ASDM, using external as the interface, 192.168.4.1:1024 as the source and 192.168.20.1:80 as the destination, the trace fails at the access list lookup, showing me that the final drop-any rule on the external interface is causing the packet to be dropped. We have VPN connections set up to ignore ACLs so I'm lost on this one.

Does anyone have any suggestions?

[cdusio]

I think your packet tracer doesn't take into account VPN's and that's why it's dropping..

Once you connect, you can run a capture from within the ASDM or on the console to see if the packets getting there..

Are you seeing anything in the ASDM logging indicating an issue?

Does the DC know how to get to the VPN subnet?

If you're connected to the VPN those are the places I would start.

[accudataa]

The DC A Firewall (provided to us by the co-location center, and based on open source) has a static route to VPN/24 which specifies the inside address on the ASA (192.168.10.252) as the gateway.

Now that I type that I'm seriously wondering if that's correct. The VPN subnet isn't associated with the inside interface...

[cdusio]

I think you're running into a NAT issue.

it's an outside to outside issue so look for "no translation group" messages.. From the ASA's perspective its a connetion coming into and going out of the outside interface..

I have seen this many times..

[accudataa]

Well, that's something.

I get "%ASA-3-305005: No translation group found for udp src external:192.168.4.10/137 dst external:192.168.4.255/137" when I try to ping a host in DC A.

[cdusio]

Bingo. that's your issue...

Create a nat exemption rule for outside to outside and that should fix it.

access-list Outside_nat0_outbound_1 extended permit ip object-group Trusted_Networks object-group Trusted_Networks... Substitute your networks...

-C

[accudataa]

So I did this:

access-list external_nat0_outbound_1 extended permit ip 192.168.4.0 255.255.255.0 192.168.20.0 255.255.255.0

I got three new ACEs: external_nat0_outbound_1, external_nat0_outbound, and "1", with the last allowing TCP from any to any. I don't get the no-translation-group message any longer, but I don't have connectivity either.

That any-to-any seemed kind of hair-raising, so I removed the ACE and changed it to "access-list external_nat0_outbound..." and got only the one ACE. That one gives me the no-translation-group message.

[accudataa]

arrgh...some days I have extended stupid.

I went back to a config I saved this morning, and the "1" ACE was already there, so I imagine that's not a mistake or a security risk.

There was also this:

access-list external_nat0_outbound extended permit ip 192.168.4.0 255.255.255.0 192.168.20.0 255.255.255.0

So now I'm really confused. "external_nat0_outbound" still has the no-translation-group error, but when I added "external_nat0_outbound_1" it went awat. Still no connectivity, though.

So I'll be exceptionally dumb: does the VPN subnet need to be part of the VPN policy on the DC A firewall? I noticed I was getting these errors when I would try to connect:

2009-02-11 16:52:04 Local4.Error zz.zz.zz.zz %ASA-3-713902: Group = xxx.xxx.xxx.xxx, IP = xxx.xxx.xxx.xxx, QM FSM error (P2 struct &0xd576daa0, mess id 0xaf8d76ae)!

2009-02-11 16:52:04 Local4.Alert zz.zz.zz.zz %ASA-1-713900: Group = xxx.xxx.xxx.xxx, IP = xxx.xxx.xxx.xxx, construct_ipsec_delete(): No SPI to identify Phase 2 SA!

2009-02-11 16:52:04 Local4.Error zz.zz.zz.zz %ASA-3-713902: Group = xxx.xxx.xxx.xxx, IP = xxx.xxx.xxx.xxx, Removing peer from correlator table failed, no match!

A quick check of Google says that error is caused by having mismatched subnet(s) between the ends of the tunnel. I'm starting to think just having the static route on the DC A firewall isn't going to cut it...

[cdusio · Accepted solution]

yes of course it does. The crypto maps have to match on both sides. I would have suspected though that all your traffic to DC-A wouldn't be working.

If you want to give me your contact info I will help you.

[cdusio]

stop worrying about the ACE's.

Match up the crypto maps for the LAN to LAN stuff.

Match up your no_nat rules...

You need the tunnel to DC-A and HQ to be up obviously and then you need the no_nat ACL to work correctly.

[JORGE RODRIGUEZ]

Hi,

Don't mean to hijack this post, and with all the respect by all means.

You are almost %99 there to resolve your problem with Chri's recomendations.

important point on geting this to work is that Chris has dictated , on every firewall or device you have the Ipsec tunnels terminated on between DCs and Corporate you have to taylor the nonat acls and their respective crypto maps in adding the RA networks from Corporate for interesting traffic on the tunnels.

Chris pointed out key observation, I quote ! it's an outside to outside issue so look for "no translation group" messages

for this above you will need in Corporate network firewall where all the IPsec tunels converges and the L2L traffic from DC-A,B and C will hit outside interface incuding RA vpn

same-security-traffic permit intra-interface

nat (outside) 0 access-list inside_nat0_outbound

lets brake it down, I would recommend to work with a single nonat acl name for this particular scenario.

In corporate network: trusted/24 (192.168.10.0/24) and AnyConnect users: VPN/24 (192.168.4.0/24)

Corporate has tree L2Ls plus RA VPN

RA VPN 192.168.4.0/24

Corporate to DATACENTER A 192.168.20.0/24

Corporate to DATACENTER B 192.168.21.0/24

Corporate to DATACENTER C 192.168.22.0/24

You may try this :

In Corporate Network firewall:

for AnyConnect users: VPN/24 (192.168.4.0/24) to access datacenter A: DC-A/24 (192.168.20.0/24)

for AnyConnect users: VPN/24 (192.168.4.0/24) to access datacenter B: DC-B/24 (192.168.21.0/24)

for AnyConnect users: VPN/24 (192.168.4.0/24) to access datacenter C: DC-C/24 (192.168.22.0/24)

access-list inside_nat0_outbound extended permi ip 192.168.4.0 255.255.255.0 192.168.20.0 255.255.255.0

access-list inside_nat0_outbound extended permi ip 192.168.4.0 255.255.255.0 192.168.21.0 255.255.255.0

access-list inside_nat0_outbound extended permi ip 192.168.4.0 255.255.255.0 192.168.22.0 255.255.255.0

access-list outside_cryptomap extended permit ip 192.168.4.0 255.255.255.0 192.168.20.0 255.255.255.0

access-list outside_cryptomap extended permit ip 192.168.4.0 255.255.255.0 192.168.21.0 255.255.255.0

access-list outside_cryptomap extended permit ip 192.168.4.0 255.255.255.0 192.168.22.0 255.255.255.0

same-security-traffic permit intra-interface

nat (outside) 0 access-list inside_nat0_outbound

In DATACENTER A firewall

access-list inside_nat0_outbound extended permi ip 192.168.20.0 255.255.255.0 192.168.4.0 255.255.255.0

access-list outside_cryptomap extended permit ip 192.168.20.0 255.255.255.0 192.168.4.0 255.255.255.0

In DATACENTER B firewall

access-list inside_nat0_outbound extended permi ip 192.168.21.0 255.255.255.0 192.168.4.0 255.255.255.0

access-list outside_cryptomap extended permit ip 192.168.21.0 255.255.255.0 192.168.4.0 255.255.255.0

In DATACENTER C firewall

access-list inside_nat0_outbound extended permi ip 192.168.22.0 255.255.255.0 192.168.4.0 255.255.255.0

access-list outside_cryptomap extended permit ip 192.168.22.0 255.255.255.0 192.168.4.0 255.255.255.0

B.Regards

PLS rate any helpful post if it helps

[accudataa]

It wasn't a NAT issue. I went back through my saved configurations and I saw that I'd added the NAT exception for VPN to DC-A when I first added VPN to the configuration profile. The "no translation group" errors are actually from my client trying to do some kind of broadcast. After carefully inspecting the syslog messages, I see that I get those messages even with the correct NAT ACL.

The problem was the cryptomap. I needed to add the VPN subnet to the DC-A firewall's connection profile. In my defense, we are migrating from Watchguard Fireboxes, which (at least with our software revision) didn't allow VPN-to-VPN traffic, so this was all new to me. The firewall provider at DC-A was no help with this and we had to tell them exactly how to implement it. Since they manage to break one thing for everything they fix, I have to wait until business hours are over to have them make changes.

[cdusio]

cool !