• RSS
  • Twitter
  • FaceBook

Welcome to ISAserver.org

Forums | Register | Login | My Profile | Inbox | RSS RSS icon | My Subscription | My Forums | Address Book | Member List | Search | FAQ | Ticket List | Log Out

Nortel Contivity Client

Users viewing this topic: none

Logged in as: Guest
  Printable Version
All Forums >> [ISA Server 2004 Firewall] >> VPN >> Nortel Contivity Client Page: [1]
Login
Message << Older Topic   Newer Topic >>
Nortel Contivity Client - 31.Mar.2006 11:46:09 PM   
tharler

 

Posts: 1
Joined: 31.Mar.2006
Status: offline
I am running ISA Server 2004.  We have a client network that we need to connect to using the Nortel Contivity client.

I have created an access rule to allow IKE Client, IPSec ESP, and IPSec NAt-T Client protocols access to the external network from All Protected Networks.

I have disabled the Firewall client.

When I try to connect, I get the message Login Failue die to:  Remote host not responding.  If I move the machine to the other side of the firewall, I can get connected without issues.

What else do I need to do in order to allow this access through the ISA Server?

I have tried publishing Server rules for the above protocols as well.

Thanks,
-Tyke.
Post #: 1
RE: Nortel Contivity Client - 1.Apr.2006 12:15:01 AM   
ClintD

 

Posts: 1848
Joined: 26.Jan.2001
From: Keller, TX
Status: offline
At work, we use an older version of the Nortel client (unsure of the version) and when I went home to connect, I had to create a "IPSEC NAT-T Client 10001" using UDP 10001 for the destination port - after this, I was able to connect. I've seen other threads where the later versions use the NAT-T Client built in protocol.

You might check the Monitoring\Logging section - add an entry for 'Client IP Equals %ClientIP%' and see what gets logged when the client tries to connect - like Unknown Protocol or other.

(in reply to tharler)
Post #: 2
RE: Nortel Contivity Client - 1.Apr.2006 3:07:14 PM   
spouseele

 

Posts: 12830
Joined: 1.Jun.2001
From: Belgium
Status: offline
Hi Tyke,

check out http://www.isaserver.org/articles/IPSec_Passthrough.html.

HTH,
Stefaan

(in reply to ClintD)
Post #: 3
RE: Nortel Contivity Client - 5.Apr.2006 3:57:42 PM   
ahmedsaeed

 

Posts: 4
Joined: 7.Nov.2005
From: Karachi, Pakistan
Status: offline
Hi:

I had too the same senario. I require to connect to a VPN site through Contivity VPN Client software ver. 5_01.100. But I am unable to got through. I am using ISA 2004 & create 2 access rules to allowing built-in IKE Client and IPSec NAT-T Server protocols.

Can anyone plz. tell me how to create this rule

Thanks

(in reply to tharler)
Post #: 4
RE: Nortel Contivity Client - 20.Apr.2006 1:40:46 AM   
baggyg

 

Posts: 11
Joined: 6.Sep.2004
Status: offline
Hi All,

I am having the same problem.  I have two options for getting onto the company's VPN.  I can dial up, then use the Contivity client to connect.  That seems to work fine.

The other option is to connect from another site through an ISA 2004 Firewall using ADSL.  This option does not work so well.  Without changing the configuration of ISA, I have been able to connect twice out of 50 odd tries.

I have captured the packets using Ethereal:

Dial-up: (note that the ISAKMP traffic is showing port 500 on source and destination)

Laptop IP = 192.168.x.x internal LAN IP
Company IP = External interface of the company firewall

Source               Dest                Protocol   Info
{laptop IP}         {company IP}   ISAKMP   Aggressive
{company IP}     {laptop IP}       ISAKMP   Aggressive
{laptop IP}         {company IP}   ISAKMP   Aggressive
{company IP}      {laptop IP}      ISAKMP   Transaction (Config Mode)
{laptop IP}         {company IP}   ISAKMP   Transaction (Config Mode)
{company IP}      {laptop IP}      ISAKMP   Transaction (Config Mode)
{company IP}      {laptop IP}      ISAKMP   Transaction (Config Mode)
{laptop IP}         {company IP}   ISAKMP   Transaction (Config Mode)
{company IP}      {laptop IP}      ISAKMP   Transaction (Quick Mode)
{laptop IP}         {company IP}   ISAKMP   Transaction (Quick Mode)
{company IP}      {laptop IP}      ISAKMP   Transaction (Quick Mode)
{laptop IP}         {company IP}   ESP        ESP (SPI=...)
.
.
At this point the tunnel is established and the world is a happy place.  The ESP traffic is going both ways and there is no further ISAKMP traffic for as long as I was capturing.

ADSL: (note that the ISAKMP traffic is showing port 500 on source and destination)

Laptop IP = DHCP IP provided by ISP
Company IP = External interface of the company firewall

Source               Dest                Protocol   Info
{laptop IP}         {company IP}   ISAKMP   Aggressive
{company IP}     {laptop IP}       ISAKMP   Aggressive
{laptop IP}         {company IP}   ISAKMP   Aggressive
{company IP}      {laptop IP}      ISAKMP   Transaction (Config Mode)
{laptop IP}         {company IP}   ISAKMP   Transaction (Config Mode)
{company IP}      {laptop IP}      ISAKMP   Transaction (Config Mode)
{company IP}      {laptop IP}      ISAKMP   Transaction (Config Mode)
{laptop IP}         {company IP}   ISAKMP   Transaction (Config Mode)
{company IP}      {laptop IP}      ISAKMP   Transaction (Quick Mode)
{laptop IP}         {company IP}   ISAKMP   Transaction (Quick Mode)
{company IP}      {laptop IP}      ISAKMP   Transaction (Quick Mode)
{laptop IP}         {company IP}   ESP        ESP (SPI=...)
{laptop IP}         {company IP}   ESP        ESP (SPI=...)
{laptop IP}         {company IP}   ESP        ESP (SPI=...)
{laptop IP}         {company IP}   ESP        ESP (SPI=...)
.
.
.
{laptop IP}         {company IP}    ISAKMP  Informational
{company IP}      {laptop IP}       ISAKMP  Informational
{laptop IP}         {company IP}    ICMP      Destination unreachable (Port unreachable)
{company IP}      {laptop IP}       ISAKMP  Informational
{laptop IP}         {company IP}    ICMP      Destination unreachable (Port unreachable)

At this point I get the 'lost connection' message and the world is not a great place.

Hope you can help. Dialup is killing me slowly.

Cheers,
Micah

-edit-

I forgot to mention that in the two times that the VPN connected through the firewall, there is an additional protocol that showed up on the ISA monitor (before I decided to use Ethereal).  It was SecureID.  This protocol does not show up when the connection does not work.

Additionally, the ISA monitor is not showing any blocked traffic, and the firewall client on the laptop is disabled.

-edit 2-

Today I read that there may be some problems with the current version of the Intel wireless driver dropping connections.  However I tried to connect to the VPN through the LAN and still no joy.  I did, however connect successfully from another network that does not have an ISA server between me and the VPN.

< Message edited by baggyg -- 20.Apr.2006 2:10:47 PM >

(in reply to spouseele)
Post #: 5
RE: Nortel Contivity Client - 20.Apr.2006 9:35:08 PM   
spouseele

 

Posts: 12830
Joined: 1.Jun.2001
From: Belgium
Status: offline
Hey guys,

make sure the client is behaving as a SecureNAT client only. Next, take a Netmon or Ethereal capture of the IKE negotiation to find out how far the negotiation goes. If the VPN client has a good logging, check it out too.

With all that info you should be able to determine if it is a problem on the client side (including the ISA server) or at the remote VPN gateway side (or along the path).

HTH,
Stefaan

(in reply to baggyg)
Post #: 6
RE: Nortel Contivity Client - 21.Apr.2006 5:00:37 AM   
baggyg

 

Posts: 11
Joined: 6.Sep.2004
Status: offline
Hi Spousee,

How do i make sure my client is acting as a SecureNAT?  I thought that if it has an IP address and you can do other things (like browse) through the firewall, the by defaut, it is a SecureNAT client.

As far as the negotiation goes...  It would appear that the negotiation of the tunnel is successful, but no data can pass through the tunnel.

Also there are these 'ISAKMP  Informational' packets that turn up only when I have these unseccessful attempts (i.e. they aren't generated when I connected via dial-up (always successfully).

I am going to got to a local wireless hotspot and see if I can connect without an ISA firewall in the way.  That will at least prove that the client laptop is not at fault.

Cheers,
Micah

(in reply to spouseele)
Post #: 7
RE: Nortel Contivity Client - 21.Apr.2006 5:26:46 AM   
baggyg

 

Posts: 11
Joined: 6.Sep.2004
Status: offline
I just went down to my local hotspot and, after paying with my first borne child, was able to successfully connect to my company VPN.  I took a capture again with Ethereal and it looked exactly like the connection attempt using dial-up (shown above).  So I am now very confident that the issue is with the ISA firewall.

Micah

(in reply to tharler)
Post #: 8
RE: Nortel Contivity Client - 21.Apr.2006 10:54:39 PM   
spouseele

 

Posts: 12830
Joined: 1.Jun.2001
From: Belgium
Status: offline
Hi Micah,

that proves nothing because the environment is different. Only a detailed analyses of the IKE negotiation can show what is really going on. All the rest is just guesswork. So, I suggest you reread again my previous post, my article and related topic to better understand how NAT-T is negotiated and how the ISA client types should be configured.

HTH,
Stefaan

(in reply to baggyg)
Post #: 9
RE: Nortel Contivity Client - 22.Apr.2006 4:16:17 AM   
baggyg

 

Posts: 11
Joined: 6.Sep.2004
Status: offline
Thanks Spousee,

I did read through your article again.  It must be noted that I am not what you would call a network guru.  However, I have tried setting direct access for the VPN hosts IP addresses, and have tried disabling the Firewall client when trying the VPN access.

The laptop's IP is listed as SecureNAT, so that's okay.

I have had a look at the payloads of the ISAKMP packets.  The first two packets are not encrypted and, as you would expect, exchanging proposals.  The rest of the packets are all encryped which leads me to believe the tunnel is being established.

I think the problem is that the ESP encapsulated traffic is being blocked.  That's the bit I don't understand:  If the tunnel is being established between the laptop and the VPN host, why can't the ESP traffic get back from the VPN host to the laptop?

Would it be safe to assume that since I am not seeing any NAT-T traffic in the log, that would mean that NAT-T is not enabled on the Contivity VPN Host?  I suspect if they were using a non-standard port it would show up on the ISA logs as blocked traffic.

Is there any way to trace where the ESP traffic is going astray on the way back to my laptop?

Thanks for the help...

Micah

-edit-

I decided to have a look at what is going on outside the firewall to try and answer my own question about what is happening to the ESP packets.  There are ESP packets comming back to the external interface of the firewall from the VPN Host.  However the test is grey on white background (not sure what that means in Ethereal) while ESP traffic from the external interface of the firewall TO the VPN host is normal black on white text.  If I check the internal interface of the firewall I don't see any of the traffic returing from the VPN host.

So it would appear that the ESP traffic is comming back but ISA doesn't know what to do with it so the packets seem to be just dropped.?.

< Message edited by baggyg -- 22.Apr.2006 4:50:50 AM >

(in reply to spouseele)
Post #: 10
RE: Nortel Contivity Client - 22.Apr.2006 12:45:24 PM   
spouseele

 

Posts: 12830
Joined: 1.Jun.2001
From: Belgium
Status: offline
Hi Micah,

you may post here the URL where I can download the Ethereal file for further analyses. The trace should have been taken on the ISA external interface or outside of the ISA server.

quote:

It is important that the presence of a NAPT device along the path is detected in the very beginning of the IKE negotiation process. This is done in two steps:

  • The first step is to detect that the IPSec peers are capable of performing NAT-T. Each IPSec NAT-T capable peer must add a new Vendor-ID (VID) payload to the first IKE message (Security Association), containing a well-known hash value. Only if both the initiator and the responder have sent and received that specific VID payload, the NAT Traversal probe will continue. In all other cases, normal IPSec negotiations and IPSec protection is performed.

  • The second step is to add one or more new NAT-Discovery (NAT-D) payloads to the second IKE message (Key Exchange). Each NAT-D payload contains a hash value of an IP address and UDP port number. During Main Mode negotiation each IPSec peer sends two NAT-Discovery payloads, one for the destination IP address and UDP port number (default 500), and one for the source IP address and port number (default 500). By comparing the hash of the real source IP address and UDP port number of the received IKE message with those sent within the NAT-D payload, each recipient can determine if there is a NAPT device along the path and which peer is located behind a NAPT device. If at least one NAPT is detected, then the IPSec peers automatically use IPSec NAT-T to send IPSec-protected traffic across a NAPT device. In all other cases, normal IPSec negotiations and IPSec protection is performed.
    As soon as the use of IPSec NAT Traversal is negotiated, the IKE traffic will move to a new UDP port number, the IKE Header will change to a Floated IKE Header format and the peer behind a NAPT device will start sending NAT-keepalive packets. Because these are three very important changes, let us examine them in more detail.


  • So, in the first and second IKE packet you should find the NAT-T Vendor-ID. Ethereal decodes them very well as
    quote:

        Vendor ID payload
           Next payload: Vendor ID (13)
           Length: 20
           Vendor ID: draft-ietf-ipsec-nat-t-ike-02


    The third and forth IKE packet should contain the NAT-D payloads. Ethereal decodes them very well as
    quote:

        NAT-D (draft-ietf-ipsec-nat-t-ike-01 to 03) payload
           Next payload: NAT-D (draft-ietf-ipsec-nat-t-ike-01 to 03) (130)
           Length: 24
           Hash of address and port: 46E0C8AA04F6114FDF4B938A2367310EED0BADA2
       NAT-D (draft-ietf-ipsec-nat-t-ike-01 to 03) payload
           Next payload: NONE (0)
           Length: 24
           Hash of address and port: 32C71BC7126BD60E33202597AFFF209D033BD022


    Once, the NAT-T is agreed upon you should see the IKE port change to UDP 4500 or sometimes to UDP 10000 or 100001 depending on which version of the NAT-T draft the vendor supports. Also, in any case you shouldn't see pure ESP (IP protocol 50) packets. They should all been encapsulated in UDP packets on the NAT-T port. If not, then clearly no NAT-T is negotiated.

    HTH,
    Stefaan

    (in reply to baggyg)
    Post #: 11
    RE: Nortel Contivity Client - 23.Apr.2006 2:34:26 AM   
    baggyg

     

    Posts: 11
    Joined: 6.Sep.2004
    Status: offline
    Hi Stefaan,

    Okay.  That makes sense.  I think I understand now.

    There is no refference to nat-t in any of the packets.

    In the first packet there are two Vender ID sections:
    -This first is

    quote:


    Vendor ID payload
      Next payload: Key Exchange Payload (4)
      Length: 30
      Vendor ID: unknown vendor ID: 0x4E61542D53497BC564C0DD558F3F....


    The next section is the Key Echange payload. The Nonce and Identification payloads.

    Then there is the last payload which is:

    quote:


    Vendor ID payload
       Next payload: NONE (0)
       Length: 12
       Vendor ID: unknown vendor ID: 0x424E454300000004


    The second packet only has one refference to Vendor ID:

    quote:


    Vendor ID payload
       Next payload: NONE (0)
       Length: 14
       Vendor ID: unknown vendor ID: 0x4E61542D53492D4E5053


    So I'm guessing that means the host does not have NAT-T enabled!  The wierd thing is that it has worked twice???

    Anyway... I will try to get on to them on Monday and see what they say.  the Remote Network Access guys have a few thousand people connecting into this, so I'm nit too sure how they will feel about making changes.  That said... with so many people connecting, I'd be surprised if this has not been raised as an issue before (maybe the person raising the issue didn't have the fine help from you to understand what the problem is!).

    Thanks heaps for the help!

    Cheers,

    Micah

    < Message edited by baggyg -- 24.Apr.2006 2:04:29 AM >

    (in reply to spouseele)
    Post #: 12
    RE: Nortel Contivity Client - 23.Apr.2006 12:25:22 PM   
    spouseele

     

    Posts: 12830
    Joined: 1.Jun.2001
    From: Belgium
    Status: offline
    Hi Micah,

    yep, it sounds that the NAT-T capability is not announced in the first place! I know for sure it is possible to pass through the Nortel Contivity client if the client and VPN gateway are running the correct version and are properly configured.
    quote:

    5.5. Nortel Contivity
     
    You can pass the Nortel Extranet Access Client software through ISA server if the Nortel Contivity switch is running with one of the newest firmware version 04_05.024 or later and you use the newest client software version 4.65 or later. This is what you need to do at the Contivity Switch:
    • On the configuration page's left side, click on "Services", then "IPSEC". Toward the middle of page is the setting "NAT Traversal". Check to have it enabled and set it on UDP port 4500 (strongly recommended).
    • Once the above step is done, go to "Profiles", then "Groups". Under a designated group where you want NAT Traversal enabled, click on "Edit." Under the section "IPSEC", click on "Configure." At the very bottom of the page, make sure "Auto-Detect NAT" is selected and keep the "NAT Keepalive" setting at 18 seconds.

    If the VPN administrator have set the NAT Traversal port on something else than UDP port 4500 (i.e. UDP port 10001), you need to adopt the IPSec NAT-T protocol definition accordingly or create a new one and add it to the IPSec Passthrough protocol rule.

    Of course, for more recent versions of the client software and/or the VPN gateway, the exact configuration steps can be different. Good luck and let us know how it goes...

    HTH,
    Stefaan

    (in reply to baggyg)
    Post #: 13
    RE: Nortel Contivity Client - 24.Apr.2006 2:12:26 AM   
    baggyg

     

    Posts: 11
    Joined: 6.Sep.2004
    Status: offline
    Hi Stefaan,

    I got an email back from our gateway guys saying that the standard set-up is as follows:

    quote:


    If the box is behind a firewall make sure that the following ports are open:
    UDP 500 (IKE)
    UDP 5500 (NAT Traversal for IPSec)
    IP Protocol 50 (ESP)


    The standard is UDP 5500 for NAT-T but I would have thought that I still would have seen NAT-T data in the packets???

    I'll try to reconfigure to use UDP 5500 for NAT-T and let you know what happens...

    Micah

    (in reply to spouseele)
    Post #: 14
    RE: Nortel Contivity Client - 30.Apr.2006 5:37:05 PM   
    spouseele

     

    Posts: 12830
    Joined: 1.Jun.2001
    From: Belgium
    Status: offline
    Hi Micah,

    ip protocol 50 (ESP) won't help in a NAT environment!

    Why doesn't the VPN admin use the standard NAT-T UDP Port 4500 as defined in IETF RFC 3947/3948?

    HTH,
    Stefaan

    (in reply to baggyg)
    Post #: 15

    Page:   [1] << Older Topic    Newer Topic >>
    All Forums >> [ISA Server 2004 Firewall] >> VPN >> Nortel Contivity Client Page: [1]
    Jump to:

    New Messages No New Messages
    Hot Topic w/ New Messages Hot Topic w/o New Messages
    Locked w/ New Messages Locked w/o New Messages
     Post New Thread
     Reply to Message
     Post New Poll
     Submit Vote
     Delete My Own Post
     Delete My Own Thread
     Rate Posts