-----BEGIN PGP SIGNED MESSAGE-----
I wanted to let you know that we hear you... I think that there are number
of challenges - it likely won't be possible at this precise moment.
I hope that we will be able to solve your situation soon.
Concerns
1) There are some reports that OE and X.509 do not mix. I see no reason
why they shouldn't except that stock pluto doesn't like certificate
request messages. I think I have a patch for that, but haven't tested
this.
2) NAT and OE do not mix.
This is because the Connection Tracking system that NAT uses does not
cope with multihoming - it believes that if a packet leaves on interface
X, that it must return on interface X for the NAT to be un-done.
OE screws this - the packets leave on ipsecX interface, but return on
ethX/pppX. A simple fix for this is to route the non-OE destinations
directly out the plain interface.
There are two catches for this:
a) pluto has to invoke the updown script when it installs a %pass.
Probably it should be invoke with a new PLUTO_VERB.
b) To do this nicely, in this situation we should really cause
KLIPS to *DROP* the packet rather than send it. This is because
the kernel will have already allocated a NAT entry on ipsec0 (a
source port number). The packet that goes out would create state
on the peer as well. The reply packet will get dropped since it
arrives on the wrong interface.
The sender will then retransmit, and new state will be created on
the ethX interface. Bad enough that we are creating two times as
much state on the gateway box, but to also cause each peer to
create more state is just unfriendly.
3) Pluto and virtual IPs
No doubt your additional IPs are virtual IPs on your external interface.
Pluto doesn't like that for no good reason.
It would be best if each system was able to be mapped to a different ipsec
interface, and we could pick the source address for each properly.
4) security.
Right now, being a pseudo-bump-in-the-stack implementation, but with no
built-in firewalling, it is basically impossible to verify that the
packets that emerge from ipsecX came from the right origins.
That means that any OE peer would be able to impersonate *any* of your
VPN peers or road warriors. (Your RWs can probably already impersonate
each other, btw).
This won't be solved properly until 3.0, but I hope to have some
facilities in 2.1 to help us prototype things. The current situation is
unacceptable, I rather agree.
] Internet Security. Have encryption, will travel |1 Fish/2 Fish [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [
] mcr_at_sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [
] At the far end of some dark fiber - wait that's dirt! |for everyone [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPTnN8oqHRg3pndX9AQFd/wP/cvWE2dJa+7QiDUuXj+kXWKJVttdBIwSX
xxZEaxJSSRoolzHzmaw/MUSXKCvyHOORHPYU7T+dQ62L5yHsXFHyrXMsn8aLuOn0
X4iv3rNlWpeXCWAS40rQPhOH9qGe4uq5CZhBHq6RfLzXNkQijW2oE1YJdOq/p3Ce
MTNpujTT+Dc=
=hhrk
-----END PGP SIGNATURE-----
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:25 CEST