[Openswan Users] Questions regarding firewall and routing accommodations for openswan 2.6.28
neal.p.murphy at alum.wpi.edu
Thu Sep 16 13:32:43 EDT 2010
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
> > 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.
More information about the Users