[Openswan Users] Questions regarding firewall and routing accommodations for openswan 2.6.28

[Neal Murphy]

On Thursday 16 September 2010 08:59:26 Paul Wouters wrote:
> If you are using protostack=mast, then I assume we are setting it and not
> something else, and you should not have a problem. The mark is used in more
> then just the scripts, so you canoot easilly change how it works.
>
> >> That would only be if you have protostack=mast in your config. The
> >> default protostack (=auto) tries netkey first, then klips.
> >
> > I don't have protostack= in the config. I don't have NETKEY configured or
> > compiled. The only option should be the klips module. Is there a way to
> > make it not use mast? Or is mast 'the new way'?
>
> protostack=klips will do that. If you didnt set it to mast, then I am
> unsure how you would be using mast, as it is not picked up through any
> defaults.
>
> > Just tried this with the latest source from git and the .29rc1 tarball.
> > It works better when I remember to rmmod/modprobe when changing the
> > package. :) Output is:
> > lanner (root) ~ $ /usr/sbin/ipsec policy
> > stack: mast
>
> Odd, so you ARE using mast then....

*I'm* not using mast; openswan is. :) So Openswan should *not* default to 
using mast? That is, a vanilla build from the tarball should result in pluto 
trying netkey, then klips? Wait, no, that's only if 'protostack=auto' is set 
in the config, right? Checking... Ah, I didn't have protostack set at all in 
the config (because the original SWE3 stuff didn't have it); perhaps that 
makes pluto default to using the mast stack?

I've just set 'protostack=klips' and, Hairy Thunderer be praised, it works! 
Traffic passes both directions! That was the clue I needed. Cosmic Muffin was 
just toying with me all these weeks. Now I can move on with the project.

Do you want to continue searching for why the firewall only allows the remote 
to have full access? It it probably not an openswan problem, but would be 
good to have a solution/workaround documented.

>
> > DESTDIR (in the manner you've illustrated) is where I want to install the
> > module. The make rule 'minstall' depends on 'ministall26', which does an
> > admirable job determining where to install the module on a live system or
> > where he built kernel wants it (via variable OSMODLIB), but doesn't use
> > DESTDIR. It's OK, though; a mkdir and a cp in my Makefile work fine. ...
> > OK, I made a patch. If the attached file makes it through, it'll
> > illustrate what worked for me. If not, I changed the 8 instances of
> > $$OSMODLIB/kernel/... to $(DESTDIR)$$OSMODLIB/kernel/.... This only
> > changes minstall26.
>
> Ok, we will fix that.
>
> Paul

Thanks Paul!