Tibbs, Richard wrote:
Charles, On the nat-traversal issue in bering fws -- I thought that parameter was
if there was a router downstream that would subsequently nat the
connection. I had an exchange with Microsoft about the need for a
patch on the XP (or any machine) going through a nat box like bering.
And I think a while back someone on the list volunteered that
nat_traversal=yes was ineffective.
There is a NAT box...the home FW between your XP system and the internet.
The nat_traversal=yes could be ineffective...I don't use nat_traversal, so I'm not sure. IIRC it's not something that can be negotiated at connection time, however, so both ends need to be setup with agreeing NAT-T settings at configuration time.
Let me try a domain name in my XP IPsec config, as well as -- I think --
the office fw config. Right? IOW, here is my current xp box security policy on the outbound
direction:
Mirr Desc Proto srcport destport srcDNS Scraddr destDNS destaddr
Y - any any any myIP myIP/32 Subnet
192.168.10.0/24
and for inbound.
Y - any any any Subnet 192.168.10.0/24 myIP myIP/32
So, at least the destdns for inbound needs to be mydomain.com and office fw ipsec.conf should have leftid = mydomain.com ?
I don't grok XP ipsec config, and the above looks more like firewall rules than an IPSec connection config. If this were two linux boxen, they should have something like the following in the config files on *BOTH* ends of the link:
conn roadwarrior [EMAIL PROTECTED] [EMAIL PROTECTED] ...
NOTES: - These ID's could also go in conn %default, an included file, etc.
- The @ sign is important! If you don't include the @, the name is resolved and the IP address is used as the identifier, typically *NOT* what you want (you're defaulting to the IP address of ipsec0 for the identifier already, by not specifying [left|right]id).
- The ID's provided/expected by each end must match, (along with other settings, like [L|R]subnet, etc) or you'll get the 'no suitable connection' error.
- I don't know how you specify this sort of ID in XP...perhps google can help you.
BTW, don't know if it matters by I notice that the homefw ipsec conf has
both
left=216.12.22.89 left=%deafultroute.
Could that be any problem?
It could, but I suspect the latter value simply overwrites the earlier one (check the man page and your log files to be sure).
One other issue that might be causing you problems: Are you establishing any IPSec links between your home FW and the office FW? If so, the problem could be that the office FW is getting confused by the fact that you've got multiple connections comming from the same IP address, which already has identity information associated with it (this would also explain the errors in the log about no valid connection description). Using explicit IDs might help you, but it might not (depends on what your other tunnels are like, as there are limitations based on when various information is transfered and how ipsec figures out which connection description to use).
You fundamental problem is that the office FW can't figure out which connection description applies to the inbound connections from your XP box, and this is pretty much by definition a configuration problem (or a problem with the architecture of your network not properly taking into account the limitations of identifying inbound ipsec connections). If using explicit IDs doesn't get you anywhere, try to up the debugging level and post more information from your logs when trying to get the XP box to connect.
-- 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: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html