[Openswan Users] Revisting old routing problem. Passthrough conns only creating "dir out" policies.

[Michael H. Warfield]

Paul,

	I see now where this can be fixed but I'm really torn.  It could be
"fixed" either at the bottom of netlink_shunt_eroute or at the bottom of
netlink_raw_eroute.

	First off, in my mind, it would seem to make no sense to have a "dir
out" policy without a matching "dir in" policy.  You could sent out on
that set of selectors but couldn't receive back it's mirror image?  I
suppose one might envision some sort of asymetrical environment where
that might be possible but I don't see how you configure it here
anyways.  And there's precedence for this.  If you look at the bottom of
netlink_raw_eroute, there's a switch statement on dir and if this was a
"dir in" action it transforms it into a "dir fwd" action and repeats.
So everything that gets done to an "dir in" gets done to a corresponding
"dir fwd".

	So...  That's the first location where we could "patch" this.  Just add
to that switch block for "out" and switch it to an "in" (and then fall
through to the "fwd" case without breaking).  From reading the code
above that, it looks like some src and dst addresses have to also be
swapped.  I didn't test this.

	The other spot, at the bottom of netlink_shunt_eroute would just add
another call to netlink_raw_eroute adding this right before the return
netlink_raw_eroute at the bottom of the function.

===
      if( ! netlink_raw_eroute(&sr->this.host_addr, &sr->this.client
                              , fam->any
                              , &sr->that.client
                              , htonl(spi)
                              , SA_INT
                              , sr->this.protocol
                              , K_SADB_X_SATYPE_INT
                              , null_proto_info, 0, op, buf2) )
      {
        return FALSE;
      }

      switch (op)
      {
      case ERO_ADD:
          op = ERO_ADD_INBOUND;
          break;
      case ERO_DELETE:
          op = ERO_DEL_INBOUND;
          break;
      default:
          return ok;
      }

      snprintf(buf2, sizeof(buf2)
               , "eroute_connection %s inbound", opname);

===

	This I tried and does work.  Almost seems like the other way would be
more "elegant" but this worked for a quick test.

	Now any eroute added gets added to in, out, and fwd.  This has the side
effect of added unnecessary fwd routes where rightsubnet == leftsubnet.
Not sure if that's a problem.  If it is, then it could be caught down in
netlink_raw_eroute where "in" is turned to "fwd".


On Mon, 2009-05-11 at 10:10 -0400, Paul Wouters wrote:
> On Mon, 11 May 2009, Michael H. Warfield wrote:
> 
> >> 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.
> 
> 
> >> 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?).
> 
> > ===
> >    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)

> Oh, if that is getting a spi of 0, then I take it the code would just work
> properly without the risks I mentioned above.

	That was a red herring.  That spi value is actually coming back from
the shunt_policy_spi() function in kernel.c and is just some ENUM
values.  The 0 case was not applicable and it appears that it was coming
back with SPI_PASS for the passthrough case.

> 
> >    {
> >        /* 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?).
> 
> I'll need to look more at the code to understand wht the entire switch case
> is neccessary to begin with.

	Ignore that switch case.  I was barking up the wrong tree on that one.

> 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/ed48ed2c/attachment.bin