Has anyone had an issue where a tunnel is configured with multiple proxy-id's for a policy-based peer, but a working security association is formed for only one of them?
I have a number of ASA 5505s that need to connect to my new Palo Altos from remote locations, where they mostly get dynamic, NATed, non-routable IPs. After more faffing about than expected, I've reached the point where I have two nice, green dots in Network/IPSec Tunnels. Turns out, though, that that's kind of misleading.
Each tunnel has three proxy-ids, one for each of the big blocks of non-routable space. They look like this:
The IKE security association gets set up without any issue.
The IPSec SA for selector pair c is also forming just fine, and passing traffic. I think it couldn't be doing that unless most of the configuration was OK?
As far as I can see, b never tries to negotiate at all.
A is the oddest case. I see a security association on both the ASA and the Palo Alto. The SPIs match. All the parameters match. But traffic doesn't move in either direction. On both devices I can see the count of encap packets increasing (so routing and blocking must be OK, traffic's entering the tunnel), but decap packets never moves from zero on either side.
I thought I'd seen most IPSec failure modes, but I've never seen anything like that.
I'd thought I might be triggering some weirdness with the overlapping address space for the remote /27 and 172.16/12, even though that's the connection that worked. Wasn't sure it could be the issue since so many folks use 0.0.0.0/0, but I tried removing it anyhow. It didn't make any difference to the behavior of the other SAs.
I'm utterly at a loss with this one. Ticket is open with support, but it would sure make my day if someone recognizes these symptoms.
Here are the selector configurations from both devices. Maybe (hopefully) I'm just doing something dumb?
ASA: object network 10dot subnet 10.0.0.0 255.0.0.0 object network 192dot subnet 192.168.0.0 255.255.0.0 object network 172dot subnet 172.16.0.0 255.240.0.0 ...
object-group network InternalNets
network-object object 10dot
network-object object 192dot
network-object object 172dot
... access-list outside_cryptomap_1 extended permit ip 172.19.29.192 255.255.255.224 object-group InternalNets ... crypto map outside_map 2 match address outside_cryptomap_1 ... PA: set network tunnel ipsec Prop_IPsec_999 auto-key proxy-id a protocol any set network tunnel ipsec Prop_IPsec_999 auto-key proxy-id a local 10.0.0.0/8 set network tunnel ipsec Prop_IPsec_999 auto-key proxy-id a remote 172.19.29.192/27 set network tunnel ipsec Prop_IPsec_999 auto-key proxy-id b protocol any set network tunnel ipsec Prop_IPsec_999 auto-key proxy-id b local 192.168.0.0/16 set network tunnel ipsec Prop_IPsec_999 auto-key proxy-id b remote 172.19.29.192/27 set network tunnel ipsec Prop_IPsec_999 auto-key proxy-id a protocol any set network tunnel ipsec Prop_IPsec_999 auto-key proxy-id c local 172.16.0.0/12 set network tunnel ipsec Prop_IPsec_999 auto-key proxy-id c remote 172.19.29.192/27
I have a couple sites with multiple networks being tunneled via IPSEC. Only the first network that is accessed is working. It will not negotiate the second Proxy ID. I tried following directions from the link below, but still only the first network that I ping is accessible . It is an IPSEC tunnel between a PA running 9.0 and an ASA running 9.1.
Do you know how to resolve this issue?
Thank you for any direction you are able to provide
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!