Tibbs, Richard wrote:
Well, the win2000pro machine is up to service pack 4, and the ipsec section of the Bering user's guide says it needs at least service pack 2.. I will check microsquish for any missing patches.
It is "not possible" to move my win2000 machine across the router,
because I am at work. And I suspect the routing issue is the key here. There seems to be no syntax in the ipsec.conf file :-( as there is in
the shorewall files :-) -- thanks very much to whoever did that.
I googled for ipsec and found the ipsec man page, but the link to
ipsec.conf is broken.
Went to freeswan.org, but couldn't find much there on ipsec.conf itself.
Can anyone point me to syntax to replace the interfaces=%defaultroute parameter? Can I just say interfaces=<win2khost IP addr> ? Thanks in advance >>> Rick.
I've got slightly dated versions (1.91 and earlier) online at my site...it's not the exact version used with Bering, but most details still apply verbatim (the newer versions are usually supersets of the older config file formats):
http://lrp2.steinkuehler.net/Packages/man/IPSec1.91/index.html http://lrp2.steinkuehler.net/Packages/man/IPSec1.91/manpage.d/ipsec.conf.5.html
Looks like either explicitly specifying the IP and next hop settings, or using %direct for nexthop should work with directly connected box...
PS:
I think the defaultroute issue may solve this because, "while you were
out" I tried another tack:
Chad Carr's setup was to route ALL traffic through the FW, so since I am
only interested in contacting the internal subnet 192.168.10.0/24, I
changed the endpoints in the Outbound -> destination ip from Any to specific subnet above, and
Inbound -> source ip from Any to specifig subnet above.
Now, I still get 100% packet loss: ======================== cmd window.. ================
C:\>ping 192.168.10.13
Pinging 192.168.10.13 with 32 bytes of data:
Negotiating IP Security. Negotiating IP Security. Negotiating IP Security. Negotiating IP Security.
Ping statistics for 192.168.10.13: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms ========================== cmd window output ==============
The auth.log appears to have lost the problem with "cannot respond to
IPsec SA request because no connection is known for
0.0.0.0/0===137.45.192.69...137.45.192.86" Here is a snip:
Jul 13 13:49:48 firewall pluto[5895]: packet from 137.45.192.86:500: ignoring Ve ndor ID payload [MS NT5 ISAKMPOAKLEY 00000002] Jul 13 13:49:48 firewall pluto[5895]: "road-warrior"[4] 137.45.192.86 #6: respon ding to Main Mode from unknown peer 137.45.192.86 Jul 13 13:49:48 firewall pluto[5895]: "road-warrior"[4] 137.45.192.86 #6: Main m ode peer ID is ID_IPV4_ADDR: '137.45.192.86' Jul 13 13:49:48 firewall pluto[5895]: "road-warrior"[4] 137.45.192.86 #6: sent M R3, ISAKMP SA established Jul 13 13:49:48 firewall pluto[5895]: "road-warrior"[4] 137.45.192.86 #7: respon ding to Quick Mode Jul 13 13:49:48 firewall pluto[5895]: "road-warrior"[4] 137.45.192.86 #7: IPsec SA established
When the SA is established but no data gets through, it's time to make sure you're allowing protocol 50 (ESP) and/or 51 (AH) thorugh your firewall (or using NAT traversal which uses UDP port 500 for all traffic, not just keying exchanges).
-- Charles Steinkuehler [EMAIL PROTECTED]
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
------------------------------------------------------------------------
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
