Welcome to ISAserver.org

RE: Discussion of IPSec Tunnel Mode Site to Site VPN

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [ISA Server 2004 Firewall] >> VPN >> RE: Discussion of IPSec Tunnel Mode Site to Site VPN

Page: << < prev 1 2 [3] 4 next > >>

Message

<< Older Topic Newer Topic >>

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 22.Nov.2004 11:19:00 AM

wbplomp

Posts: 138
Joined: 18.Nov.2004
From: Netherlands, The
Status: offline

How can you configure the IPSec tunnel as the default gateway for the Remote/Branch office?
I can only get this work with a subnet defined in the Internal network on ISA Server in the main office.

quote:
Originally posted by tshinder:
This thread is for the ISA 2004 site to site VPN using IPSec tunnel mode article at http://isaserver.org/tutorials/2004ipsectunnelmode.html

Thanks!
Tom

(in reply to tshinder)

Post #: 41

Featured Links*

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 28.Nov.2004 6:02:00 PM

wbplomp

Posts: 138
Joined: 18.Nov.2004
From: Netherlands, The
Status: offline

You are probably using the 0.0.0.0 route as the subnet on the remote site.

quote:
Originally posted by d-zam:
I have a Netgear FVM318 that I am trying to setup an IPSEC tunnel to with ISA 2004. Phase 1 will connect but phase 2 will not. What am I doing wrong. I followed your instructions on how to setup the tunnel in ISA 2004. I can get the router to establish both connections on a Windows 2000 RRAS server but not with ISA 2004 isntalled.

(in reply to tshinder)

Post #: 42

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 6.Dec.2004 3:17:00 AM

jamesprice3

Posts: 10
Joined: 25.Jan.2004
From: FL
Status: offline

Great Article. Like some of the posts I've seen here, I set up the connections as described and the tunnel will come up but I can't get any traffic to pass through the tunnel. I simplified the rule to allow only DNS and DNS Server to pass from the Main to the Branch and vice versa. When I open a web browser or use nslookup, the Branch ISA server logs Result code:

0xc0040014 FWX_E_FWE_SPOOFING_PACKET_DROPPED

What would cause this? I think this may the source of my problems.

(in reply to tshinder)

Post #: 43

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 6.Dec.2004 9:22:00 PM

wbplomp

Posts: 138
Joined: 18.Nov.2004
From: Netherlands, The
Status: offline

You are probably using 0.0.0.0 as the remote network.

(in reply to tshinder)

Post #: 44

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 8.Feb.2005 10:32:00 AM

guavaq

Posts: 1
Joined: 2.Feb.2005
From: South Africa
Status: offline

Hi there I am in the process of setting up a site-to-site VPN using ISA 2004 Standard edition, to a Checkpoint Firewall 4.1 I have set up the remote network, and created the rules. The people on the Checkpoint side can see the tunnel, but say that the data is not encrypting correctly! My question is does the IPSec settings have to be identical with everything for it to work?

(in reply to tshinder)

Post #: 45

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 16.Mar.2005 1:56:00 PM

james@footprintsdev.com

Posts: 5
Joined: 16.Mar.2005
From: UK
Status: offline

Hi Tom,

Very good article which raises a fundemental security question about IPSEC Tunnel Mode using shared-secrets.

I'm currently evaluating ISA 2004 Enterprise Ed. (for its NLB functionality)at our main site. We have several small branch offices which use sub-$200 3rd party VPN gateways and therefore have to connect using IPSEC Tunnel mode using shared-secrets to the ISA 2004 Array. This works fine but having read your article I'm concerned at just how secure this configuration is.

Your article mentioned that Tunnel mode is susceptible to 'Man in the middle' attacks - I just wondered if you would elaborate on this? I don't understand why Microsoft would offer such a solution if it was insecure?

Also, could you comment on how 'easy' it is to crack a shared secret from an ISA 2004 server?

Many thanks,

Jim

(in reply to tshinder)

Post #: 46

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 9.Jul.2005 10:55:00 AM

Paul Mead

Posts: 2
Joined: 9.Jul.2005
From: Europe
Status: offline

Hi,
I am trying to get a cisco 831 or linksys ethernet VPN router BEFVP41 to work with 2003 server at the other end.

Phase 1 IKE works fine, but phase 2/Quick mode fails during negotiation(in both cases). The oakley log on the 2003 server implies that it (2003 server) is at fault as it cannot match a policy to the SA suggested by the linksys/cisco router.

My aim is to use the cisco router, but I am currently using the linksys router for comparision and to try to prove that it is the 2003 server settings which are not working.

I have configured the 2003 server as per microsoft article KB816514, using two subnet definitions. I have seen elsewhere a comment that W2003 negotiates phase II/Quick mode differently to most RFC imterpretations and thus may need extra SA definitions/filters as a consequence. Can anyone help me (If have spent the best part of 3 days on this and urgently need to sort) - TIA.

Network A=10.10.10.0 Mask=255.255.255.248
Linksys local ip: 10.10.10.1
Linksys public ip: 81.154.76.80
Test PC: 10.10.10.2

Network B=10.0.96.0 Mask=255.255.252.0
Windows 2003 Server local ip: 10.0.98.101
Windows 2003 public ip: 194.106.63.149

Please find below the oakly log:
7-09: 15:07:35:515:264
7-09: 15:07:35:515:264 Receive: (get) SA = 0x00000000 from 81.154.76.80.500
7-09: 15:07:35:515:264 ISAKMP Header: (V1.0), len = 192
7-09: 15:07:35:515:264 I-COOKIE c3169724f6d9eafb
7-09: 15:07:35:515:264 R-COOKIE 0000000000000000
7-09: 15:07:35:515:264 exchange: Oakley Main Mode
7-09: 15:07:35:515:264 flags: 0
7-09: 15:07:35:515:264 next payload: SA
7-09: 15:07:35:515:264 message ID: 00000000
7-09: 15:07:35:515:264 Filter to match: Src 81.154.76.80 Dst 10.0.98.101
7-09: 15:07:35:515:264 MM PolicyName: 2
7-09: 15:07:35:515:264 MMPolicy dwFlags 2 SoftSAExpireTime 28800
7-09: 15:07:35:515:264 MMOffer[0] LifetimeSec 28800 QMLimit 1 DHGroup 2
7-09: 15:07:35:515:264 MMOffer[0] Encrypt: Triple DES CBC Hash: SHA
7-09: 15:07:35:515:264 MMOffer[1] LifetimeSec 28800 QMLimit 1 DHGroup 2
7-09: 15:07:35:515:264 MMOffer[1] Encrypt: Triple DES CBC Hash: MD5
7-09: 15:07:35:515:264 MMOffer[2] LifetimeSec 28800 QMLimit 1 DHGroup 1
7-09: 15:07:35:515:264 MMOffer[2] Encrypt: DES CBC Hash: SHA
7-09: 15:07:35:515:264 MMOffer[3] LifetimeSec 28800 QMLimit 1 DHGroup 1
7-09: 15:07:35:515:264 MMOffer[3] Encrypt: DES CBC Hash: MD5
7-09: 15:07:35:515:264 Auth[0]:PresharedKey KeyLen 18
7-09: 15:07:35:531:264 Responding with new SA 382dba0
7-09: 15:07:35:531:264 processing payload SA
7-09: 15:07:35:531:264 Received Phase 1 Transform 1
7-09: 15:07:35:531:264 Encryption Alg Triple DES CBC(5)
7-09: 15:07:35:531:264 Hash Alg SHA(2)
7-09: 15:07:35:531:264 Auth Method Preshared Key(1)
7-09: 15:07:35:531:264 Oakley Group 2
7-09: 15:07:35:531:264 Life type in Seconds
7-09: 15:07:35:531:264 Life duration of 28800
7-09: 15:07:35:531:264 Received Phase 1 Transform 2
7-09: 15:07:35:531:264 Encryption Alg DES CBC(1)
7-09: 15:07:35:531:264 Hash Alg MD5(1)
7-09: 15:07:35:531:264 Auth Method Preshared Key(1)
7-09: 15:07:35:531:264 Oakley Group 1
7-09: 15:07:35:531:264 Life type in Seconds
7-09: 15:07:35:531:264 Life duration of 28800
7-09: 15:07:35:531:264 Received Phase 1 Transform 3
7-09: 15:07:35:531:264 Encryption Alg Triple DES CBC(5)
7-09: 15:07:35:531:264 Hash Alg SHA(2)
7-09: 15:07:35:531:264 Auth Method Preshared Key(1)
7-09: 15:07:35:531:264 Oakley Group 2
7-09: 15:07:35:531:264 Life type in Seconds
7-09: 15:07:35:531:264 Life duration of 28800
7-09: 15:07:35:531:264 Received Phase 1 Transform 4
7-09: 15:07:35:531:264 Encryption Alg Triple DES CBC(5)
7-09: 15:07:35:531:264 Hash Alg MD5(1)
7-09: 15:07:35:531:264 Auth Method Preshared Key(1)
7-09: 15:07:35:531:264 Oakley Group 2
7-09: 15:07:35:531:264 Life type in Seconds
7-09: 15:07:35:531:264 Life duration of 28800
7-09: 15:07:35:531:264 Phase 1 SA accepted: transform=1
7-09: 15:07:35:531:264 SA - Oakley proposal accepted
7-09: 15:07:35:531:264 ClearFragList
7-09: 15:07:35:531:264 constructing ISAKMP Header
7-09: 15:07:35:531:264 constructing SA (ISAKMP)
7-09: 15:07:35:531:264 Constructing Vendor MS NT5 ISAKMPOAKLEY
7-09: 15:07:35:531:264 Constructing Vendor FRAGMENTATION
7-09: 15:07:35:531:264 Constructing Vendor draft-ietf-ipsec-nat-t-ike-02
7-09: 15:07:35:531:264
7-09: 15:07:35:531:264 Sending: SA = 0x0382DBA0 to 81.154.76.80:Type 2.500
7-09: 15:07:35:531:264 ISAKMP Header: (V1.0), len = 148
7-09: 15:07:35:531:264 I-COOKIE c3169724f6d9eafb
7-09: 15:07:35:531:264 R-COOKIE 8e86155e061eea21
7-09: 15:07:35:531:264 exchange: Oakley Main Mode
7-09: 15:07:35:531:264 flags: 0
7-09: 15:07:35:531:264 next payload: SA
7-09: 15:07:35:531:264 message ID: 00000000
7-09: 15:07:35:531:264 Ports S:f401 D:f401
7-09: 15:07:36:31:264
7-09: 15:07:36:31:264 Receive: (get) SA = 0x0382dba0 from 81.154.76.80.500
7-09: 15:07:36:31:264 ISAKMP Header: (V1.0), len = 184
7-09: 15:07:36:31:264 I-COOKIE c3169724f6d9eafb
7-09: 15:07:36:31:264 R-COOKIE 8e86155e061eea21
7-09: 15:07:36:31:264 exchange: Oakley Main Mode
7-09: 15:07:36:31:264 flags: 0
7-09: 15:07:36:31:264 next payload: KE
7-09: 15:07:36:31:264 message ID: 00000000
7-09: 15:07:36:31:264 processing payload KE
7-09: 15:07:36:78:264 processing payload NONCE
7-09: 15:07:36:78:264 ClearFragList
7-09: 15:07:36:78:264 constructing ISAKMP Header
7-09: 15:07:36:78:264 constructing KE
7-09: 15:07:36:78:264 constructing NONCE (ISAKMP)
7-09: 15:07:36:78:264
7-09: 15:07:36:78:264 Sending: SA = 0x0382DBA0 to 81.154.76.80:Type 2.500
7-09: 15:07:36:78:264 ISAKMP Header: (V1.0), len = 184
7-09: 15:07:36:78:264 I-COOKIE c3169724f6d9eafb
7-09: 15:07:36:78:264 R-COOKIE 8e86155e061eea21
7-09: 15:07:36:78:264 exchange: Oakley Main Mode
7-09: 15:07:36:78:264 flags: 0
7-09: 15:07:36:78:264 next payload: KE
7-09: 15:07:36:78:264 message ID: 00000000
7-09: 15:07:36:78:264 Ports S:f401 D:f401
7-09: 15:07:36:562:264
7-09: 15:07:36:562:264 Receive: (get) SA = 0x0382dba0 from 81.154.76.80.500
7-09: 15:07:36:562:264 ISAKMP Header: (V1.0), len = 68
7-09: 15:07:36:562:264 I-COOKIE c3169724f6d9eafb
7-09: 15:07:36:562:264 R-COOKIE 8e86155e061eea21
7-09: 15:07:36:562:264 exchange: Oakley Main Mode
7-09: 15:07:36:562:264 flags: 1 ( encrypted )
7-09: 15:07:36:562:264 next payload: ID
7-09: 15:07:36:562:264 message ID: 00000000
7-09: 15:07:36:562:264 processing payload ID
7-09: 15:07:36:562:264 processing payload HASH
7-09: 15:07:36:562:264 AUTH: Phase I authentication accepted
7-09: 15:07:36:562:264 ClearFragList
7-09: 15:07:36:562:264 constructing ISAKMP Header
7-09: 15:07:36:562:264 constructing ID
7-09: 15:07:36:562:264 MM ID Type 1
7-09: 15:07:36:562:264 MM ID 0a006265
7-09: 15:07:36:562:264 constructing HASH
7-09: 15:07:36:562:264 MM established. SA: 0382DBA0
7-09: 15:07:36:562:264
7-09: 15:07:36:562:264 Sending: SA = 0x0382DBA0 to 81.154.76.80:Type 2.500
7-09: 15:07:36:562:264 ISAKMP Header: (V1.0), len = 68
7-09: 15:07:36:562:264 I-COOKIE c3169724f6d9eafb
7-09: 15:07:36:562:264 R-COOKIE 8e86155e061eea21
7-09: 15:07:36:562:264 exchange: Oakley Main Mode
7-09: 15:07:36:562:264 flags: 1 ( encrypted )
7-09: 15:07:36:562:264 next payload: ID
7-09: 15:07:36:562:264 message ID: 00000000
7-09: 15:07:36:562:264 Ports S:f401 D:f401
7-09: 15:07:36:609:264
7-09: 15:07:36:609:264 Receive: (get) SA = 0x0382dba0 from 81.154.76.80.500
7-09: 15:07:36:609:264 ISAKMP Header: (V1.0), len = 164
7-09: 15:07:36:609:264 I-COOKIE c3169724f6d9eafb
7-09: 15:07:36:609:264 R-COOKIE 8e86155e061eea21
7-09: 15:07:36:609:264 exchange: Oakley Quick Mode
7-09: 15:07:36:609:264 flags: 1 ( encrypted )
7-09: 15:07:36:609:264 next payload: HASH
7-09: 15:07:36:609:264 message ID: c3878c6e
7-09: 15:07:36:609:264 processing HASH (QM)
7-09: 15:07:36:609:264 ClearFragList
7-09: 15:07:36:609:264 processing payload NONCE
7-09: 15:07:36:609:264 processing payload ID
7-09: 15:07:36:609:264 processing payload ID
7-09: 15:07:36:609:264 processing payload SA
7-09: 15:07:36:609:264 Negotiated Proxy ID: Src 10.10.10.0.0 Dst 10.0.96.0.0
7-09: 15:07:36:609:264 Src id for subnet. Mask 255.255.255.248
7-09: 15:07:36:609:264 Dst id for subnet. Mask 255.255.252.0
7-09: 15:07:36:609:264 Checking Proposal 1: Proto= ESP(3), num trans=1 Next=0
7-09: 15:07:36:609:264 Checking Transform # 1: ID=Triple DES CBC(3)
7-09: 15:07:36:609:264 SA life type in seconds
7-09: 15:07:36:609:264 SA life duration 00000e10
7-09: 15:07:36:609:264 tunnel mode is Tunnel Mode(1)
7-09: 15:07:36:609:264 HMAC algorithm is SHA(2)
7-09: 15:07:36:609:264 Finding Responder Policy for SRC=10.10.10.0.0000 DST=10.0.96.0.0000, SRCMask=255.255.255.248, DSTMask=255.255.252.0, Prot=0 InTunnelEndpt 6562000a OutTunnelEndpt 504c9a51
7-09: 15:07:36:609:264 Failed to get TunnelPolicy 13015
7-09: 15:07:36:609:264 Responder failed to match filter(Phase II) 13015
7-09: 15:07:36:609:264 Data Protection Mode (Quick Mode)
7-09: 15:07:36:609:264 Source IP Address 10.0.96.0 Source IP Address Mask 255.255.255.248 Destination IP Address 10.10.10.0 Destination IP Address Mask 255.255.252.0 Protocol 0 Source Port 0 Destination Port 0 IKE Local Addr 10.0.98.101 IKE Peer Addr 81.154.76.80 IKE Source Port 500 IKE Destination Port 500 Peer Private Addr
7-09: 15:07:36:609:264 Preshared key ID. Peer IP Address: 81.154.76.80
7-09: 15:07:36:609:264 Me
7-09: 15:07:36:609:264 No policy configured
7-09: 15:07:36:609:264 Processed third (ID) payload Responder. Delta Time 1 0x0 0x0
7-09: 15:07:36:609:264 isadb_set_status sa:0382DBA0 centry:03831090 status 3601
7-09: 15:07:36:609:264 ProcessFailure: sa:0382DBA0 centry:03831090 status:3601
7-09: 15:07:36:609:264 constructing ISAKMP Header
7-09: 15:07:36:609:264 constructing HASH (null)
7-09: 15:07:36:609:264 constructing NOTIFY 18
7-09: 15:07:36:609:264 constructing HASH (Notify/Delete)
7-09: 15:07:36:609:264
7-09: 15:07:36:609:264 Sending: SA = 0x0382DBA0 to 81.154.76.80:Type 1.500
7-09: 15:07:36:609:264 ISAKMP Header: (V1.0), len = 68
7-09: 15:07:36:609:264 I-COOKIE c3169724f6d9eafb
7-09: 15:07:36:609:264 R-COOKIE 8e86155e061eea21
7-09: 15:07:36:609:264 exchange: ISAKMP Informational Exchange
7-09: 15:07:36:609:264 flags: 1 ( encrypted )
7-09: 15:07:36:609:264 next payload: HASH
7-09: 15:07:36:609:264 message ID: f439e2b5
7-09: 15:07:36:609:264 Ports S:f401 D:f401

TIA

Paul.

(in reply to tshinder)

Post #: 47

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 11.Jul.2005 2:29:00 AM

ClintD

Posts: 1833
Joined: 26.Jan.2001
From: Keller, TX
Status: offline

Include the 81.154.76.80 address into the properties of the Remote Site on the Addresses tab.

(in reply to tshinder)

Post #: 48

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 5.Aug.2005 6:02:00 AM

EMademlis

Posts: 6
Joined: 1.Mar.2004
Status: offline

Hello, Tom.

Great article, as usual!
I'm in the process of placing MSISA2004 on our different european sites. Our Main office is already running the EE of MSISA2004. Branch offices are still running Watchguard SOHO6tc firewalls...

I have a senario where I can't establish the IPSec tunnel from the MSISA2004 to the SOHO6tc but the link from the SOHO6tc to MS-ISA-2004 establishes correctly, so from the remote site I can ping machines at the MAIN office.

This is the topology:
[EDGE] <--> [NAT BOX] <--> [INTERNET] <--> [NAT BOX] <--> [MSISA2004]

Both ISP's NAT boxes are assigned with static public IP addresses and traffic is forwarded to the EDGE's and MSISA2004's external IP addresses.

SOHO6tc's IP addresses:
EXT: 192.168.254.1
SM: 255.255.255.0
DG: 192.168.254.254

INT: 192.168.11.254
SM: 255.255.254.0

MICROSOFT ISA SERVER 2004 IP addresses:
EXT: 192.168.104.1
SM: 255.255.255.0
DG: 192.168.104.254

INT: 192.168.4.254
SM: 255.255.254.0

My problem is the following:
Traffic initializes correctly from MSISA2004 but security negotiation does not succeed.
At the SOHO6tc's side I've opened UDP port 4500 and forwarded traffic to its internal address. Could that be the issue of the negotiation time out? I don't have the possibility to configure it for a range of addresses.
Also, I have included external IP addresses on both ends for the addresses' range definition but the problem still persists. I wonder what else can be missing(?)

On MSISA2004's logs the following event appears:

============================================
IKE security association negotiation failed.
Mode:
Data Protection Mode (Quick Mode)
Filter:
Source IP Address 192.168.4.0
Source IP Address Mask 255.255.254.0
Destination IP Address 192.168.10.0
Destination IP Address Mask 255.255.254.0
Protocol 0
Source Port 0
Destination Port 0
IKE Local Addr 192.168.104.1
IKE Peer Addr 2.2.2.2
IKE Source Port 4500
IKE Destination Port 4500
Peer Private Addr
Peer Identity:
Preshared key ID.
Peer IP Address: 2.2.2.2

Failure Point:
Me
Failure Reason:
Negotiation timed out
Extra Status:
Processed third (ID) payload
Initiator. Delta Time 63
0x0 0x0
=============================================

Any troubleshooting hints will be mostly appreciated.

Regards

EM

(in reply to tshinder)

Post #: 49

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 5.Aug.2005 8:39:00 AM

ClintD

Posts: 1833
Joined: 26.Jan.2001
From: Keller, TX
Status: offline

quote:
At the SOHO6tc's side I've opened UDP port 4500 and forwarded traffic to its internal address

Did you include UDP 500 as well? UDP 500 is used for the first 4 packets of IKE negotiations before switching to UDP 4500 (for the remaining 6 packets) if a NAT is involved.

If you have forwarded UDP 500, then run the following at a command prompt on the ISA Server (c:\netsh ipsec static set config ikelogging 1) and after it compeltes, attempt to communicate between the Local and Remote subnets. Once it fails, post the contents of the c:\Windows\Debug\oakley.log file.

Note : you are about the 6th person to post on the list that they have problems with Watchguard and ISA. Other folks have reported problems with other vendors devices and I've been able to get them working, but the folks that use Watchguard either stop posting or never follow up to say whether or not it works. What I'm trying to say is that Watchguard is the only device that I'm not 100% sure if it works well with ISA 2004.

[ August 05, 2005, 08:45 AM: Message edited by: ClintD ]

(in reply to tshinder)

Post #: 50

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 5.Aug.2005 10:40:00 AM

EMademlis

Posts: 6
Joined: 1.Mar.2004
Status: offline

Many thanks for your reply ClintD.

I've already contacted Watchguard providing them all the necessary information and printscreens to help them investigate this issue.

Yes, UDP port 500 at Watchguard is open and redirected to its internal interface, that is 192.168.11.254.

At MSISA2004, I've enabled Oakley logging and isssued a "ping -t" to initiate the tunnel; here is the output:

=================================================
8-05: 16:19:32:20:f60 Creating socket directly on MS base provider. Bypassing LSPs
8-05: 16:19:32:20:f60 Creating socket directly on MS base provider. Bypassing LSPs
8-05: 16:19:32:20:f60 Creating socket directly on MS base provider. Bypassing LSPs
8-05: 16:19:32:20:f60 Initialization OK
8-05: 16:20:26:756:f34 Invalid Isakmp Version in header
8-05: 16:20:26:756:f34 Invalid Isakmp Version in header
8-05: 16:20:26:756:f34 Invalid Exchange Type
8-05: 16:20:26:756:f34 Bad length in header. Hdrlen:1159495236 PacketSize 120
8-05: 16:20:26:756:f34 SanityCheckHeader failed 3600 errs 7
8-05: 16:21:28:758:f34 Invalid Isakmp Version in header
8-05: 16:21:28:758:f34 Invalid Exchange Type
8-05: 16:21:28:758:f34 Invalid Flags
8-05: 16:21:28:758:f34 Bad length in header. Hdrlen:1971894620 PacketSize 120
8-05: 16:21:28:758:f34 SanityCheckHeader failed 3600 errs d
8-05: 16:21:40:586:f34
8-05: 16:21:40:586:f34 Receive: (get) SA = 0x00000000 from 81.240.253.102.500
8-05: 16:21:40:586:f34 ISAKMP Header: (V1.0), len = 172
8-05: 16:21:40:586:f34 I-COOKIE 02d73a7d57326142
8-05: 16:21:40:586:f34 R-COOKIE 0000000000000000
8-05: 16:21:40:586:f34 exchange: Oakley Main Mode
8-05: 16:21:40:586:f34 flags: 0
8-05: 16:21:40:586:f34 next payload: SA
8-05: 16:21:40:586:f34 message ID: 00000000
8-05: 16:21:40:586:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:21:40:586:f34 MatchMMFilter failed 13013
8-05: 16:21:40:586:f34 Responding with new SA 0
8-05: 16:21:40:586:f34 HandleFirstPacketResponder failed 3601
8-05: 16:21:52:571:f34
8-05: 16:21:52:571:f34 Receive: (get) SA = 0x00000000 from 81.240.253.102.500
8-05: 16:21:52:571:f34 ISAKMP Header: (V1.0), len = 172
8-05: 16:21:52:571:f34 I-COOKIE 02d73a7d57326142
8-05: 16:21:52:571:f34 R-COOKIE 0000000000000000
8-05: 16:21:52:571:f34 exchange: Oakley Main Mode
8-05: 16:21:52:571:f34 flags: 0
8-05: 16:21:52:571:f34 next payload: SA
8-05: 16:21:52:571:f34 message ID: 00000000
8-05: 16:21:52:571:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:21:52:587:f34 MatchMMFilter failed 13013
8-05: 16:21:52:587:f34 Responding with new SA 0
8-05: 16:21:52:587:f34 HandleFirstPacketResponder failed 3601
8-05: 16:22:04:572:f34
8-05: 16:22:04:572:f34 Receive: (get) SA = 0x00000000 from 81.240.253.102.500
8-05: 16:22:04:572:f34 ISAKMP Header: (V1.0), len = 172
8-05: 16:22:04:572:f34 I-COOKIE 02d73a7d57326142
8-05: 16:22:04:572:f34 R-COOKIE 0000000000000000
8-05: 16:22:04:572:f34 exchange: Oakley Main Mode
8-05: 16:22:04:572:f34 flags: 0
8-05: 16:22:04:572:f34 next payload: SA
8-05: 16:22:04:572:f34 message ID: 00000000
8-05: 16:22:04:572:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:22:04:587:f34 MatchMMFilter failed 13013
8-05: 16:22:04:587:f34 Responding with new SA 0
8-05: 16:22:04:587:f34 HandleFirstPacketResponder failed 3601
8-05: 16:22:16:572:f34
8-05: 16:22:16:572:f34 Receive: (get) SA = 0x00000000 from 81.240.253.102.500
8-05: 16:22:16:572:f34 ISAKMP Header: (V1.0), len = 172
8-05: 16:22:16:572:f34 I-COOKIE 02d73a7d57326142
8-05: 16:22:16:572:f34 R-COOKIE 0000000000000000
8-05: 16:22:16:572:f34 exchange: Oakley Main Mode
8-05: 16:22:16:572:f34 flags: 0
8-05: 16:22:16:572:f34 next payload: SA
8-05: 16:22:16:572:f34 message ID: 00000000
8-05: 16:22:16:572:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:22:16:572:f34 MatchMMFilter failed 13013
8-05: 16:22:16:572:f34 Responding with new SA 0
8-05: 16:22:16:572:f34 HandleFirstPacketResponder failed 3601
8-05: 16:22:28:572:f34
8-05: 16:22:28:572:f34 Receive: (get) SA = 0x00000000 from 81.240.253.102.500
8-05: 16:22:28:572:f34 ISAKMP Header: (V1.0), len = 172
8-05: 16:22:28:572:f34 I-COOKIE 02d73a7d57326142
8-05: 16:22:28:572:f34 R-COOKIE 0000000000000000
8-05: 16:22:28:572:f34 exchange: Oakley Main Mode
8-05: 16:22:28:572:f34 flags: 0
8-05: 16:22:28:572:f34 next payload: SA
8-05: 16:22:28:572:f34 message ID: 00000000
8-05: 16:22:28:572:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:22:28:572:f34 MatchMMFilter failed 13013
8-05: 16:22:28:572:f34 Responding with new SA 0
8-05: 16:22:28:572:f34 HandleFirstPacketResponder failed 3601
8-05: 16:22:30:744:f34 Invalid Isakmp Version in header
8-05: 16:22:30:744:f34 Invalid Exchange Type
8-05: 16:22:30:744:f34 Bad length in header. Hdrlen:-491534754 PacketSize 120
8-05: 16:22:30:744:f34 SanityCheckHeader failed 3600 errs 6
8-05: 16:22:40:573:f34
8-05: 16:22:40:573:f34 Receive: (get) SA = 0x00000000 from 81.240.253.102.500
8-05: 16:22:40:573:f34 ISAKMP Header: (V1.0), len = 172
8-05: 16:22:40:573:f34 I-COOKIE 02d73a7d57326142
8-05: 16:22:40:573:f34 R-COOKIE 0000000000000000
8-05: 16:22:40:573:f34 exchange: Oakley Main Mode
8-05: 16:22:40:573:f34 flags: 0
8-05: 16:22:40:573:f34 next payload: SA
8-05: 16:22:40:573:f34 message ID: 00000000
8-05: 16:22:40:573:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:22:40:573:f34 MatchMMFilter failed 13013
8-05: 16:22:40:573:f34 Responding with new SA 0
8-05: 16:22:40:573:f34 HandleFirstPacketResponder failed 3601
8-05: 16:23:32:762:f34
8-05: 16:23:32:762:f34 Receive: (get) SA = 0x00000000 from 81.240.253.102.500
8-05: 16:23:32:762:f34 ISAKMP Header: (V1.0), len = 172
8-05: 16:23:32:762:f34 I-COOKIE a79cee2b211d91b1
8-05: 16:23:32:762:f34 R-COOKIE 0000000000000000
8-05: 16:23:32:762:f34 exchange: Oakley Main Mode
8-05: 16:23:32:762:f34 flags: 0
8-05: 16:23:32:762:f34 next payload: SA
8-05: 16:23:32:762:f34 message ID: 00000000
8-05: 16:23:32:762:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:23:32:762:f34 MatchMMFilter failed 13013
8-05: 16:23:32:762:f34 Responding with new SA 0
8-05: 16:23:32:762:f34 HandleFirstPacketResponder failed 3601
8-05: 16:23:43:559:f34
8-05: 16:23:43:559:f34 Receive: (get) SA = 0x00000000 from 81.240.253.102.500
8-05: 16:23:43:559:f34 ISAKMP Header: (V1.0), len = 172
8-05: 16:23:43:559:f34 I-COOKIE a79cee2b211d91b1
8-05: 16:23:43:559:f34 R-COOKIE 0000000000000000
8-05: 16:23:43:559:f34 exchange: Oakley Main Mode
8-05: 16:23:43:559:f34 flags: 0
8-05: 16:23:43:559:f34 next payload: SA
8-05: 16:23:43:559:f34 message ID: 00000000
8-05: 16:23:43:559:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:23:43:575:f34 MatchMMFilter failed 13013
8-05: 16:23:43:575:f34 Responding with new SA 0
8-05: 16:23:43:575:f34 HandleFirstPacketResponder failed 3601
8-05: 16:23:55:559:f34
8-05: 16:23:55:559:f34 Receive: (get) SA = 0x00000000 from 81.240.253.102.500
8-05: 16:23:55:559:f34 ISAKMP Header: (V1.0), len = 172
8-05: 16:23:55:559:f34 I-COOKIE a79cee2b211d91b1
8-05: 16:23:55:559:f34 R-COOKIE 0000000000000000
8-05: 16:23:55:559:f34 exchange: Oakley Main Mode
8-05: 16:23:55:559:f34 flags: 0
8-05: 16:23:55:559:f34 next payload: SA
8-05: 16:23:55:559:f34 message ID: 00000000
8-05: 16:23:55:559:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:23:55:575:f34 MatchMMFilter failed 13013
8-05: 16:23:55:575:f34 Responding with new SA 0
8-05: 16:23:55:575:f34 HandleFirstPacketResponder failed 3601
=================================================

Regarding Tom's article and Microsoft's recommendations I have some issues to clarify, especially for my case where both firewalls seat behind NAT boxes.
On the ISA2004 server, when defining the IP addresses of the Remote Site Network, under the "Connection" tab; which IP address should be used as "LOCAL VPN GATEWAY IP ADDRESS"? The NAT boxes EXTERNAL public static address or ISA's EXTERNAL private IP address?

This is something that I couldn't clarify when reading Tom's article.

Remote Site should be able to locate the Local Site; this is possible only with public IP addresses, so I presume that I should use my local site's PUBLIC IP as "Local VPN gateway IP address".
I couldn't find accurate information about this and it is still a vague issue. How does ISA handle this?

From the other site, at Watchguard's configuration interface page, it is clearly stated that public IP addresses should be used for local & remote gateways and there is an option to specify whether local or remote site seat behind NAT boxes.

Remember that the NAT box forwards all traffic to ISA or to Watchguard respectively.

Thanks in advance for your help.
Regards.

EM

(in reply to tshinder)

Post #: 51

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 5.Aug.2005 2:02:00 PM

ClintD

Posts: 1833
Joined: 26.Jan.2001
From: Keller, TX
Status: offline

Your scenario is somewhat unique in that the endpoints are both behind NAT devices, so your question is dead-on the money. You have to specify ISA's external IP (the 192 address) in the Connections tab as this is where ISA will be listening.

But, in the Addresses tab, you should include the NAT'd IP as this is where the requests will appear to come from, as far as the IPSec Tunnel itself is concerned.

You can see it is needed here, in this excerpt from the oakley log...

quote:

8-05: 16:21:40:586:f34 Filter to match: Src 81.240.253.102 Dst 192.168.104.1
8-05: 16:21:40:586:f34 MatchMMFilter failed 13013
8-05: 16:21:40:586:f34 Responding with new SA 0
8-05: 16:21:40:586:f34 HandleFirstPacketResponder failed 3601
quote:

The Source is 81.240.253.102 and this most likely not in the properties of the Remote Site. Likewise, you'll need to add ISA's NAT'd IP into the Watchguard config.

[ August 05, 2005, 02:07 PM: Message edited by: ClintD ]

(in reply to tshinder)

Post #: 52

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 6.Aug.2005 7:12:00 AM

EMademlis

Posts: 6
Joined: 1.Mar.2004
Status: offline

Hello ClintD and thanks for the information.

You were right, I had to use ISA's external private IP address as "Local gateway VPN end point" and not the static public address assigned to NAT box's external interface.
Directly after correcting this parameter, things got better. I also had to make this change at the watchguard as well.

Now, the tunnel initiates and I can ping sites from both ends. BUT, security negotiation keeps failing on both ends.
I have the same error message on both firewalls: "No policy defined". I can't figure out what can still be missing since networks are defined correctly including internal and public IP addresses, IPSec security parameters are identical and UDP ports 4500 and 500 are operational.

In the addresses' range, should I include the "external networks" for both sites? I mean the IP addresses used for the external interfaces on the firewalls; that is 192.168.254.0/24 for watchguard appliance and 192.168.104.0/24 for the ISA server. Since both firewalls seat behind NAT boxes this is necessary for forwarding traffic to the NAT's internal interface, which is used as default gateway.

Yes, it's quite a complicated scenario, but there must be a way to make it work. ISP does not disable "NAT" on the NAT box; they simply forward traffic to an internal address. There is a much higher price to pay for getting direct public IP addresses!

All the best.

EM

(in reply to tshinder)

Post #: 53

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 8.Aug.2005 7:07:00 PM

jmadlock

Posts: 2
Joined: 8.Aug.2005
From: Hope, AR
Status: offline

We are having a major problem with this. Actually, the PPTP protocol. We have 6 sites...5 connected to a central hub all over T1. We were working great with ISA 2000. Routing was beautiful. We upgraded to Server 2003 and ISA 2004 with SP1 on Saturday. Each site can now contact ADMIN (central Hub) but cannot see the other connected networks.

Admin (central Hub) 192.168.0.0-192.168.0.255
255.255.255.0
HHS 192.168.4.0-192.168.5.255
255.255.254.0
YMS 192.168.10.0-192.168.10.255
255.255.255.0
BHE 192.168.15.0-192.168.15.255
255.255.255.0
CPS 192.168.20.0-192.168.21.255
255.255.254.0
GAS 192.168.25.0-192.168.25.255
255.255.255.0

We have contacted Microsoft on Sunday. They could not fix the problem. Possibly due to our inexperience in talking to support people. Our problem seems to reside in RRAS. The routing table is very wrong. When one site attempts to reach another site, they go outside and not to the internal private network. We are not sure how to configure ISA to alleviate the problem. We miss the old LAT table from ISA 2000.

Any help would be greatly appreciated.

(in reply to tshinder)

Post #: 54

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 24.Oct.2005 7:03:00 AM

Guest

Does anyone have any doco on IOS - ISA2004 Site to Site ?

Cheers
Peter.

(in reply to tshinder)

Post #: 55

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 25.Oct.2005 5:28:00 AM

tshinder

Posts: 47490
Joined: 10.Jan.2001
From: Texas
Status: offline

quote:
Originally posted by jmadlock:
We are having a major problem with this. Actually, the PPTP protocol. We have 6 sites...5 connected to a central hub all over T1. We were working great with ISA 2000. Routing was beautiful. We upgraded to Server 2003 and ISA 2004 with SP1 on Saturday. Each site can now contact ADMIN (central Hub) but cannot see the other connected networks.

Admin (central Hub) 192.168.0.0-192.168.0.255
255.255.255.0
HHS 192.168.4.0-192.168.5.255
255.255.254.0
YMS 192.168.10.0-192.168.10.255
255.255.255.0
BHE 192.168.15.0-192.168.15.255
255.255.255.0
CPS 192.168.20.0-192.168.21.255
255.255.254.0
GAS 192.168.25.0-192.168.25.255
255.255.255.0

We have contacted Microsoft on Sunday. They could not fix the problem. Possibly due to our inexperience in talking to support people. Our problem seems to reside in RRAS. The routing table is very wrong. When one site attempts to reach another site, they go outside and not to the internal private network. We are not sure how to configure ISA to alleviate the problem. We miss the old LAT table from ISA 2000.

Any help would be greatly appreciated.

Hi J,

I thought I covered this in the ISA 2004 VPN deployment kit?

Tom

(in reply to tshinder)

Post #: 56

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 1.Apr.2006 5:52:57 PM

kim2005

Posts: 5
Joined: 14.Nov.2005
Status: offline

Hi there,

Hopefully there are someone in this forum that can help me with this issue.

I have set up a branch office with a ISA 2004 which have a IPSec Site-to-Site VPN to a ISA 2004 at our main office.

I'm well aware that if you're using two ISA firewalls for the site to site VPN, then use L2TP/IPSec, NOT IPSec tunnel mode. IPSec tunnel mode is much less secure than L2TP/IPSec.

But I have had a lot of problems getting L2TP/IPSec to work and don't have the time to solve them so I had to make a much less secure solution and are therefore using IPSec.

I want the branch office clients to access the Internet via the main office ISA firewall? But how do I set that up?

Regards,
Kim Soerensen

(in reply to tshinder)

Post #: 57

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 17.Apr.2006 7:09:03 PM

crashadder

Posts: 6
Joined: 22.Nov.2005
Status: offline

hi there Tom,
Seriously great article about ipsec tunnel vpn which was not available in 2000. Anyway as a network administrator before i actually deployed site to site vpn i just wanted to test it in a virtual pc environment. However it didnt work. config is as follows.

Main office
isa gateway 172.16.1.1 /24
subnet 192.168.1.0 /24

Branch office
isa gateway 172.16.1.2 /24
subnet 10.2.1.0 /24

The problem is that i can not access to branch office from main office or the opposite.
The access rules allow all protocols from main to branch and branch to main for all users.
network rule is Route from internal to branch and internal to main (inthe branch office)

When i checked the monitoring i see an error stating that route table should be updated before making ipsec site to site. that error is also in the event viewer. As far as i know when there is no default gateway defined on the isa servers external interface a routing problem might occur. so i added static routes but still no luck. Is RSAS necessary on this scenerio ? what about vpn client access ? has it got anything to do with that ?

Thanks

(in reply to tshinder)

Post #: 58

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 17.Apr.2006 7:49:08 PM

ClintD

Posts: 1833
Joined: 26.Jan.2001
From: Keller, TX
Status: offline

Since the ISA Servers are on the same IP segment externally, you need to add a route on each for the opposing subnet. For example, on Main Office ISA, you'll need...

route add 10.2.1.0 mask 255.255.255.0 172.16.1.2 -p

While on Brnch Office ISA you'll need

route add 192.168.1.0 mask 255.255.255.0 172.16.1.1 -p

The reason for this is described in Stefaan's thread here.
http://forums.isaserver.org/m_2002001759/mpage_1/key_ipsec/tm.htm#2002008148

In essence, the route decision is made prior to the packet being sent to IPSec, which places another IP header on the packet making the original route decision invalid.

(in reply to crashadder)

Post #: 59

RE: Discussion of IPSec Tunnel Mode Site to Site VPN - 18.Apr.2006 10:29:41 PM