VPN between ASA and Netbox

[augnevenok]

Hi,

I have to connect a new office to the company network. The new office uses ASA whereas all other sites use Netbox firewalls. I have configured LAN-to-LAN VPNs between ASA and several remote sites. Local IT of the company configured Netboxes at remote locations. Non of the VPNs is working properly. Some of them do not come up at all, the Netbox guys don't see any VPN-related activity on their boxes. One VPN is always stucks on IKE stage and another one comes up and drops shortly.

I built a test VPN between production ASA and a test PIX and it is rock stable. We also checked and double checked all IKE and IPSec settings (which are identical for tunnels) with the other party and everything seems to be fine.

What would be the best aproach to troubleshoot the issue further? I have either to get it work or prove that there is a compatibility issue.

Are there options that would allow for VPN fine-tuning?

If I enable debugging what clues should I look for in the debug output?

Thank you very much.

Regards,

Alex

[5220]

Hi Alex,

So the problem is IKE 1.

Check again if all settings are the same (lifetime, hash, DH group, authentication method, encryption).

Check to have "isakmp identity address" and "isakmp enable " commands.

Make sure the group is a lan-to-lan.

If using certificates, make sure CRL checking is disabled.

"sysopt permit ipsec" must be present on ASA and the Netbox must allow UDP 500, ESP (IP 50), ICMP (for MTU discovery) toards ASA public IP.

Commands for troubleshoot:

debug crypto isakmp

It will specify the reason for not esablishing.

Please rate if this helepd.

Post the debug if not.

Regards,

Daniel

[augnevenok]

Hi Daniel,

The box I am trying to connect ASA to is actually Gnat Box device.

isakmp identity address, isakmp enable, sysopt permit ipsec are present in ASA config.

group is a lan-t0-lan, pre-share key is used.

Gnat Box allows UDP 500, ESP, I am not sure about ICMP, however external interface of Gnat Box is not pingable.

I couldn't get a stable test either positive or negative. Sometimes VPN comes up for 2-10 min, 20min max and drops off. Then it just doesn't come up and I cannot see any isakmp or ipsec debug output even with debug level 255. ISP connectivity is not an issue.

Could this unstable behaviour be caused by blocked ICMP on the Gnat box?

If nothing comes up when debug crypto isakmp is enabled what else could I possibly check?

How could I check that traffic is coming from Gnat Box to ASA at all?

Thank you very much.

Regards,

Alex

[5220]

Hi Alex,

The console will display the debug infromation.

Can you check the lifetime to be the same on both machines (IKE lifetime and IPSEC lifeftime).

Please rate if this helped.

Regards,

Daniel

[augnevenok]

Hi Daniel,

Finally managed to get some stable tunnels but still with issues.

Presently we have the following setup.

GNat Box and ASA connected with lan-to-lan VPN. Network behind ASA is 10.32.1.0/24, GNat has several private networks behind:

10.1.1.0 /24 - the main site that routes traffic to

10.3.1.0 /24

10.31.1.0 /24

All these networks are added to a cryptomap on ASA:

access-list outside_20_cryptomap extended permit ip 10.32.1.0 10.1.1.0

access-list outside_20_cryptomap extended permit ip 10.32.1.0 10.3.1.0

access-list outside_20_cryptomap extended permit ip 10.32.1.0 10.31.1.0

Now when tunnel is going from 10.1.1.0 to 10.32.1.0 or vice versa everything works fine, the tunnel comes up and it is stable.

If at the same time the tunnel between 10.32.1.0 and 10.3.1.0 comes up then 10.32.1.0 becomes inaccessable from the main lan 10.1.1.0, however ASA shows 1 isakmp and 2 ipsec tunnels.

We have tried to initiate a tunnel sending traffic from 10.31.1.0 and 10.3.1.0 to 10.32.1.0 and nothing came up however I captured some debug output, please see attached.

I can see that the reason for not establishing the tunnel is:

Group = 210.9.131.46, IP = 210.9.131.46, All IPSec SA proposals found unacceptable!

210.9.131.46 being public IP of GNat Box.

If you could shed some light on this I would greatly appreciate.

I suspect misconfiguration on the GNat Box and it is out of our control.

Thank you.

Regards,

Alex

[5220]

Hi,

Yes, i suspect a missconfiguration on the GNat Box.

As well, the lifetimes are not syncronized:

Jan 17 19:08:42 [IKEv1 DEBUG]: Group = 210.9.131.46, IP = 210.9.131.46, Starting P1 rekey timer: 4050 seconds.

Jan 17 19:08:42 [IKEv1]: Group = 210.9.131.46, IP = 210.9.131.46, QM IsRekeyed old sa not found by addr

Regards,

Daniel

[augnevenok]

Hi Daniel,

We checked the lifetime settings and they are identical on the ASA and GNat.

How can you see that they are not syncronised?

Is it possible to see which particular lifetime is out of sync?

Thank you.

Regards,

Alex

[scottosan]

Are all of the crytpo interfaces on these devices configured with public address, are are some ove them being NAT's to public address?

[augnevenok]

Yes, there is PAT configured on the public interface of the ASA box for general Internet access.

At the moment there can be only one tunnel between ASA and Gnat Box. As soon as the second tunnel to a different subnet behind Gnat Box comes up the first tunnel stops passing traffic though "show crypto ipsec sa" shows the tunnel is still present.

Could there be a NAT-related issue?

Thank you.

Regards,

Alex

[scottosan]

This sounds like the crypto access-list do no match. For example if you had 2 networks included in your access-list example:

Peer#1-

permit ip 10.1.1.0 255.255.255.0 192.168.1.0

permit ip 10.1.2.0 255.255.255.0 192.168.1.0

Peer#2-

permit ip 192.168.1.0 255.255.255.0 10.1.0.0 255.255.0.0

In this case peer 1 has a more granular match while peer 2 has a less granular match. Peer 1 generates traffic from the 10.1.1.0/24 network bring up the tunnel with a matching SPI. Now peer 1 starts sending traffic from the 10.1.2.0/24 which needs to create another SA, but it still matches the SA on Peer 2. The SA's must match exactly because the SA's are 1 to 1

[augnevenok]

Thank you for the answer.

Could there be a problem if I use Network Objects in ACL?

So instead of using individual ACL entries:

permit ip 10.1.1.0 255.255.255.0 192.168.1.0

permit ip 10.1.2.0 255.255.255.0 192.168.1.0

permit ip 10.1.3.0 255.255.255.0 192.168.1.0

I define an object group AllNetworks which includes all the networks:

object-group network AllNetworks

network-object 10.1.1.0 255.255.255.0

network-object 10.2.1.0 255.255.255.0

network-object 10.3.1.0 255.255.255.0

and then define ACL:

permit ip AllNetworks 192.168.1.0

I think there should not be any difference.

Thank you.