VPN to third-party firewall problems (Full Version)

All Forums >> [ISA Server 2004 Firewall] >> VPN



Message


twcarlin -> VPN to third-party firewall problems (22.Apr.2005 11:47:00 PM)

OK, according to MS, you can do a site-ot-site VPN with a third party firewall using IPSEC. the article is here-
third-party site-to-site vpn

I've tried it with sonicwall and linksys firewalls, and both fail on phase 2 with the same error- INVALID_ID_INFO

I've triple checked the configurations and they match on both ends- has anyone come across this?




ClintD -> RE: VPN to third-party firewall problems (23.Apr.2005 4:08:00 AM)

Windows can only use IP address for IKE Identity - do the Linksys and Sonicwall have options ro allow IP Address for this parameter?

If this is already set, enable oakley logging in the ISA Server and post the contents of the c:\windows\debug\oakley.log when you try to connect.

c:\netsh ipsec dynamic set config ikelogging 1

Also, where are you tsting from? The ISA Server or from a client behind ISA? If you test from the ISA Server, you'll need to include ISAs IP address in the tunnel mode policy on the Sonicwall or Linksys. When we PING from ISA, it sources from it's external IP - ISA automatically includes it's external IP in the IPSec filters lists, but typically, this IP isn't included in the remote configuration.




Guest -> RE: VPN to third-party firewall problems (23.Apr.2005 8:16:00 AM)

FWIW, in my tesing with linksys/iogear vpn connections to ISA2004, if you're running windows 2003 sp1, these connections will be flaky at best. Removing sp1 from windows seems to make it work better.
The linksys befsx41, if set with identical setting on ISA, works nicely (minus sp1).

Make sure that phase1 and phase2 encryption (des/3des) match with the encryption for phase1 and phase2 on ISA. Here's my setting on the befsx41;

Phase 1:
Operation mode : Main mode

Proposal 1:
Encryption : DES
Authentication : SHA
Group : 1024-bit
Key Lifetime : 3600 seconds

Phase 2:

Proposal 2:
Encryption : 3DES
Authentication : SHA
PFS : ON
Group : 1024-bit
Key Lifetime : 3600 seconds

Other Setting:
NetBIOS broadcast
Keep-Alive

Make sure the key lifetime matches as well on the ISA server (for both phases). If the settings do indeed match on both ends, the tunnel will connect (though a reboot of the ISA server can at times do wonders if all else fails [Wink]

Sidebar: Under windows 2003 sp1, I noticed that when the vpn was connected between the befsx41 and ISA, ISA would initiate IKE every 360 seconds no matter how high you set the key lifetime to (172800 seconds max). Remove sp1, and IKE happens at the alotted times. Anyone know what gives?




ClintD -> RE: VPN to third-party firewall problems (23.Apr.2005 9:23:00 AM)

How did you determine that ISA was rekeying the SA? Was Main Mode or Quick Mode being re-keyed?

Is the 360 seconds above a typo? Did you mean 3600?

If you meant 360, it corresponds to Windows IPSec reaper process - the reaper comes through every 5-6 minutes and cleans up any un-used SAs - this might correspond to the problem below.

As for the Win2003 SP1 oddities - are your test "clients" Win2003 SP1? There was a regression in Win2003 SP1 such that it disregards ICMP Destination Unreachable messages. This also occurs after installing the patch for MS05-019 on both Win2000 WinXP. A fix for this is forthcoming (I work in MS' PSS).

I said that it could be correlated to the 360 second rekey as the packets would get dropped before IPSec could send them resulting in the SA going idle. This is just conjecture on my part right now - I'd have to set it up for testing.

[ April 23, 2005, 09:38 AM: Message edited by: ClintD ]




Guest -> RE: VPN to third-party firewall problems (23.Apr.2005 5:51:00 PM)

quote:
Originally posted by ClintD:
How did you determine that ISA was rekeying the SA?

When I looked over the real time monitoring, as well as looking at the linksys log, the ISA monitor would show the external IP of ISA "initiating connection" to the linksys IP. The linksys log would reflect this as well.
quote:
Was Main Mode or Quick Mode being re-keyed?
Main Mode, afaik. I would get a lot of 547 errors in the security event log, with this at the bottom;
Failure Point:
Me

Failure Reason:
IKE SA deleted before establishment completed
quote:
Is the 360 seconds above a typo? Did you mean 3600?
Sorry, I should have also put in brackets 6 minutes to confirm, but no, 360 seconds was not a typo, that is actually how frequently IKE was being initiated by ISA.
quote:
If you meant 360, it corresponds to Windows IPSec reaper process - the reaper comes through every 5-6 minutes and cleans up any un-used SAs
Okay, I have a bit more for you if it helps. Whereas the vast majority of the time IKE is initiated every 360 seconds (6 minutes) there are the odd times (key lifetime settings notwithstanding) that IKE will be initiated every 480 seconds (8 minutes) after a pipe is connected, though this is rare.
quote:
As for the Win2003 SP1 oddities - are your test "clients" Win2003 SP1?
Actually, the only Windows 2003 SP1/ISA 2004 SP1 in my testing has only been one machine, pretty much a virgin install of the OS, upgraded to SP1, then ISA 2004 added, the SP1 for 2004 (I know, I know, shouldn't install 2004 on a SP1 machine, should install 2004 then SP1 for Windows, right? Read something about this after the fact). The ISA server is then connected to a remote linksys befsx41 vpn endpoint.
I must add though that under this setup (windows 2003 sp1/ISA sp1) I could connect via PPTP to a windows 2000/ISA 2000 machine and it worked fine. I don't have a computer running windows 2003sp1/ISA2004 sp1 to test the IPSEC between them, just the linksys and iogear routers, the linksys being a bit more configureable for IPSEC, however both work. I would have liked to test IPSEC between two windows firewalls of the same setup before opening my mouth, but when I read cnytech's post, I couldn't resist posting my findings to date.
quote:
There was a regression in Win2003 SP1 such that it disregards ICMP Destination Unreachable messages. This also occurs after installing the patch for MS05-019 on both Win2000 WinXP. A fix for this is forthcoming (I work in MS' PSS).
Your expertise on this subject is an invaluable addition to this forum, thanks for taking the time to hang around.
quote:
I said that it could be correlated to the 360 second rekey as the packets would get dropped before IPSec could send them resulting in the SA going idle. This is just conjecture on my part right now - I'd have to set it up for testing.
I will be doing a wipe and reload of the ISA server in question (made a lot of quick changes to the server during troubleshooting, as well I am not a big fan of removing service packs and still using the machine, would rather start fresh) likely without sp1 for windows.
If you had a suggestion for installation path (eg, install windows, install ISA 2004, upgrade to sp1 on ISA 2004, or even upgrade to sp1 on windows) I would be happy to follow it and repost my reults.

Thanks again Clint, and sorry cnytech if it looks I hijacked your post.




ClintD -> RE: VPN to third-party firewall problems (23.Apr.2005 7:03:00 PM)

For your lab, Win2003, ISA, then ISA SP1 should be safe enough until the ICMP issue gets sorted out.




twcarlin -> RE: VPN to third-party firewall problems (23.Apr.2005 7:06:00 PM)

Ok here is the oakley log, as you can see, the log says phase 1 completes, phase 2 is saying- "Failed to get TunnelPolicy 13015" followed by " Responder failed to match filter(Phase II) 13015" and "No policy configured"

Thanks for the help so far, if we can get this resolved i'll be able to sleep at night again.

4-23: 12:51:24:24:f60 isadb_schedule_kill_oldPolicy_sas: 7003fdb6-f96d-47ff-b427db8973e0b279 3
4-23: 12:51:24:40:994 entered kill_old_policy_sas 3
4-23: 12:51:24:134:f60 isadb_schedule_kill_oldPolicy_sas: 7003fdb6-f96d-47ff-b427db8973e0b279 3
4-23: 12:51:24:149:994 entered kill_old_policy_sas 3
4-23: 12:51:40:680:798 isadb_schedule_kill_oldPolicy_sas: 7003fdb6-f96d-47ff-b427db8973e0b279 3
4-23: 12:51:40:695:994 entered kill_old_policy_sas 3
4-23: 12:51:40:789:ab8 isadb_schedule_kill_oldPolicy_sas: 7003fdb6-f96d-47ff-b427db8973e0b279 3
4-23: 12:51:40:805:994 entered kill_old_policy_sas 3
4-23: 12:53:58:64:994
4-23: 12:53:58:64:994 Receive: (get) SA = 0x00000000 from 24.39.215.118.500
4-23: 12:53:58:64:994 ISAKMP Header: (V1.0), len = 100
4-23: 12:53:58:64:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:53:58:64:994 R-COOKIE 0000000000000000
4-23: 12:53:58:64:994 exchange: Oakley Main Mode
4-23: 12:53:58:64:994 flags: 0
4-23: 12:53:58:64:994 next payload: SA
4-23: 12:53:58:64:994 message ID: 00000000
4-23: 12:53:58:64:994 Filter to match: Src 24.39.215.118 Dst 209.217.202.118
4-23: 12:53:58:64:994 MM PolicyName: ISA Server watertown_vpn MM Policy
4-23: 12:53:58:64:994 MMPolicy dwFlags 0 SoftSAExpireTime 28800
4-23: 12:53:58:64:994 MMOffer[0] LifetimeSec 28800 QMLimit 0 DHGroup 2
4-23: 12:53:58:64:994 MMOffer[0] Encrypt: Triple DES CBC Hash: SHA
4-23: 12:53:58:64:994 Auth[0]:PresharedKey KeyLen 26
4-23: 12:53:58:64:994 Responding with new SA e1890
4-23: 12:53:58:64:994 processing payload SA
4-23: 12:53:58:64:994 Received Phase 1 Transform 1
4-23: 12:53:58:64:994 Encryption Alg Triple DES CBC(5)
4-23: 12:53:58:64:994 Hash Alg SHA(2)
4-23: 12:53:58:64:994 Oakley Group 2
4-23: 12:53:58:64:994 Auth Method Preshared Key(1)
4-23: 12:53:58:64:994 Life type in Seconds
4-23: 12:53:58:64:994 Life duration of 28800
4-23: 12:53:58:64:994 Phase 1 SA accepted: transform=1
4-23: 12:53:58:64:994 SA - Oakley proposal accepted
4-23: 12:53:58:79:994 processing payload VENDOR ID
4-23: 12:53:58:79:994 ClearFragList
4-23: 12:53:58:79:994 constructing ISAKMP Header
4-23: 12:53:58:79:994 constructing SA (ISAKMP)
4-23: 12:53:58:79:994 Constructing Vendor MS NT5 ISAKMPOAKLEY
4-23: 12:53:58:79:994 Constructing Vendor FRAGMENTATION
4-23: 12:53:58:79:994 Constructing Vendor draft-ietf-ipsec-nat-t-ike-02
4-23: 12:53:58:79:994
4-23: 12:53:58:79:994 Sending: SA = 0x000E1890 to 24.39.215.118:Type 2.500
4-23: 12:53:58:79:994 ISAKMP Header: (V1.0), len = 148
4-23: 12:53:58:79:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:53:58:79:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:53:58:79:994 exchange: Oakley Main Mode
4-23: 12:53:58:79:994 flags: 0
4-23: 12:53:58:79:994 next payload: SA
4-23: 12:53:58:79:994 message ID: 00000000
4-23: 12:53:58:79:994 Ports S:f401 D:f401
4-23: 12:53:58:204:994
4-23: 12:53:58:204:994 Receive: (get) SA = 0x000e1890 from 24.39.215.118.500
4-23: 12:53:58:204:994 ISAKMP Header: (V1.0), len = 220
4-23: 12:53:58:204:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:53:58:204:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:53:58:204:994 exchange: Oakley Main Mode
4-23: 12:53:58:204:994 flags: 0
4-23: 12:53:58:204:994 next payload: KE
4-23: 12:53:58:204:994 message ID: 00000000
4-23: 12:53:58:204:994 processing payload KE
4-23: 12:53:58:267:994 processing payload NONCE
4-23: 12:53:58:267:994 processing payload VENDOR ID
4-23: 12:53:58:267:994 processing payload VENDOR ID
4-23: 12:53:58:267:994 processing payload VENDOR ID
4-23: 12:53:58:267:994 ClearFragList
4-23: 12:53:58:267:994 constructing ISAKMP Header
4-23: 12:53:58:267:994 constructing KE
4-23: 12:53:58:267:994 constructing NONCE (ISAKMP)
4-23: 12:53:58:267:994
4-23: 12:53:58:267:994 Sending: SA = 0x000E1890 to 24.39.215.118:Type 2.500
4-23: 12:53:58:267:994 ISAKMP Header: (V1.0), len = 184
4-23: 12:53:58:267:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:53:58:267:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:53:58:267:994 exchange: Oakley Main Mode
4-23: 12:53:58:267:994 flags: 0
4-23: 12:53:58:267:994 next payload: KE
4-23: 12:53:58:267:994 message ID: 00000000
4-23: 12:53:58:267:994 Ports S:f401 D:f401
4-23: 12:53:58:439:994
4-23: 12:53:58:439:994 Receive: (get) SA = 0x000e1890 from 24.39.215.118.500
4-23: 12:53:58:439:994 ISAKMP Header: (V1.0), len = 100
4-23: 12:53:58:439:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:53:58:439:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:53:58:439:994 exchange: Oakley Main Mode
4-23: 12:53:58:439:994 flags: 1 ( encrypted )
4-23: 12:53:58:439:994 next payload: ID
4-23: 12:53:58:439:994 message ID: 00000000
4-23: 12:53:58:439:994 processing payload ID
4-23: 12:53:58:439:994 processing payload HASH
4-23: 12:53:58:439:994 AUTH: Phase I authentication accepted
4-23: 12:53:58:439:994 processing payload NOTIFY
4-23: 12:53:58:439:994 Unknown Notify Message 24578
4-23: 12:53:58:439:994 ClearFragList
4-23: 12:53:58:439:994 constructing ISAKMP Header
4-23: 12:53:58:439:994 constructing ID
4-23: 12:53:58:439:994 MM ID Type 1
4-23: 12:53:58:439:994 MM ID d1d9ca76
4-23: 12:53:58:439:994 constructing HASH
4-23: 12:53:58:439:994 MM established. SA: 000E1890
4-23: 12:53:58:439:994
4-23: 12:53:58:439:994 Sending: SA = 0x000E1890 to 24.39.215.118:Type 2.500
4-23: 12:53:58:439:994 ISAKMP Header: (V1.0), len = 68
4-23: 12:53:58:439:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:53:58:439:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:53:58:439:994 exchange: Oakley Main Mode
4-23: 12:53:58:439:994 flags: 1 ( encrypted )
4-23: 12:53:58:439:994 next payload: ID
4-23: 12:53:58:439:994 message ID: 00000000
4-23: 12:53:58:439:994 Ports S:f401 D:f401
4-23: 12:53:58:579:994
4-23: 12:53:58:579:994 Receive: (get) SA = 0x000e1890 from 24.39.215.118.500
4-23: 12:53:58:579:994 ISAKMP Header: (V1.0), len = 300
4-23: 12:53:58:579:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:53:58:579:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:53:58:579:994 exchange: Oakley Quick Mode
4-23: 12:53:58:579:994 flags: 1 ( encrypted )
4-23: 12:53:58:579:994 next payload: HASH
4-23: 12:53:58:579:994 message ID: 0bdf604c
4-23: 12:53:58:579:994 processing HASH (QM)
4-23: 12:53:58:579:994 ClearFragList
4-23: 12:53:58:579:994 processing payload NONCE
4-23: 12:53:58:579:994 processing payload KE
4-23: 12:53:58:579:994 Quick Mode KE processed; Saved KE data
4-23: 12:53:58:579:994 processing payload ID
4-23: 12:53:58:579:994 processing payload ID
4-23: 12:53:58:579:994 processing payload SA
4-23: 12:53:58:579:994 Negotiated Proxy ID: Src 192.168.0.0.0 Dst 192.168.1.0.0
4-23: 12:53:58:579:994 Src id for subnet. Mask 255.255.255.0
4-23: 12:53:58:579:994 Dst id for subnet. Mask 255.255.255.0
4-23: 12:53:58:579:994 Checking Proposal 1: Proto= ESP(3), num trans=1 Next=0
4-23: 12:53:58:579:994 Checking Transform # 1: ID=Triple DES CBC(3)
4-23: 12:53:58:579:994 SA life type in seconds
4-23: 12:53:58:579:994 SA life duration 28800
4-23: 12:53:58:579:994 group description for PFS is 2
4-23: 12:53:58:579:994 tunnel mode is Tunnel Mode(1)
4-23: 12:53:58:579:994 HMAC algorithm is SHA(2)
4-23: 12:53:58:579:994 Finding Responder Policy for SRC=192.168.0.0.0000 DST=192.168.1.0.0000, SRCMask=255.255.255.0, DSTMask=255.255.255.0, Prot=0 InTunnelEndpt 76cad9d1 OutTunnelEndpt 76d72718
4-23: 12:53:58:579:994 Failed to get TunnelPolicy 13015
4-23: 12:53:58:579:994 Responder failed to match filter(Phase II) 13015
4-23: 12:53:58:579:994 Data Protection Mode (Quick Mode)
4-23: 12:53:58:579:994 Source IP Address 192.168.1.0 Source IP Address Mask 255.255.255.0 Destination IP Address 192.168.0.0 Destination IP Address Mask 255.255.255.0 Protocol 0 Source Port 0 Destination Port 0 IKE Local Addr 209.217.202.118 IKE Peer Addr 24.39.215.118 IKE Source Port 500 IKE Destination Port 500 Peer Private Addr
4-23: 12:53:58:579:994 Preshared key ID. Peer IP Address: 24.39.215.118
4-23: 12:53:58:579:994 Me
4-23: 12:53:58:579:994 No policy configured
4-23: 12:53:58:579:994 Processed third (ID) payload Responder. Delta Time 0 0x0 0x0
4-23: 12:53:58:579:994 isadb_set_status sa:000E1890 centry:000F08C8 status 3601
4-23: 12:53:58:579:994 ProcessFailure: sa:000E1890 centry:000F08C8 status:3601
4-23: 12:53:58:579:994 constructing ISAKMP Header
4-23: 12:53:58:579:994 constructing HASH (null)
4-23: 12:53:58:579:994 constructing NOTIFY 18
4-23: 12:53:58:579:994 constructing HASH (Notify/Delete)
4-23: 12:53:58:579:994
4-23: 12:53:58:579:994 Sending: SA = 0x000E1890 to 24.39.215.118:Type 1.500
4-23: 12:53:58:579:994 ISAKMP Header: (V1.0), len = 68
4-23: 12:53:58:579:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:53:58:579:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:53:58:579:994 exchange: ISAKMP Informational Exchange
4-23: 12:53:58:579:994 flags: 1 ( encrypted )
4-23: 12:53:58:579:994 next payload: HASH
4-23: 12:53:58:579:994 message ID: 34c57457
4-23: 12:53:58:579:994 Ports S:f401 D:f401
4-23: 12:54:03:220:994
4-23: 12:54:03:220:994 Receive: (get) SA = 0x000e1890 from 24.39.215.118.500
4-23: 12:54:03:220:994 ISAKMP Header: (V1.0), len = 300
4-23: 12:54:03:220:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:54:03:220:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:54:03:220:994 exchange: Oakley Quick Mode
4-23: 12:54:03:220:994 flags: 1 ( encrypted )
4-23: 12:54:03:220:994 next payload: HASH
4-23: 12:54:03:220:994 message ID: 0bdf604c
4-23: 12:54:03:220:994 Dropping Centry processing because SA status set. SA 000E1890 Centry 000F08C8 Status 3601
4-23: 12:54:11:454:994
4-23: 12:54:11:454:994 Receive: (get) SA = 0x000e1890 from 24.39.215.118.500
4-23: 12:54:11:454:994 ISAKMP Header: (V1.0), len = 300
4-23: 12:54:11:454:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:54:11:454:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:54:11:454:994 exchange: Oakley Quick Mode
4-23: 12:54:11:454:994 flags: 1 ( encrypted )
4-23: 12:54:11:454:994 next payload: HASH
4-23: 12:54:11:454:994 message ID: 0bdf604c
4-23: 12:54:11:454:994 Dropping Centry processing because SA status set. SA 000E1890 Centry 000F08C8 Status 3601
4-23: 12:54:28:469:994
4-23: 12:54:28:469:994 Receive: (get) SA = 0x000e1890 from 24.39.215.118.500
4-23: 12:54:28:469:994 ISAKMP Header: (V1.0), len = 300
4-23: 12:54:28:469:994 I-COOKIE 8254c1582f48b1a1
4-23: 12:54:28:469:994 R-COOKIE 9bbc17c967c16d3b
4-23: 12:54:28:469:994 exchange: Oakley Quick Mode
4-23: 12:54:28:469:994 flags: 1 ( encrypted )
4-23: 12:54:28:469:994 next payload: HASH
4-23: 12:54:28:469:994 message ID: 0bdf604c
4-23: 12:54:28:469:994 Dropping Centry processing because SA status set. SA 000E1890 Centry 000F08C8 Status 3601




ClintD -> RE: VPN to third-party firewall problems (23.Apr.2005 9:48:00 PM)

This is where we fail - the error 13015 basically means that we don't have a matching filter for the offer that the remote side sent us.

code:
Finding Responder Policy for
SRC=192.168.0.0.0000
DST=192.168.1.0.0000
SRCMask=255.255.255.0
DSTMask=255.255.255.0
Prot=0
InTunnelEndpt 76cad9d1 = 118.202.217.209
OutTunnelEndpt 76d72718 = 118.215.39.24

So this is what the remote side is sending for the Quick Mode filters - run the following command to see if you truly do have a match for this offer.

netsh ipsec dynamic show qmfilter all

ISA builds it's IPSec filters based off of your Network definitions so if you don't have all addresses listed in there, it can result in Quick Mode failures.

For example, it appears that your Internal Network is using the 192.168.1.0/24 subnet range - does your Internal network contain 192.168.1.0 - 192.168.1.255?

[ April 23, 2005, 09:50 PM: Message edited by: ClintD ]




ifurlender -> RE: VPN to third-party firewall problems (12.Sep.2005 3:10:00 PM)

I am having the same problem but I am not able to enable Oakly since I have windows 2000. Is there a way to find out what is going on when the remote VPN is connecting with Windows 2000?




ClintD -> RE: VPN to third-party firewall problems (13.Sep.2005 2:05:00 PM)

You can enable Oakley logging on Win2000 in the registry.

HKEy_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley ->EnableLogging Reg_DWORD of 1. You might have to create the Oakley folder (or Key, more properly). If possible, it's easieer to restart the system to get the C:\Windows\Debug\Oakley.log created.

[ September 13, 2005, 02:05 PM: Message edited by: ClintD ]




ifurlender -> RE: VPN to third-party firewall problems (13.Sep.2005 2:34:00 PM)

Thanks Clint. This is what I get in the log.

9-13: 14:36:01:6d4 *****************Queueing work for worker. 6
9-13: 14:36:01:8a8
9-13: 14:36:01:8a8 Resume: (get) SA = 0x00000000 from xxx.xxx.xxx.xxx
9-13: 14:36:01:8a8 ISAKMP Header: (V1.0), len = 192
9-13: 14:36:01:8a8 I-COOKIE 0f0646ee8a587c1b
9-13: 14:36:01:8a8 R-COOKIE 0000000000000000
9-13: 14:36:01:8a8 exchange: Oakley Main Mode
9-13: 14:36:01:8a8 flags: 0
9-13: 14:36:01:8a8 next payload: SA
9-13: 14:36:01:8a8 message ID: 00000000
9-13: 14:36:01:8a8 DetermineSourceAddr Sock 1592
9-13: 14:36:01:8a8 Filter to match: Src xxx.xxx.xxx.xxx.0 Dst xxx.xxx.xxx.xxx.0 Proto = 0
9-13: 14:36:01:8a8 Responder failed to match filter
9-13: 14:36:01:8a8 Responding with new SA 0
9-13: 14:36:01:8a8 HandleFirstPacketResponder failed cbad0339

Maybe this makes some sence to you. I will be very very very happy if you can help with this.

Thank you in advance,

Igor Furlender




ClintD -> RE: VPN to third-party firewall problems (13.Sep.2005 4:39:00 PM)

Heh - it's pretty cryptic, but you get used to it, like anything else, by learning what is relevant and what isn't.

So the first part...

quote:

9-13: 14:36:01:8a8 Resume: (get) SA = 0x00000000 from xxx.xxx.xxx.xxx
9-13: 14:36:01:8a8 ISAKMP Header: (V1.0), len = 192
9-13: 14:36:01:8a8 I-COOKIE 0f0646ee8a587c1b
9-13: 14:36:01:8a8 R-COOKIE 0000000000000000

A RESUME message is an incoming message from a remote host - in other words, ISA received an IPSec negotiation request.

The I-COOKIE and R-COOKIE attributes help the IPSec component track messages and also illustrate that this i a "First Contact" message - if the R-COOKIE attribute is all 0's, then it's the first message sent.

The rest of it is pretty straightforward - ISA receives an offer from the remote host - "Filter to match...", but the offer doesn't match what ISA has defined - "Responder failed to match filter". Since you blanked out the IP,s it's hard to help isolate it further. Possibly provide a diagram of the topology and the endpoint addresses of the tunnel (just mask the last octet) and we'll see if we can figure this out. Also, the details of the ISA Server Remote Site - addresses and such.

[ September 13, 2005, 04:40 PM: Message edited by: ClintD ]




ifurlender -> RE: VPN to third-party firewall problems (13.Sep.2005 7:10:00 PM)

The setup is simple. In this main office I have the ISA server attached directly to the DSL Modem with the external NIC and the LAN with the internal NIC. At the remote I have a Linksys BEFSX41 router attached to the DSL modem. I hope that is enough info for you.

This is the message:

9-13: 18:33:24:7cc *****************Queueing work for worker. 2
9-13: 18:33:24:120
9-13: 18:33:24:120 Resume: (get) SA = 0x00000000 from 151.204.191.xxx
9-13: 18:33:24:120 ISAKMP Header: (V1.0), len = 192
9-13: 18:33:24:120 I-COOKIE b38e8c2f743d1bd2
9-13: 18:33:24:120 R-COOKIE 0000000000000000
9-13: 18:33:24:120 exchange: Oakley Main Mode
9-13: 18:33:24:120 flags: 0
9-13: 18:33:24:120 next payload: SA
9-13: 18:33:24:120 message ID: 00000000
9-13: 18:33:24:120 DetermineSourceAddr Sock 1476
9-13: 18:33:24:120 Filter to match: Src 151.204.191.xxx.0 Dst 68.236.202.xxx.0 Proto = 0
9-13: 18:33:24:120 Responder failed to match filter
9-13: 18:33:24:120 Responding with new SA 0
9-13: 18:33:24:120 HandleFirstPacketResponder failed cbad0339




ClintD -> RE: VPN to third-party firewall problems (13.Sep.2005 8:28:00 PM)

OK - could you post the details of the ISA Server Remote Site? The Tunnel endpoint settings and remote site address subnet.




ifurlender -> RE: VPN to third-party firewall problems (15.Sep.2005 1:22:00 PM)

Ok. The subnet in the remote office is 10.1.1.0 255.255.255.0.
The subnet in the main office is 192.168.1.0 255.255.255.0.

Proposal 1
Encryption DES
Auth SHA
Group 1024
Key Lifetime 3600

Proposal 2
Encryption 3DES
Auth SHA
Group 1024
Key Lifetime 3600

NetBIOS broadcast
Keep-Alive are checked

Auto. Ike is enabled

I hope this is enough. If you need more please let me know exactly what you need.




ClintD -> RE: VPN to third-party firewall problems (15.Sep.2005 1:43:00 PM)

<smack>

Crap - I forgot about this - since you're running Windows 2000, I'm going to assume that you have ISA enabled for VPN access? If so, then the L2TP policy is conflicting with the IPsec Tunnel Mode policy you have configured.

With Win2000, it can only have 1 Main Mode policy configured so you'll need to configure your Tunnel Mode parameters to match the details of the L2TP IPSec policy.

Use NETDIAG /V /DEBUG:IPSEC to view the L2TP policy.




ifurlender -> RE: VPN to third-party firewall problems (15.Sep.2005 2:21:00 PM)

It gives me alot. It says that there are 42 Filters. This thing goes on for ever. What am I looking for?




ifurlender -> RE: VPN to third-party firewall problems (15.Sep.2005 2:27:00 PM)

This is just one page of what I get:

IP Security test . . . . . . . . . : Passed
IPSec policy service is active, but no policy is assigned.

There are 42 filters
No Name
Filter Id: {CEB19FFA-F050-4469-8D63-DB88C0E09D44}
Policy Id: {43BD584A-3EE1-405A-9312-E167FF310352}
IPSEC_POLICY PolicyId = {43BD584A-3EE1-405A-9312-E167FF310352}
Flags: 0x0
Tunnel Addr: 0.0.0.0
PHASE 2 OFFERS Count = 1
Offer #0:
ESP[ 3DES SHA1 HMAC]
Rekey: 3600 seconds / 0 bytes. With PFS.
AUTHENTICATION INFO Count = 1
Method = Preshared key: 2014989400
Src Addr : 192.168.1.1 Src Mask : 255.255.255.255
Dest Addr : 10.1.1.0 Dest Mask : 255.255.255.0
Tunnel Addr : 151.204.191.xxx Src Port : 0 Dest Port : 0
Protocol : 0 TunnelFilter: Yes
Flags : Outbound
No Name
Filter Id: {BB67A81E-67FC-4FDB-AAAF-BBDDF34E9B1B}
Policy Id: {83EC7C53-E53B-4D94-9DD5-1EA49C952A07}
IPSEC_POLICY PolicyId = {83EC7C53-E53B-4D94-9DD5-1EA49C952A07}
Flags: 0x0
Tunnel Addr: 0.0.0.0
PHASE 2 OFFERS Count = 1
Offer #0:
ESP[ 3DES SHA1 HMAC]
Rekey: 3600 seconds / 0 bytes. With PFS.
AUTHENTICATION INFO Count = 1
Method = Preshared key: 2014989400
Src Addr : 10.1.1.0 Src Mask : 255.255.255.0
Dest Addr : 192.168.1.1 Dest Mask : 255.255.255.255
Tunnel Addr : 68.236.202.xxx Src Port : 0 Dest Port : 0
Protocol : 0 TunnelFilter: Yes
Flags : Inbound
No Name
Filter Id: {CB59525B-EC0E-4A51-A4A1-086625DCD728}
Policy Id: {0AF55EAD-34D3-4CE1-8E66-B0F6300D7BC7}
IPSEC_POLICY PolicyId = {0AF55EAD-34D3-4CE1-8E66-B0F6300D7BC7}
Flags: 0x0
Tunnel Addr: 0.0.0.0
PHASE 2 OFFERS Count = 1
Offer #0:
ESP[ 3DES SHA1 HMAC]
Rekey: 3600 seconds / 0 bytes. With PFS.
AUTHENTICATION INFO Count = 1
Method = Preshared key: 2014989400
Src Addr : 192.168.11.254 Src Mask : 255.255.255.255
Dest Addr : 10.1.1.0 Dest Mask : 255.255.255.0
Tunnel Addr : 151.204.191.xxx Src Port : 0 Dest Port : 0
Protocol : 0 TunnelFilter: Yes
Flags : Outbound
No Name




ifurlender -> RE: VPN to third-party firewall problems (15.Sep.2005 2:30:00 PM)

I got the entire output in a log file. If you want I can send it to you. Please let me know where to send it.

Thanks




ClintD -> RE: VPN to third-party firewall problems (15.Sep.2005 2:39:00 PM)

3 things...

1. Verify if VPN Access is enabled
2. Ensure that the Remote Site you've created only contains the addresses 10.1.1.0 through 10.1.1.255
3. Verify the Internal network contains the addresses of 192.168.1.0 through 192.168.1.255

This is the only time that I have seen ISA break up the filters like this - they're supposed to be very simple filters - like 192.168.1.0/24 to 10.1.1.0/24, but yours are broken up into individual filters

Src Addr : 192.168.1.1 Src Mask : 255.255.255.255
Dest Addr : 10.1.1.0 Dest Mask : 255.255.255.0

Src Addr : 192.168.11.254 Src Mask : 255.255.255.255
Dest Addr : 10.1.1.0 Dest Mask : 255.255.255.0




Page: [1] 2   next >   >>