[Openswan Users] Revisting old routing problem. Passthrough conns only creating "dir out" policies.
Michael H. Warfield
mhw at WittsEnd.com
Mon May 11 09:53:42 EDT 2009
On Mon, 2009-05-11 at 09:21 -0400, Paul Wouters wrote:
> On Sun, 10 May 2009, Michael H. Warfield wrote:
>
> > I tried the suggestions for passthrough connections, which made sense.
> > All were unsuccessful. Each time I tried this before I'd usually just
> > give up and forget about it for a long time. Tried again just recently
> > with 2.6.21 on kernel 2.6.27 (netkey) and still had the problem.
> >
> > A little more research I finally stumbled onto a message with almost my
> > exact same configuration and exact same problem here:
> >
> > http://lists.openswan.org/pipermail/users/2007-April/012298.html
> >
> > His workaround fixed my problems. I also saw several comments in other
> > messages about OpenSWAN only creating the "dir out" policy and not
> > creating the "dir in" or "dir fwd" policies on passthrough connections.
> But the problem here is that I am not convinced of the workaround mentioned there:
> # used to get traffic passed from subnet1 to subnet2 and reverse
> ip xfrm policy add dir in src subnet1 dst subnet2
> ip xfrm policy add dir out src subnet1 dst subnet2
> ip xfrm policy add dir in src subnet2 dst subnet1
> ip xfrm policy add dir out src subnet2 dst subnet1
> ip xfrm policy add dir fwd src subnet1 dst subnet2
> ip xfrm policy add dir fwd src subnet2 dst subnet1
> The problem here is that these policies list no SPI on which they
> apply. I believe that means now that any IPsec SA can send traffic
> with that src/dst combination, and it will be accepted by the kernel.
Well, these are bypasses. They're not suppose to be encapsulated.
Yeah, and that's the case where you have two local networks off two
local intertaces. This is basically what I have for the bypass conns
(even though none of them work, ATM):
conn local-0
authby=never
right=192.168.12.131
rightsubnet=192.168.0.0/19
rightrsasigkey=%none
left=192.168.12.130
leftsubnet=192.168.0.0/19
leftrsasigkey=%none
type=passthrough
auto=route
conn local-1
authby=never
right=192.168.38.0
rightsubnet=192.168.38.0/24
rightrsasigkey=%none
left=192.168.38.1
leftsubnet=192.168.38.0/24
leftrsasigkey=%none
type=passthrough
auto=route
conn local-2
authby=never
right=192.168.38.0
rightsubnet=192.168.0.0/19
rightrsasigkey=%none
left=192.168.38.1
leftsubnet=192.168.38.0/24
leftrsasigkey=%none
type=passthrough
auto=route
conn local-3
authby=never
right=192.168.38.0
rightsubnet=192.168.38.0/24
rightrsasigkey=%none
left=192.168.38.1
leftsubnet=192.168.0.0/19
leftrsasigkey=%none
type=passthrough
auto=route
In each case, the only thing that gets added to the policy database is
the "dir out" case for the ordered set of "src {leftsubnet} dst
{rightsubnet}" policy selectors, which doesn't work without the
corresponding "dir in" policies as well.
The local-0 conn should cover the 1st local network communicating with
the gateway. The local-1 conn should cover the 2nd local network
communicating with the gateway. Except neither have the "in" policy to
allow it. The local-2 adds the out policy but not the in policy for
when the 1st local network is trying to hit the interface of on the
gateway for the second local network. It also needs the forward policy
to allow packets to route from interface 1 to interface 2 from local
network 1 to local network 2. All of this is to avoid the encapsulation
code.
> The original klips passthrough routes, since they were route based, could
> only work for the local machine itself. Perhaps Herbert can tell us more
> about how this would apply safely on netkey?
I'm not sure I understand. These are being selected by the src and dst
selectors and applying a policy of "none" to that case, which is exactly
what we want and I'm not sure I see the difference between this and the
klips "route based" case, other than the fact that routes would be
selected purely on the destination regardless of the source (which would
be worse, would it not?).
> > This is even sitting in the OpenSWAN bugzilla here from a year ago:
> >
> > http://bugs.xelerance.com/view.php?id=907
> >
> > If I add a passthrough conn for rightsubnet=A/19 and leftsubnet=A/19
> > and bring it up (--route) the "dir out" is in the policy table but
> > there's not "dir in" in the policy table. Add the matching "dir in" and
> > it starts working.
> > Question is, what is it suppose to do or what are we suppose to do to
> > make this work, if it's not a bug, or can we get this bug in bugzilla
> > addressed?
> I am not sure what the best way is, or whether there is a better way, when
> using NETKEY.
Debugging, I saw in the code where it prints this: "request to add a
prospective erouted policy with netkey kernel --- experimental". Yeah,
ok...
I can see why adding the two policies works and I can understand why
adding the single policy doesn't.
Around line 2858 in programs/pluto/kernel.c I see this:
===
/* if no state provided, then install a shunt for later */
if (st == NULL)
eroute_installed = shunt_eroute(c, sr, RT_ROUTED_PROSPECTIVE
, ERO_ADD, "add");
else
eroute_installed = sag_eroute(st, sr, ERO_ADD, "add");
===
And, of course, shunt_eroute calls netlink_shunt_eroute here:
===
if(kernel_ops->shunt_eroute) {
return kernel_ops->shunt_eroute(c, sr, rt_kind, op, opname);
}
===
In kernel_netlink.c netlink_shunt_eroute() I see this:
===
if (spi == 0)
{
/* we're supposed to end up with no eroute: rejig op and opname
*/
switch (op)
{
case ERO_REPLACE:
/* replace with nothing == delete */
op = ERO_DELETE;
opname = "delete";
break;
case ERO_ADD:
/* add nothing == do nothing */
return TRUE;
case ERO_DELETE:
/* delete remains delete */
break;
case ERO_ADD_INBOUND:
break;;
case ERO_DEL_INBOUND:
break;;
===
SPI = 0 case as you pointed out.
So ERO_ADD (return) really seems to be acting very different from
ERO_ADD_INBOUND (break) and would seem to be only adding the "dir out"
case (but it just returns from that function, so I'm confused - where
did the "dir out" get added?).
Seems like something different should be done back in kernel.c but
that's really scary to me since that would impact the other modes
(klips) and that's not where I expect to plug in something that's netkey
specific.
> Paul
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20090511/844387cb/attachment-0001.bin
More information about the Users
mailing list