VPN PIX to Contivity problem

[ramiro]

I have a vpn between a Nortel Contivity 1700 and a Cisco PIX Firewall 525. The VPN rises without problems, but the connectivity of the application across this one, is established only in a direction, that is to say, there is not bidirectional connectivity.

Contivity to PIX, there is connectivity of the application.

PIX to Contivity, there is not connectivity of the application.

[rjwalani]

Hi,

A couple of things to verify

1. Check to make sure that the vpn configuration on the Contivity box matches the PIX.

2. When you say that there is no connectivity of the application from the PIX to Contivity, are you not seeing any packets get encrypted on the PIX end. Are you seeing only decrypts on the PIX?

You could verify this using the command

show crypto ipsec sa

3. Try pinging through the tunnel and see if packets are getting encrypted and decrypted.

Thanks

Ranjana

[ddavis]

Hi,

I have similar problems with VPN-connectivity between a Cisco PIX 515e and a remote Nortel Contivity (Don't know the model number).

In addition, our VPN tunnel often disappears for no apparent reason. The interim solution has been to request that our partner reset their Nortel Contivity's VPN tunnel, and connectivity is mysteriously resumed immediately after.

One thing to check is that the ISAKMP lifetime values are identical on both ends. In our case it's set to "28800" or 8 hours.

I've heard of some IPSEC/VPN incompatibilities between Nortel and Cisco, but nothing that could explain sporadic tunnel losses. If anyone has similar experiences to share, please do.

Thanks,

Dean Davis, MCSE,MCDBA,CCNA,CNA,N+,Linux+

[l.mourits · Accepted solution]

Sound to me that you forgot to put in a nat (inside) 0 on the PIX for the traffic that has to be encrypted. Be aware of the order of operation within the PIX. First routing and translation takes place and later on encryption (search for "order of operation" on CCO and you will find documents about this).

But why am I saying this?

Well, let's say your internal net is 10.0.0.0/8 and you have the following config:

nat (inside) 1 10.0.0.0 255.0.0.0

global (outside)1 interface

Then you have a crypto map configured and within the crypto map the command "match address" points to access-list 101. If the server which you are trying to reach via the VPN has IP-address 192.168.1.1 (it's just an example) the access-list 101 would look like:

access-list 101 permit 10.0.0.0 255.0.0.0 host 192.168.1.1

What would happen if you just configure it this way. Well, obvious, your tunnel is configured correctly, cause you are receiving traffic from the other peer. But the problem lies at your site. Looking at the example: traffic that is received at the inside interface is going to be translated first due to the nat and global statements, so, your source adresses are translated to your interfaces address. Then this translated traffic hits access-list 101 to see if this traffic has to be encrypted or not. The PIX sees the traffic with source address of your interface and destination 192.168.1.1 and this does NOT match access-list 101 so the PIX does not encrypt the traffic, but just routes them to the outside interface (assuming that routing is configured correctly)

Traffic that comes in from the VPN is first put into the crypto engine, where is is decrypted en de-capsulated, then it is send out to the inside interfaces.

If this is the case then the solution to it is very simple. Just put in the following:

nat (inside) 0 access-list 101

Note1: the access-list bound to nat (inside) 0 has to be the same as the one that defines your VPN traffic

Note2: if you are allready using a nat (inside) 0 command for other reasons then this particular one, then you would have to change this existing access-list ofcourse.

Hope this helps. In case more help is needed, you could always mail me if you want. You could also post your complete config (remove passwords first) and we could have a look at it.

Kind Regards,

Leo

[egaytan]

Actually I have the same problem and a ticket opened with the TAC. The enginner assigned toll me that Nortel Contivity 1700 has two types of mode Main and Agressive. So I should be sure the mode that is configured on Nortel is Main and not Agressive. As Pix will only respond to Main mode for Negotiating. The PIX can respond to Aggressive mode for negotiating but it cannot initiate negotiation using aggressive mode.

I hope that this can help you

Ernesto

[bcturner]

About 6 months ago I ran into similar problems trying to connect from a Pix 515E to a customer's Nortel Contivity. The customer called Nortel support who advised to change the Pix default Isakmp identity from Hostname to IP address. The Contivity cannot use hostname for IKE authentication, only IP address. As soon as I made this change the customer was able to bring the tunnel up and traffic was able to flow. The command is "isakmp identity address".

[egaytan]

I have configured that command. If so, should I use the command "isakmp key ******** address x.x.x.x netmask y.y.y.y" ?????

[bcturner]

The "isakmp key ***** address x.x.x.x netmaks y.y.y.y" command is what I'm using. Once I entered the "isakmp identity address" command, I was able to bring the tunnel up.

As a note, we also needed to configure this command in order to terminate tunnels from the Pix to a Nokia device.

[vanagon2tdi]

I am experiencing a similar problem with a 1710, and the Nortel tech told me to make sure I am using IP and not hostname. Currently I have:

"crypto isakmp key test address 209.xxx.xx.xx" for my isakmp line. On the 1710 is there another line similar to "isakmp identity address"? Thanks for your time!

Dave