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.

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

firewall: -root-
#



-----Original Message-----
From: Charles Steinkuehler [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 13, 2004 1:55 PM
To: Tibbs, Richard
Cc: [EMAIL PROTECTED]
Subject: Re: [leaf-user] Difficulty with Bering 1.2 IPSEC road-warrior


Tibbs, Richard wrote:

> Hello list..
> 
> Trying to implement IPSEC tunnels on my Bering 1.2 fw.
> A few inauspicious lines from the debug log:
> Jul 13 11:35:37 firewall pluto[29061]: | from whack: got --esp=3des 
> Jul 13 11:35:37 firewall pluto[29061]: | from whack: got --ike=3des 
> Jul 13 11:35:37 firewall pluto[29061]: | from whack: got --esp=3des 
> Jul 13 11:35:37 firewall pluto[29061]: | from whack: got --ike=3des 
> What could be wrong here?

That part looks OK...what you need to worry about is the following:

> Jul 13 11:58:08 firewall pluto[29061]: "road-warrior"[1] 137.45.192.86
> #1: 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

While in general your configuration looks OK, I suspect the problem is 
you're testing your road-warrior link too close to the firewall.

You've told IPSec to use %default-route, which sets the next-hop value 
(ipsec has to do it's own low-level routing, and %default-route tells it

to grab what it needs from the kernel routing tables).  This means the 
firewall is sending it's response packets to whatever IP is your default

gateway, while it looks like you've attached the road-warrior system on 
the same network as the upstream interface of the router (meaning the 
ipsec next-hop setting should be the IP of the road-warrior, not the IP 
of your default gateway).

Try moving the test road-warrior system beyond the router hooked to your

firewall, and see if that helps...

One other thing to verify with a windows client is to make sure you've 
actually got the high-security patch installed.  The GUI is dumb enough 
to allow you to select 3DES but it's not actually enabled unless you 
install the appropriate patch from Microsoft.  I don't think you have 
this problem (it usually shows up as a different error in the ipsec 
logs), but I don't work with MS clients enough to rule it out.

-- 
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

Reply via email to