Victor B. Berdin wrote:
<snip>Hello everyone,I've upgraded my DS 2.2.19 to 2.2.20 and built the current FSwan1.99 with x509 to my kernel. Everything works fine if I were to use FSwan to FSwan Sub2Sub VPN (either by PSK or RSA/Certs). My problem is that, when I InterOp my LRP machine to a WIN2K, a tunnel gets formed, but it seems that it dies down (the active tunnel / association in ipsecmon disappears) after a few minutes. And to top it all, I can't "ping" from either subnet. It's not really a LEAF problem as everything works perfectly using a FSwan to FSwan setup. I believe the problem lies on my WIN2K side. I'm just hoping someone here will be kind enough to shed any hints concerning M$ WIN2K. Anyways, here's what I have on my WIN2K: Security Method: Negotiate Security Session Key PFS Custom MD5 3DES
I guess this is all OK, I don't really know that much about setting up IPSec on windows boxen.
The one thing I can point out is the 3DES entry. IIRC, you have to install a patch to Win2K to be able to run 3DES, even though the check-box is there regardless. FreeS/WAN will *NOT* talk 1DES if the 2K system is not patched to really do 3DES. I doubt this is a problem based on the output of ipsec look provided below.
This looks OK except possibly for your connection description. It looks like your trying to create a subnet-subnet tunnel. In Microsoft world, this is only possible with 2K-Server or maybe 2K-Advanced Server, as part of the "we want *ALL* the money" campaign. If you're running 2K-Workstation, I don't think this will *EVER* work using microsoft's client (I think you can buy the ssh-sentinel client or similar and get subnet-subnet connectivity at a much lower price than upgrading to Server or Advacned Server).And here's my ipsec.conf: config setup interfaces=%defaultroute plutodebug=none klipsdebug=none plutoload=%search plutostart=%search uniqueids=yes conn %default keyingtries=0 pfs=yes conn SR3K-NET authby=secret left=192.168.3.1 leftsubnet=192.168.246.0/24 leftnexthop=192.168.3.200 right=192.168.2.1 rightsubnet=192.168.0.0/24 rightnexthop=192.168.2.200 auto=start
Since it looks like the two ends negotiated an SA, I don't think you're encountering the 1DES/3DES patch problem.The output of my ipsec look: SR3K Wed Feb 12 20:11:41 UTC 2003 192.168.246.0/24 -> 192.168.0.0/24 => [EMAIL PROTECTED] [EMAIL PROTECTED] (0) [EMAIL PROTECTED] ESP_3DES_HMAC_MD5: dir=out src=192.168.3.1 iv_bits=64bits iv=0x0e86cc9dda1e8d8a ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(12,0,0) [EMAIL PROTECTED] ESP_3DES_HMAC_MD5: dir=in src=192.168.2.1 iv_bits=64bits iv=0x5488aa183793c623 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(12,0,0) [EMAIL PROTECTED] IPIP: dir=in src=192.168.2.1 life(c,s,h)=addtime(12,0,0) [EMAIL PROTECTED] IPIP: dir=out src=192.168.3.1 life(c,s,h)=addtime(12,0,0) Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.3.200 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 192.168.3.200 255.255.255.0 UG 0 0 0 ipsec0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
The FreeS/WAN side logs (in /var/log/auth.log) are always helpful, and the equivelent logs from the windows side (wherever they live) would also be good to review.Also: - My WIN2K eth0 is sharing it's internet resource with eth1. Thus, eth1 automatically inheriting the 192.168.0.0/24 network - pinging from WIN2K N-times, simply displays the "Negotiating IP Security" message. pinging from its client to the client on the other end is negative. - I'll be glad to send more command results if needed.
--
Charles Steinkuehler
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html