Two ASA tunnels, only some remote peers are reachable

[doylepaul]

Hi, very strange issue here ...

Brief overview ..... I have one ASA with two tunnels. Each going to a different 3rd party Checkpoint firewall (site A, site B)

Each site has two servers (A1, A2, B1, B2)

I can only connect to A1 and B1. any connection to A2 and B2 fails.

I have defined B2 and A2 in the crypto map to be protected.

If I only have B2 or A2 in the crypto map ACL then the tunnel fails. Phase 1 does not come up. Its as if the ASA is ignoring the entries for B2 and A2.

ASA running 8.4(2).

I have also trashed the VPN and built via the wizard, same result.

Any thoughts greatly appreciated.

Regards

Paul

[Marvin Rhoads]

What does packet tracer report when selecting A2 or B2 as your destination?

[Jouni Forss]

Hi,

To my understanding the Phase1 should not be affected by the configurations you set in the Phase2 ACL defining interesting traffic.

Though it would naturally mean that your VPN negotiation would still fail.

It would seem to me that if the secondary A2 and B2 addresses dont work along with the A1 and B1 or even alone by themselves that the remote ends would have been configured incorrectly. Though it would seem wierd if this happens on 2 different connections. Unless ofcourse the same person handled the remote end configurations?

If you want we could certainly check your ASAs configurations for any problems after which you could ask the remote site management to go through the configurations.

You have also the ability to use the "packet-tracer" command to define what is happening.

The format is this

packet-tracer input tcp

Just modify the above to suite your situation. The is the ASA interface behind which your connecting host is. (Dont use ASA interface IP addresses as the source)

Can you take the above command output when you are trying to connect to A2 and B2 hosts. Please take the command output twice from each and then copy/paste the second commands output here on the forums. Why I ask you to take the output twice is because you would need the first command just to bring up the L2L VPN connection and it coudlnt go through completely. The second command output should on the other hand succeed if configurations are correct. If it doesnt go through then the problem is probably configurations between the local and remote site.

You can also use the command "show crypto ipsec sa peer " to see if the both devices of the L2L VPN Connection have been able to form the connection.

- Jouni

[doylepaul]

Thanks for your input guy's, much appreciated ...

Packet tracer ... great idea .. I will do that first thing tomorrow ...

I will also confirm sh crypto isakmp sa peer too.l

And yes the same third party engineer did configure both remote ends.

Thanks again :-)

[Julio Carvajal]

Hello Doyle,

I would like to see the No-Nat configuration, If you say the Crypto ACL is good then we need to check something else, why is not the tunnel being triggered when you try connectivity to those servers, they might not be included in the NO_NAT setup.....

As you said phase 1 does not build when you use this particular traffic only then we know there is a problem with the traffic,

Provide the NAT statement you are using, make sure you have both Addresses on the NO_NAT setup..

The packet-tracer will help but based on the information you are telling me the problem is with that ( The other thing would be a routing issue)

Anyway let us know

[doylepaul]

Hi, thanks for your response. I am not at site so cannot perfrom a packet trace yet .. However, I do have a sh run from the ASA in question on my laptop ... and I have extracted the relevant NAT statements (below). I am not using the nonat aCL. I did however tell the wizard to NAT etc. I guess it saw the existing NAT entries below and realised it didnt need to do a nonat???

nat (inside,outside) source static LocalServer LocalServer destination static A1 A1 no-proxy-arp route-lookup
nat (inside,outside) source static LocalServer LocalServer destination static A2 A2 no-proxy-arp route-lookup
nat (inside,outside) source static LocalServer LocalServer destination static B1 B1 no-proxy-arp route-lookup
nat (inside,outside) source static LocalServer LocalServer destination static B2 B2 no-proxy-arp route-lookup

nat (outside,any) source static B1 B1 destination static LocalServer LocalServer
nat (outside,any) source static B2 B2 destination static LocalServer LocalServer
nat (outside,any) source static A2 A2 destination static LocalServer LocalServer
nat (outside,any) source static A1 A1 destination static LocalServer LocalServer

There are other NAT statements for these servers but they are related to different DMZ's etc. The LocalServer is on the inside (a different subnet to the inside interface, but routing is okay)

A1&A2 are a different subnet to B1&B2.

A1's IP address is one lower than A2 and the same is true for B1&B2.

I have not tried removing the NAT statements above and adding them to the nonat ACL. I guess that is worth trying?

I will post the packet trace when I get to site.

Thanks again for your help.

Regards

Paul.

[Jouni Forss]

Hi,

In your software level you dont anymore configure the NAT0 / NONAT / NAT Exempt with ACLs

nat (inside,outside) source static LocalServer LocalServer destination static A1 A1 no-proxy-arp route-lookup

nat (inside,outside) source static LocalServer LocalServer destination static A2 A2 no-proxy-arp route-lookup

nat (inside,outside) source static LocalServer LocalServer destination static B1 B1 no-proxy-arp route-lookup

nat (inside,outside) source static LocalServer LocalServer destination static B2 B2 no-proxy-arp route-lookup

Actually the first 4 listed NAT configurations are NAT0 type configurations in a way. You have defined the local server and the remote hosts/servers object twice which means that they will keep their original IP addresses when communicating together.

The "crypto map match address " configurations ACL should match the above NAT configurations.

The other connection should have local server as source and A1 and A2 as destination

The other connection should have local server as source and B1 and B2 as destination.

To my understanding these should  not be needed

nat (outside,any) source static B1 B1 destination static LocalServer LocalServer

nat (outside,any) source static B2 B2 destination static LocalServer LocalServer

nat (outside,any) source static A2 A2 destination static LocalServer LocalServer

nat (outside,any) source static A1 A1 destination static LocalServer LocalServer

- Jouni

[doylepaul]

Thanks again guy's for your input ... please see below the packet trace output which indicates (I think) that the traffic going to A2 is not being protected? I have pasted the ACL too, which seems okay to me?

Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static LocalServer LocalServer destination static A2 A2 no-proxy-arp route-lookup
Additional Information:

Phase: 9
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

This is the relevant ACL:
access-list outside_cryptomap_3 extended permit ip object LocalServer object-group DM_INLINE_NETWORK_30

This is the object group associated with the ACL above:

object-group network DM_INLINE_NETWORK_30
network-object object A1
network-object object A2

Also I could not see any active IKEv1 SA's after the packet trace above .... but when I performed the packet trace for A1 it all worked???

Any thoughts   :-)

[Julio Carvajal]

Hello Doyle,

I do not know the rest of our friends here but I would like to see the entire configuration ( So I can analize object groups definitions, Crypto ACLs, NAT, Routing,etc)

Besides that would make the solution to appear faster

[doylepaul]

Hi, thanks for your response, I am offsite for a couple of days so can't access the ASA. I do have a sh run on my laptop which I will try and reduce down as there is a lot of other config on there too.

Kind regards

Paul.

[Jouni Forss · Accepted solution]

Hi,

If you issued the "packet-tracer" command twice and it still shows DROP in the VPN Phase it means that your local sites and remotes sites VPN paramaters dont match.

Since you say that the other hosts work on the L2L VPN Connection then we know that the VPN parameters in general are correct.

So I would have to say that the remote sites have been configured incorrectly with regards to the Crypto ACL.

Please ask them to confirm their setting. Perhaps send you screen capture of the settings or something. But it does seem that their are missing the other host on their side from the L2L VPN ACL configuration since SA isnt formed between the local server and the A2

- Jouni

[Marvin Rhoads · Accepted solution]

It is looking an awful lot like the remote site doesn't have a matching encryption policy that includes the A2 and B2 hosts.

You can do a:

debug crypto condition peer

debug crypto ipsec 7

debug crypto isakmp 7

and monitor the output of the debug in your log when introducing interesting traffic (A2-B2). If the remote end does not have a matching policy it will show up in the resultant debug log entries.

Also, ask the Checkpoint admin to verify that both pairs of servers are setup in his policy and that the policy is published. It should look something like Step 14 in this example.

[doylepaul]

Thanks Marvin, this looks great !!! I will try and get to site tomorrow to debug, but it will probably be Friday.

I have sent 'Step 14' over to the third party to confirm their settings are correct.

Thanks again to everyone for all your help and advice so far .... it is really appreciated, and I am learning :-)

Cheers

Paul ....

[doylepaul]

Thanks to everyone who helped me with this issue, I really appreciate your help.

It turns out that the 3rd party where running Checkpoint and acutally did not have their configuration correct!!

Thanks again