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.
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.
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.
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
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 >
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).
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.
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.
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.
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 >
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.
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 >
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...
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2004 Firewall] >> VPN >> Nortel Contivity Client 
Nortel Contivity Client - 
. 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!). 
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