Welcome to ISAserver.org

RE: How to pass IPSec traffic through ISA Server

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [ISA Server 2000 Firewall] >> VPN >> RE: How to pass IPSec traffic through ISA Server

Page: << < prev 3 4 5 [6] 7 next > >>

Message

<< Older Topic Newer Topic >>

RE: How to pass IPSec traffic through ISA Server - 13.Apr.2006 1:09:31 AM

itsuncoast

Posts: 7
Joined: 17.Mar.2006
Status: offline

Thankyou for the advice Stefaan. I am still to hear back from the Cisco Admin but I visited the site and checked the client log. Below is the output from this.

Cisco Systems VPN Client Version 4.0.1 (Rel)
Copyright (C) 1998-2003 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Windows, WinNT
Running on: 5.0.2195
1      12:12:19.875 04/12/06 Sev=Info/4 CM/0x63100002
Begin connection process
2      12:12:20.140 04/12/06 Sev=Info/4 CM/0x63100004
Establish secure connection using Ethernet
3      12:12:20.203 04/12/06 Sev=Info/4 CM/0x63100024
Attempt connection with server "203.0.220.234"
4      12:12:20.203 04/12/06 Sev=Info/6 IKE/0x6300003B
Attempting to establish a connection with 203.0.220.234.
5      12:12:20.437 04/12/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Nat-T), VID(Frag), VID(Unity)) to 203.0.220.234
6      12:12:20.437 04/12/06 Sev=Info/4 IPSEC/0x63700008
IPSec driver successfully started
7      12:12:20.437 04/12/06 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
8      12:12:25.718 04/12/06 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!
9      12:12:25.718 04/12/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 203.0.220.234
10     12:12:30.718 04/12/06 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!
11     12:12:30.718 04/12/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 203.0.220.234
12     12:12:36.203 04/12/06 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!
13     12:12:36.203 04/12/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 203.0.220.234
14     12:12:41.203 04/12/06 Sev=Info/4 IKE/0x63000017
Marking IKE SA for deletion (I_Cookie=228FA6557F8CDAE0 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING
15     12:12:41.703 04/12/06 Sev=Info/4 IKE/0x6300004A
Discarding IKE SA negotiation (I_Cookie=228FA6557F8CDAE0 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING
16     12:12:41.703 04/12/06 Sev=Info/4 CM/0x63100014
Unable to establish Phase 1 SA with server "203.0.220.234" because of "DEL_REASON_PEER_NOT_RESPONDING"
17     12:12:41.703 04/12/06 Sev=Info/5 CM/0x63100025
Initializing CVPNDrv
18     12:12:41.781 04/12/06 Sev=Info/4 IKE/0x63000001
IKE received signal to terminate VPN connection
19     12:12:42.203 04/12/06 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
20     12:12:42.203 04/12/06 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
21     12:12:42.203 04/12/06 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
22     12:12:42.203 04/12/06 Sev=Info/4 IPSEC/0x6370000A
IPSec driver successfully stopped

From what I can make out, the client is sending NAT-T but as you mentioned the IKE is failing. Can I tell conclusively from this that my end is ok and the issues are at the Cisco end?

Thanks for your time and assistance.

Neil Gray

(in reply to spouseele)

Post #: 101

Featured Links*

RE: How to pass IPSec traffic through ISA Server - 13.Apr.2006 8:11:41 PM

spouseele

Posts: 12782
Joined: 1.Jun.2001
From: Belgium
Status: offline

Hi Neil,

yep, the problem is along the path or with the remote site. The client log shows that the initial IKE request with NAT-T capability is effectively sent by the client. The ISA packet filter log shows that the initial IKE request is effectively sent by the ISA server. However in neither log we see an IKE response. So, the client retransmits a number of times and then gives up.

Therefore, either something between the ISA server and the remote site 203.0.220.234 doesn't allow IPSec, or the remote site does not listen on UDP port 500, or the remote site does not accept IKE packets from an UDP source port <> 500. The latter could indicate that te remote site is not configured to support IPSec NAT-T.

HTH,
Stefaan

(in reply to itsuncoast)

Post #: 102

RE: How to pass IPSec traffic through ISA Server - 14.Apr.2006 3:45:58 PM

fitzwat2

Posts: 1
Joined: 14.Apr.2006
Status: offline

Hi guys,

I am trying to setup VPN connections either L2TP or PPTP whichever one, doesnt really matter to me, through the ISA firewall/proxy server, but i seem to be unable to get the packets through. I am using the Linksys RV042 in the front in bridge mode to a modem, the Linksys is using a public IP. I have setup the filters and port forwarding on the Linksys. I have all the appropriate filters on in ISA, at least i think i do. Nothing shows up in the firewall log as to the reason why, or it just being plan rejected, it seems like the only thing that shows up in the log is successes that pass through. I am using SBS 2003 which has the ISA 2000 on it still. The filters on the ISA i have setup are of course 1701 etc. for the default ports on PPTP and L2TP. Its possible i might have a problem with my routing but i dont think so, because currently i have Radmin ver 2.2 that i am using to try and trouble shoot my issue with the proxy/firewall, but of course nothing is showing up in the log and the radmin program is not getting passed the LAN firewall/ISA firewall. I have the SecureNAT pptp passthrough enabled with my server's Internet NIC IP not my LAN's NIC IP enabled and I also have the radmin port enabled of course. I also have both L2TP and PPTP filters applied. This VPN setup is not a site to site connection as well, it is for home VPN users. I am pretty new to ISA server, can i get any help on this one, thanks.

Keith

< Message edited by fitzwat2 -- 14.Apr.2006 4:56:45 PM >

(in reply to itsuncoast)

Post #: 103

RE: How to pass IPSec traffic through ISA Server - 16.Apr.2006 12:17:38 AM

spouseele

Posts: 12782
Joined: 1.Jun.2001
From: Belgium
Status: offline

Hi Keith,

quote:

I have all the appropriate filters on in ISA, at least i think i do.

What have you done *exactly* to make it work so far? What are the ISA logs telling you?

For the PPTP passthrough, check out http://www.isaserver.org/tutorials/Allowing_Outbound_PING_and_PPTP_Connections.html.

HTH,
Stefaan

(in reply to fitzwat2)

Post #: 104

RE: How to pass IPSec traffic through ISA Server - 18.Apr.2006 2:11:04 AM

itsuncoast

Posts: 7
Joined: 17.Mar.2006
Status: offline

Hi Stefaan,

I finally received a reply from the Cisco Admin.

"Neil,
IKE runs on UDP 500, IPSec over NAT-T runs on UDP 4500.
If you used a direct internet machine e.g. dialup (not through your ISA) you would be able to connect to that NAT-T group fine. I know this because I have tested it myself from a direct internet machine and I also have another corporate agent using this new group. Its obviously a nat issue, so we just need to sort out the ISA natting part.

Chad"

He then replied to one of my ISA logs with what may be a valid point that I had missed. See below.

#Software: Microsoft(R) Internet Security and Acceleration Server 2000
#Version: 1.0
#Date: 2006-04-05 00:00:23
#Fields: date time source-ip destination-ip protocol param#1 param#2 tcp-flags filter-rule interface ip-header

2006-04-05 01:06:45 210.193.241.42 203.0.220.234 Udp 51351 500 - ALLOWED 210.193.241.42 45 00 03 88 77 73 00 00 80 11 00 00 d2 c1 f1 2a cb 00 dc ea
2006-04-05 01:06:51 210.193.241.42 203.0.220.234 Udp 51351 500 - ALLOWED 210.193.241.42 45 00 03 88 77 e7 00 00 80 11 00 00 d2 c1 f1 2a cb 00 dc ea
2006-04-05 01:06:56 210.193.241.42 203.0.220.234 Udp 51351 500 - ALLOWED 210.193.241.42 45 00 03 88 78 a4 00 00 80 11 00 00 d2 c1 f1 2a cb 00 dc ea
2006-04-05 01:07:01 210.193.241.42 203.0.220.234 Udp 51351 500 - ALLOWED 210.193.241.42 45 00 03 88 7a be 00 00 80 11 00 00 d2 c1 f1 2a cb 00 dc ea
Neil you can see the source port is 51351, I think it should be source port 500. This looks like it is doing PAT, it is proxying this connection essentially (hiding multiple IPs behind one public IP and identifying the client session based on its source port)

I thought that the source port 51351 was only used internally from the ISA to the client, and all outbound traffic would be sent from source port 500.

Stefaan, if what he is saying is true how do I rectify this?

Many thanks,

Neil Gray

(in reply to spouseele)

Post #: 105

RE: How to pass IPSec traffic through ISA Server - 18.Apr.2006 8:23:27 PM

spouseele

Posts: 12782
Joined: 1.Jun.2001
From: Belgium
Status: offline

Hi Neil,

quote:

RFC 3947 - Negotiation of NAT-Traversal in the IKE, January 2005

3. Phase 1

The detection of support for NAT-Traversal and detection of NAT along
the path between the two IKE peers occurs in IKE [RFC2409] Phase 1.

The NAT may change the IKE UDP source port, and recipients MUST be
able to process IKE packets whose source port is different from 500.
The NAT does not have to change the source port if:

o only one IPsec host is behind the NAT, or

o for the first IPsec host, the NAT can keep the port 500, and the
NAT will only change the port number for later connections.

Recipients MUST reply back to the source address from the packet (see
[RFC3715], section 2.1, case d). This means that when the original
responder is doing rekeying or sending notifications to the original
initiator, it MUST send the packets using the same set of port and IP
numbers used when the IKE SA was last used.

For example, when the initiator sends a packet with source and
destination port 500, the NAT may change it to a packet with source
port 12312 and destination port 500. The responder must be able to
process the packet whose source port is 12312. It must reply back
with a packet whose source port is 500 and destination port is 12312.
The NAT will then translate this packet to source port 500 and
destination port 500.

I think it is very clear that ISA server is *not* the culprit. Moreover, the NAT-T RFC's doesn't limit the NAT implementation to either 1:1 (NAT in Cisco terms) or N:1 (PAT in Cisco terms). Also, there might be multiple NAPT's along the path.

So, if the Cisco admin says that the IKE source port should be 500 then he doesn't know his job!

HTH,
Stefaan

(in reply to itsuncoast)

Post #: 106

RE: How to pass IPSec traffic through ISA Server - 19.Apr.2006 1:48:36 AM

itsuncoast

Posts: 7
Joined: 17.Mar.2006
Status: offline

Hi Stefaan,

I can't thank you enough for your time and advice.

I sent your comments on to the Cisco Admin (except for the bit about him not knowing his job). You know how sensitive these guys can be and I don't want to burn any bridges just yet.

Is this problem fixable or are we trying to do something that won't work if the Cisco implementation is not strictly RFC compliant?

Thanks again,

Neil Gray

(in reply to spouseele)

Post #: 107

RE: How to pass IPSec traffic through ISA Server - 19.Apr.2006 8:44:40 PM

spouseele

Posts: 12782
Joined: 1.Jun.2001
From: Belgium
Status: offline

Hi Neil,

as far as I know all Cisco boxes support by now IPSec NAT-T. So, if the guy runs an up-to-date software release on his Cisco box, it should work. This has been proven multiple times!

HTH,
Stefaan

< Message edited by spouseele -- 19.Apr.2006 8:45:57 PM >

(in reply to itsuncoast)

Post #: 108

RE: How to pass IPSec traffic through ISA Server - 26.Apr.2006 7:59:25 AM

itsuncoast

Posts: 7
Joined: 17.Mar.2006
Status: offline

Hi Stefaan,

The saga continues. Turns out that NAT-T is a Global setting and the Cisco admin had tried to assign it to one group only. When he did apply it globally he said it broke some of the connections for other people so he did it after hours and we tried to connect. It didn't work and he attached some of the log from the concentrator. See below.
590 04/20/2006 17:03:57.860 SEV=8 IKEDBG/81 RPT=13457 210.193.241.42
RECEIVED Message (msgid=0) with payloads :
HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR
(13) + VENDOR (13) + VENDOR (13) + NONE (0)
total length : 860
593 04/20/2006 17:03:57.860 SEV=9 IKEDBG/0 RPT=12502 210.193.241.42
processing SA payload
594 04/20/2006 17:03:57.860 SEV=9 IKEDBG/0 RPT=12503 210.193.241.42
processing ke payload
595 04/20/2006 17:03:57.860 SEV=9 IKEDBG/0 RPT=12504 210.193.241.42
processing ISA_KE
596 04/20/2006 17:03:57.860 SEV=9 IKEDBG/1 RPT=19137 210.193.241.42
processing nonce payload
597 04/20/2006 17:03:57.860 SEV=9 IKEDBG/1 RPT=19138 210.193.241.42
Processing ID
598 04/20/2006 17:03:57.860 SEV=9 IKEDBG/47 RPT=2622 210.193.241.42
processing VID payload
599 04/20/2006 17:03:57.860 SEV=9 IKEDBG/49 RPT=26448 210.193.241.42
Received xauth V6 VID
600 04/20/2006 17:03:57.860 SEV=9 IKEDBG/47 RPT=2623 210.193.241.42
processing VID payload
601 04/20/2006 17:03:57.860 SEV=9 IKEDBG/49 RPT=26449 210.193.241.42
Received DPD VID
602 04/20/2006 17:03:57.860 SEV=9 IKEDBG/47 RPT=2624 210.193.241.42
processing VID payload
603 04/20/2006 17:03:57.860 SEV=9 IKEDBG/49 RPT=26450 210.193.241.42
Received NAT-Traversal ver 02 VID
604 04/20/2006 17:03:57.860 SEV=9 IKEDBG/47 RPT=2625 210.193.241.42
processing VID payload
605 04/20/2006 17:03:57.860 SEV=9 IKEDBG/49 RPT=26451 210.193.241.42
Received Fragmentation VID
606 04/20/2006 17:03:57.860 SEV=5 IKEDBG/64 RPT=4651 210.193.241.42
IKE Peer included IKE fragmentation capability flags:
Main Mode: True
Aggressive Mode: False
608 04/20/2006 17:03:57.860 SEV=9 IKEDBG/47 RPT=2626 210.193.241.42
processing VID payload
609 04/20/2006 17:03:57.860 SEV=9 IKEDBG/49 RPT=26452 210.193.241.42
Received Cisco Unity client VID
610 04/20/2006 17:03:57.860 SEV=9 IKEDBG/23 RPT=63447 210.193.241.42
Starting group lookup for peer 210.193.241.42
638 04/20/2006 17:03:57.980 SEV=7 IKEDBG/80 RPT=63409 210.193.241.42
Group [corpagents-nat-t]
Found Phase 1 Group (corpagents-nat-t)
640 04/20/2006 17:03:57.980 SEV=7 IKEDBG/14 RPT=58295 210.193.241.42
Group [corpagents-nat-t]
Authentication configured for RADIUS
641 04/20/2006 17:03:57.980 SEV=9 IKEDBG/19 RPT=9157 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: primary DNS = 10.70.40.36
642 04/20/2006 17:03:57.980 SEV=9 IKEDBG/19 RPT=9158 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: secondary DNS = 10.80.2.36
643 04/20/2006 17:03:57.980 SEV=9 IKEDBG/19 RPT=9159 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: primary WINS = 10.70.40.36
644 04/20/2006 17:03:57.980 SEV=9 IKEDBG/19 RPT=9160 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: secondary WINS = 10.80.2.36
645 04/20/2006 17:03:57.980 SEV=9 IKEDBG/19 RPT=9161 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: split tunneling list = Telstra Cable Modem Heartbeat
647 04/20/2006 17:03:57.980 SEV=9 IKEDBG/19 RPT=9162 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: default domain = suncorpmetway.net
649 04/20/2006 17:03:57.980 SEV=9 IKEDBG/19 RPT=9163 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: IP Compression = LZS
650 04/20/2006 17:03:57.980 SEV=9 IKEDBG/19 RPT=9164 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: Split Tunneling Policy = Local Lan
652 04/20/2006 17:03:57.980 SEV=9 IKEDBG/78 RPT=50962 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: Browser Proxy Setting = 1
653 04/20/2006 17:03:57.980 SEV=9 IKEDBG/78 RPT=50963 210.193.241.42
Group [corpagents-nat-t]
IKEGetUserAttributes: Browser Proxy Bypass Local = 0
655 04/20/2006 17:03:57.980 SEV=9 IKEDBG/0 RPT=12505 210.193.241.42
Group [corpagents-nat-t]
processing IKE SA
1746 04/20/2006 17:03:58.020 SEV=7 IKEDBG/28 RPT=61143 210.193.241.42
Group [corpagents-nat-t]
IKE SA Proposal # 1, Transform # 10 acceptable
Matches global IKE entry # 2 Proposal (CiscoVPNClient-3DES-MD5)
1753 04/20/2006 17:03:58.810 SEV=9 IKEDBG/0 RPT=12506 210.193.241.42
Group [corpagents-nat-t]
constructing ISA_SA for isakmp
1754 04/20/2006 17:03:58.810 SEV=9 IKEDBG/0 RPT=12507 210.193.241.42
Group [corpagents-nat-t]
constructing ke payload
1755 04/20/2006 17:03:58.810 SEV=9 IKEDBG/1 RPT=19139 210.193.241.42
Group [corpagents-nat-t]
constructing nonce payload
1756 04/20/2006 17:03:58.810 SEV=9 IKEDBG/0 RPT=12508 210.193.241.42
Group [corpagents-nat-t]
Generating keys for Responder...
1757 04/20/2006 17:03:58.830 SEV=9 IKEDBG/1 RPT=19140 210.193.241.42
Group [corpagents-nat-t]
constructing ID
1759 04/20/2006 17:03:58.830 SEV=9 IKEDBG/0 RPT=12510 210.193.241.42
Group [corpagents-nat-t]
computing hash
1760 04/20/2006 17:03:58.830 SEV=9 IKEDBG/46 RPT=30313 210.193.241.42
Group [corpagents-nat-t]
constructing Cisco Unity VID payload
1761 04/20/2006 17:03:58.830 SEV=9 IKEDBG/46 RPT=30314 210.193.241.42
Group [corpagents-nat-t]
constructing xauth V6 VID payload
1762 04/20/2006 17:03:58.830 SEV=9 IKEDBG/46 RPT=30315 210.193.241.42
Group [corpagents-nat-t]
constructing dpd vid payload
1763 04/20/2006 17:03:58.830 SEV=9 IKEDBG/46 RPT=30316 210.193.241.42
Group [corpagents-nat-t]
constructing NAT-Traversal VID ver 02 payload
1765 04/20/2006 17:03:58.830 SEV=9 IKEDBG/0 RPT=12512 210.193.241.42
Group [corpagents-nat-t]
computing NAT Discovery hash
1767 04/20/2006 17:03:58.830 SEV=9 IKEDBG/0 RPT=12514 210.193.241.42
Group [corpagents-nat-t]
computing NAT Discovery hash
1768 04/20/2006 17:03:58.830 SEV=9 IKEDBG/46 RPT=30317 210.193.241.42
Group [corpagents-nat-t]
constructing Fragmentation VID + extended capabilities payload
1770 04/20/2006 17:03:58.830 SEV=9 IKEDBG/48 RPT=47187 210.193.241.42
Group [corpagents-nat-t]
Send IOS VID
1771 04/20/2006 17:03:58.830 SEV=9 IKEDBG/38 RPT=33230 210.193.241.42
Group [corpagents-nat-t]
Constructing VPN 3000 spoofing IOS Vendor ID payload (version: 1.0.0, capabiliti
es: 00000408)
1774 04/20/2006 17:03:58.830 SEV=9 IKEDBG/46 RPT=30318 210.193.241.42
Group [corpagents-nat-t]
constructing VID payload
1775 04/20/2006 17:03:58.830 SEV=9 IKEDBG/48 RPT=47188 210.193.241.42
Group [corpagents-nat-t]
Send Altiga GW VID
1776 04/20/2006 17:03:58.830 SEV=8 IKEDBG/81 RPT=13458 210.193.241.42
SENDING Message (msgid=0) with payloads :
HDR + SA (1) + KE (4)
total length : 448
1828 04/20/2006 17:04:02.090 SEV=8 IKEDBG/81 RPT=13467 210.193.241.42
RECEIVED Message (msgid=0) with payloads :
HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR
(13) + VENDOR (13) + VENDOR (13) + NONE (0)
total length : 860
1831 04/20/2006 17:04:02.090 SEV=6 IKE/202 RPT=7880 210.193.241.42
Duplicate first packet detected. Ignoring packet.
1882 04/20/2006 17:04:07.850 SEV=8 IKEDBG/81 RPT=13478 210.193.241.42
RECEIVED Message (msgid=0) with payloads :
HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR
(13) + VENDOR (13) + VENDOR (13) + NONE (0)
total length : 860
1885 04/20/2006 17:04:07.850 SEV=6 IKE/202 RPT=7881 210.193.241.42
Duplicate first packet detected. Ignoring packet.
1972 04/20/2006 17:04:13.200 SEV=8 IKEDBG/81 RPT=13496 210.193.241.42
RECEIVED Message (msgid=0) with payloads :
HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR
(13) + VENDOR (13) + VENDOR (13) + NONE (0)
total length : 860
1975 04/20/2006 17:04:13.200 SEV=6 IKE/202 RPT=7882 210.193.241.42
Duplicate first packet detected. Ignoring packet.
2239 04/20/2006 17:04:30.830 SEV=7 IKEDBG/65 RPT=56824 210.193.241.42
Group [corpagents-nat-t]
IKE AM Responder FSM error history (struct &0xf757ffc)
<state>, <event>:
AM_DONE, EV_ERROR
AM_WAIT_MSG3, EV_TIMEOUT
AM_WAIT_MSG3, NullEvent
AM_SND_MSG2, EV_CRYPTO_ACTIVE
2244 04/20/2006 17:04:30.830 SEV=9 IKEDBG/0 RPT=12668 210.193.241.42
Group [corpagents-nat-t]
IKE SA AM:8e903481 terminating:
flags 0x0104c001, refcnt 0, tuncnt 0
2247 04/20/2006 17:04:30.830 SEV=9 IKEDBG/0 RPT=12670 210.193.241.42
Group [corpagents-nat-t]
constructing blank hash
2249 04/20/2006 17:04:30.830 SEV=9 IKEDBG/0 RPT=12672 210.193.241.42
Group [corpagents-nat-t]
constructing qm hash
2250 04/20/2006 17:04:30.830 SEV=8 IKEDBG/81 RPT=13535 210.193.241.42
SENDING Message (msgid=2e88da9d) with payloads :
HDR + HASH (8) + DELETE (12)
total length : 76
4020 04/20/2006 17:05:22.000 SEV=8 IKEDBG/81 RPT=13643 210.193.241.42
RECEIVED Message (msgid=0) with payloads :
HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR
(13) + VENDOR (13) + VENDOR (13) + NONE (0)
total length : 860
4023 04/20/2006 17:05:22.000 SEV=6 IKE/202 RPT=7884 210.193.241.42
Duplicate first packet detected. Ignoring packet.
4028 04/20/2006 17:05:27.000 SEV=8 IKEDBG/81 RPT=13645 210.193.241.42
RECEIVED Message (msgid=0) with payloads :
HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR
(13) + VENDOR (13) + VENDOR (13) + NONE (0)
total length : 860
4031 04/20/2006 17:05:27.000 SEV=6 IKE/202 RPT=7885 210.193.241.42
Duplicate first packet detected. Ignoring packet.

I remember from one of your previous posts in this thread you mentioned you had been tasked to tackle something similar so I thought you may be familiar with a Cisco log. I couldn't identify the exact termination of the connection. Seems like you may be right about him not knowing his job but he's all I've got to work with at the moment.

Thank you,

Neil Gray

(in reply to spouseele)

Post #: 109

RE: How to pass IPSec traffic through ISA Server - 30.Apr.2006 7:53:26 PM

spouseele

Posts: 12782
Joined: 1.Jun.2001
From: Belgium
Status: offline

Hi Neil,

I never seen a log of the Cisco concentrator before. My preferred diagnose tool for such issues is Ethereal. Nevertheless, let see what we can find out of the posted log excerpt.

quote:

603 04/20/2006 17:03:57.860 SEV=9 IKEDBG/49 RPT=26450 210.193.241.42
Received NAT-Traversal ver 02 VID

It looks that the Cisco concentrator has received at least the NAT-T capability from the client.

quote:

1763 04/20/2006 17:03:58.830 SEV=9 IKEDBG/46 RPT=30316 210.193.241.42
Group [corpagents-nat-t]
constructing NAT-Traversal VID ver 02 payload
1765 04/20/2006 17:03:58.830 SEV=9 IKEDBG/0 RPT=12512 210.193.241.42
Group [corpagents-nat-t]
computing NAT Discovery hash
1767 04/20/2006 17:03:58.830 SEV=9 IKEDBG/0 RPT=12514 210.193.241.42
Group [corpagents-nat-t]
computing NAT Discovery hash

I looks that the Cisco is doing something with that NAT-T info.

quote:

1776 04/20/2006 17:03:58.830 SEV=8 IKEDBG/81 RPT=13458 210.193.241.42
SENDING Message (msgid=0) with payloads :
HDR + SA (1) + KE (4)
total length : 448

Here it is not clear what is *exactly* sent!

quote:

1828 04/20/2006 17:04:02.090 SEV=8 IKEDBG/81 RPT=13467 210.193.241.42
RECEIVED Message (msgid=0) with payloads :
HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR
(13) + VENDOR (13) + VENDOR (13) + NONE (0)
total length : 860
1831 04/20/2006 17:04:02.090 SEV=6 IKE/202 RPT=7880 210.193.241.42
Duplicate first packet detected. Ignoring packet.

Here the Cisco seems to receive again the first IKE message. So, it looks the client didn't receive anything expected in a timely fashion and therefore retransmit the first IKE message.

Again, an Ethereal or NetMon trace could give us some more info about what is *exactly* exchanged between both parties.

HTH,
Stefaan

(in reply to itsuncoast)

Post #: 110

RE: How to pass IPSec traffic through ISA Server - 23.May2006 6:06:11 AM

itsuncoast

Posts: 7
Joined: 17.Mar.2006
Status: offline

Hi Stefaan,

We have finally sorted out the problems I was having and it turned out to be a border router at the Cisco end blocking the returns to us from the Concentrator. Doh!

This router was blocking all high port numbers and when the client was initiating it uses a source port of 51351. The admin of this router would like to shut these ports down, so the last question I hope you can help me with is, how do I force an outbound request to use the port number 500 or a similar fixed port number?

Once again thankyou very much for your assistance on my problem.

Neil Gray

(in reply to spouseele)

Post #: 111

RE: How to pass IPSec traffic through ISA Server - 23.May2006 8:01:11 PM

spouseele

Posts: 12782
Joined: 1.Jun.2001
From: Belgium
Status: offline

Hi Neil,

good to hear you have it working and it was not ISA's fault!

Now, about the source port, as said before it is the very nature of NAPT that the source port will be dynamically chosen. So, nothing you can do about that. Please read again my post on Date 18.Apr.2006 8:23:27 PM with a quote from RFC 3947 - Negotiation of NAT-Traversal in the IKE, January 2005.

HTH,
Stefaan

(in reply to itsuncoast)

Post #: 112

RE: How to pass IPSec traffic through ISA Server - 24.May2006 3:46:04 AM

itsuncoast

Posts: 7
Joined: 17.Mar.2006
Status: offline

Hi Stefaan,

In the response and RFC you quoted:

The NAT does not have to change the source port if:

o only one IPsec host is behind the NAT, or

o for the first IPsec host, the NAT can keep the port 500, and the
NAT will only change the port number for later connections.

Is this a totally random thing of can you force NAT not to change the source port as this is the only IPSec connection from behind ISA?

I was also very glad it turned out to be a non ISA issue although sometimes it's easier if the problem is under your own control.

Many Thanks,

Neil

(in reply to spouseele)

Post #: 113

RE: How to pass IPSec traffic through ISA Server - 24.May2006 8:21:26 PM

spouseele

Posts: 12782
Joined: 1.Jun.2001
From: Belgium
Status: offline

Hi Neil,

when you have defined a NAT relationship in ISA server than the source port is *always* dynamically chosen. Moreover, in the case of IPSec passthrough, ISA server isn't even aware it is IPSec traffic. So, no special handling of the traffic is done as it is the case with some cheap NAT routers. This implies also that ISA doesn't have any problem in passing multiple IPSec session through and that is very often a big problem with those cheap NAT routers.

HTH,
Stefaan

(in reply to itsuncoast)

Post #: 114

RE: How to pass IPSec traffic through ISA Server - 13.Jun.2006 9:43:52 AM

magma

Posts: 2
Joined: 8.Jun.2006
Status: offline

Hello there,
in the past days I had a weird problem: traffic from and to a VPN worked sometimes yes and sometimes no.

People on a LAN subnet tried to connect using Cisco VPN Client (v. 4.7), but in the cases that connection failed I didn't understand why.

After a lot of tries, I disabled the 'CARP' on ISA server (Cache Array Routing Protocol) and the common cache: now it works every time.

Did you know this particular issue between ISA and VPNs?

Is there a workaround to enable again the caches?

Thanks in advance for any suggestion.

_____________________________

When she's walking by the river and the railway line
she can still hear him whisper
let's go down to the waterline.

(in reply to itsuncoast)

Post #: 115

RE: How to pass IPSec traffic through ISA Server - 13.Jun.2006 8:51:32 PM

spouseele

Posts: 12782
Joined: 1.Jun.2001
From: Belgium
Status: offline

Hi magma,

first of all, I have no experience whatsoever with an ISA Array, CARP, NLB, etc... So, I think I'm not well placed to comment on your particular issue. However, it's not clear to me if you have an issue with setting up the VPN connection itself or if the problem is with passing certain types of traffic through the VPN. Please clarify.

HTH,
Stefaan

(in reply to magma)

Post #: 116

RE: How to pass IPSec traffic through ISA Server - 14.Jun.2006 9:11:19 AM

magma

Posts: 2
Joined: 8.Jun.2006
Status: offline

quote:

ORIGINAL: spouseele

Hi magma,

first of all, I have no experience whatsoever with an ISA Array, CARP, NLB, etc... So, I think I'm not well placed to comment on your particular issue. However, it's not clear to me if you have an issue with setting up the VPN connection itself or if the problem is with passing certain types of traffic through the VPN. Please clarify.

HTH,
Stefaan

Hi,
the problem is with the VPN itself: IPSEC connections fail sometimes, with ISA in NLB, and the caches enabled.

_____________________________

When she's walking by the river and the railway line
she can still hear him whisper
let's go down to the waterline.

(in reply to spouseele)

Post #: 117

RE: How to pass IPSec traffic through ISA Server - 14.Jun.2006 9:13:49 PM

spouseele

Posts: 12782
Joined: 1.Jun.2001
From: Belgium
Status: offline

Hi magma,

OK, in that case I suggest you post your question to the ISAserver.org Discussion List. Hopefully Tom Shinder and/or Jim Harrison will pick it up soon.

Thanks,
Stefaan

(in reply to magma)

Post #: 118

Connection Problems with Sonicwall GVC & ISA server 2004 - 21.Nov.2006 6:48:00 PM

SNarayan

Posts: 3
Joined: 16.Dec.2003
Status: offline

Hi,

I am having problems getting connected to a remote VPN server from behind an ISA 2004 Server.

VPN client= Sonicwall GVC v3.1.0.556 (latest one available)

I have applied all protocols, IKE, IPSec, LTP2, PPTP....

Sonicwall GVC log reads:

Starting ISAKMP phase 1 negotiation
The peer is not responding to phase 1 ISAKMP request

What else do I have to do? I have checked the article on IPSec pass through on this site but does not help...all required ports seem to be open.

Please help.

Thanks,
SN

(in reply to spouseele)

Post #: 119

RE: Connection Problems with Sonicwall GVC & ISA server... - 22.Nov.2006 2:10:56 PM