RE: S2S VPN: why is a new QM SA negotiated every 5 minutes ?

Hi Jim, 

I've tried KB907259 but that does *not* solve the SA Idle Timeout problem. 

In http://forums.isaserver.org/fb.aspx?m=2002001812 there is some discussion
if the re-negotiation of the QM SA could lead to broken TCP connections
within the VPN tunnel. I would like to hear your opinion on this issue. 

Thanks, 
Stefaan

-----Original Message-----
From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx] 
Sent: maandag 2 januari 2006 18:13
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: S2S VPN: why is a new QM SA negotiated every 5
minutes ?

http://www.ISAserver.org

I spoke to the guy that worked that problem and wrote the KB.
He suggested that you try it to see if it works for you.
If so, we can get the KB updated to reflect your findings.

--------------------------------------------
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
--------------------------------------------
-----Original Message-----
From: Stefaan Pouseele [mailto:stefaan.pouseele@xxxxxxxxx]
Sent: Monday, January 02, 2006 4:38 AM
To: [ISAserver.org Discussion List]
Subject: [isalist] S2S VPN: why is a new QM SA negotiated every 5 minutes ?

http://www.ISAserver.org

Hi, 

I observed that if an S2S VPN connection of type IPSec Tunnel is used
between two ISA 2004 servers, or between two Windows 2003 RRAS servers, or
between an ISA 2004 server and a Windows 2003 RRAS server, then every 5
minutes the QM SA is deleted (Event ID 542) and a complete new QM SA is
renegotiated (Event ID 541), even if there is traffic all the time (ping
-t). 

Is this a known issue and is there already a fix available? Also, I assume
that KB907259 You cannot sustain a connection for longer than 3 to 10
minutes between a Windows Server 2003 Service Pack 1-based computer and a
Linux-based computer (http://support.microsoft.com/kb/907259/en-us) has
nothing to do with this issue. Right? 


=== Technical details ===

In the ISA MMC, the summary of the IPSec configuration is: 

--- Begin ---

Local Tunnel Endpoint: 192.168.1.30
Remote Tunnel Endpoint: 192.168.1.10

To allow HTTP proxy or NAT traffic to the remote site, the remote site
configuration must contain the local site tunnel end-point IP address.

IKE Phase I Parameters:
    Mode: Main mode
    Encryption: 3DES
    Integrity: SHA1
    Diffie-Hellman group: Group 2 (1024 bit)
    Authentication method: Pre-shared secret (azerty)
    Security Association lifetime: 28800 seconds 

IKE Phase II Parameters:
    Mode: ESP tunnel mode
    Encryption: 3DES
    Integrity: SHA1
    Perfect Forward Secrecy: ON
    Diffie-Hellman group: Group 2 (1024 bit)
    Time rekeying: ON
    Security Association lifetime: 3600 seconds <<<< one hour !!!
    Kbyte rekeying: OFF

Remote Network 'RemoteSite#22' IP Subnets:
    Subnet: 192.168.1.10/255.255.255.255
    Subnet: 192.168.22.0/255.255.255.0

Local Network 'Internal' IP Subnets:
    Subnet: 192.168.44.0/255.255.255.0

--- End ---

According to
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/T
echR
ef/8fbd7659-ca23-4320-a350-6890049086bc.mspx and
http://www.microsoft.com/windowsserver2003/techinfo/overview/ipsecfaq.ms
px
the default idle timeout for a quick mode SA is 300 seconden. This can be
changed with the following registry key (see
http://support.microsoft.com/default.aspx?scid=kb;en-us;257225): 
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec
    Value name: SAIdleTime
    Data Type: REG_DWORD
    Value data: 300 - 3600 (default=300)

So, it sounds that on a fully patched Windows 2003 SP1, the QM SA idle
timeout function is *not* working very well. A workaround is to set
SAIdleTime=3600, that's the same value as the default QM SA lifetime. In
other words, after maximum one hour a complete new QM SA will be
renegotiated because the session keys must be refreshed in any way. 


Thanks,
Stefaan





Other related posts: