Nortel vpn client behind pix

[hbaski]

Hi,

I have Nortel vpn client connecting to nortel conntivity box via my cisco pix firewall .

nortelvpnclient-----lan--insidepix---router----nortelconntivity.

Iam unable to establish the vpn tunnel with conntivity and i have opened up all the ports (ip any any) still the problem is same.

when iam tried with another firewall 506e iam able to establish the tunnel with nortel conntivity .

the config in both the device are same and all the connections are established with 506e firewall whereas in 535 new vpn connections are not established.

Adivice me on next level troubleshooting.

Thanks

S.H

[ebreniz]

Thare could be many things that can go wrong. First check the routing part. Are you able to ping and reach these devices without the tunnel. Next would be to check if the PIX is configured correctly. Make sure you have appropriate nat, global, static and access-list commands to allow the required traffic to pass through. Then verify your IPSec configuration.

[skhan]

Where you able to resolve this issue. Did you have to do a one to one NAT.

Would appreciate your answer

[saquib.mkhan]

Sorry, could you please send me an email on khanss@shaw.ca

[Vikas Saxena]

Hello,

Really, there could be alot of things which can go wrong.

Lets check the obvious first:

Can you ping the contivity box?

I am assuming you are using PAT.

How many clients are there behind the PIX which needs to connect to the contivity?

If there is only one client

fixup protocol esp-ike will do the trick.

For more then one client, Contivity must understand and let you configure NAT-Traversal.

If NAT-T is open on the contivity you need to open UDP 500-500 and UDP any-4500 in the PIX and remove fixup protocol esp-ike.

Vikas

[saquib.mkhan]

Hi Thanks,

Yes, I can ping the contivity box. I am using PAT on the Pix firewall. There may be more then one client connecting from behind the inx.

for NAT-Traversal, contivity has to be supporting on enabled as well. I will need to confirm this as this is not within our domain.

When you say open UDP 500-500, you mean in and out ?

When you say UDP any --> 4500, you mean out from the firewall ?

What if NAT-T is not open ?

[Vikas Saxena]

Hello,

If there are more then one client then you definetly need NAT-T on the contivity box. In Cisco it is controlled by gateway I am not sure where in Contivity you need to enable it.

When I say UDP500-500 I mean source and destination 500.

When I say UDP any - 4500 I mean source any and destination any.

Why do we require NAT T?

If there is no NAT-T then suppose the client has a dedicated global IP address how will the encapsulation look like when it will leave the client (PC), it will be TCP->IP->ESP->IP. Now suppose the client is behind a PAT device then because it is tunnel mode (every client use tunnel mode they can not use Transport mode) the PAT device infront of the client PC will not be able to make a translation because ESP is port 0 always (it does not have any ports) the packet will be dropped.

How can this be prevented?

We can traverse the NAT by encapsulating the entire packet into a UDP packet (UDP because it is fast TCP can also be used (undefined by RFC)).

If the NAT-T is enabled then the packet which left the PC will look like

TCP->IP->ESP->UDP->IP now the FW in front of the client will have something to create a translation on becuase UDP has ports. And, the destination port is always going to be 4500 (defined by RFC). Because the source port is in control of the intermediate FW it can be random higher no. port.

NAT-T also has features like automatic NAT-D (detection) and NAT keepalives so that the FW should not timeout the translation in case the VPN tunnel is idle.

Hope this info will help.

Vikas

[saquib.mkhan]

Thanks. Will check it out. I do not have a problem with a vpn concentrator when trying to vpn through the firewall, but I have enabled NAT-T. The Nortel stuff is out of my reach, but will ask the question. I had opened all the necessary ports both udp 500 and 4500, but was no go.

For turning on fixup, then there would be an issue with site to site tunnelling which may be created on this pix in the future.

The other option would be one to one nat.