Tibbs, Richard wrote:
Charles, I tried everything you suggested, but to no avail. Any ideas what to try next?
I still think you've got a problem with properly setting up the connection on both ends (check especially the required service-packs, updates, and registry patches required to implement NAT-T on XP (see link in #2, below), but I can think of three things to try now:
1) Clean up your config files
2) Reading up on XP/linux IPSec interop
3) Change the problem
1)
I'd 'clean' your config files, by which I mean re-organize. You've got stuff in the %default section that shouldn't be there, and not enough stuff in the road-warrior section, so it's unclear exactly what information is being used for the connection. I typically only put settings for the local-system in %default, and put all the remote stuff (and anything that needs to change from the default settings for the local end) in a seperate connection description, ie:
<ipsec.conf>
# basic configuration
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work;
# %defaultroute is okay for most simple cases.
interfaces=%defaultroute
#interfaces="ipsec0=eth0"
# Debug-logging controls: "none" for (almost) none, "all" for lots.
klipsdebug=none
plutodebug=none
# Use auto= parameters in conn descriptions to control startup actions.
plutoload=%search
plutostart=%search
# Close down old connection when new one using same ID shows up.
uniqueids=yes# defaults for subsequent connection descriptions
conn %default
# How persistent to be in (re)keying negotiations (0 means very).
keyingtries=0
# RSA authentication with keys from DNS.
#authby=rsasig
# Authentication by pre-shared secret key
authby=secret
right=%defaultroute
rightsubnet=192.168.10.0/24
rightfirewall=yes
[EMAIL PROTECTED]
pfs=yes
auto=add
#leftrsasigkey=%dns
#rightrsasigkey=%dnsconn road-warrior
left=%any
nat_traversal=yes
[EMAIL PROTECTED]
</ipsec.conf>Also, in your secrets file, you should have an entry like the following:
@itec-nat-tibbs-10.radford.edu @www.oakcitynet.com : PSK "...secret..."
2)
Your problem could be on the XP end...have you been reading up on configuring XP to interop with [free|open]/swan?
http://wiki.openswan.org/index.php/Win2K
3)
There are limitations identifying connections when using PSK's, which can make it very difficult to support road-warrior connections, especially if you want to have more than one. In general, the best way to avoid these problems is to use either RSA keys or certificates, if possible.
My experience is using RSA keys and/or certs, rather than pre-shared-secrets. In fact, it looks like the [left|right]id settings don't have any affect with PSK's (something I'd forgotten):
<quote openswan wiki docs> Multiple Road Warriors
If you're using RSA keys, as we did in this example, you can add as many Road Warriors as you like. The left/rightid parameter lets Linux Openswan distinguish between multiple Road Warrior peers, each with its own public key.
The situation is different for shared secrets (PSK). During a PSK negotiation, ID information is not available at the time Pluto is trying to determine which secret to use, so, effectively, you can only define one Roadwarrior connection. All your PSK road warriors must therefore share one secret.
</quote>
-- Charles Steinkuehler [EMAIL PROTECTED]
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ------------------------------------------------------------------------ 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
