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

[Paul Wouters]

On Thu, 16 Sep 2010, Neal Murphy wrote:

>>> SRC=10.20.30.20 DST=10.20.31.1 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=41759
>>> DF PROTO=TCP SPT=1673 DPT=222 WINDOW=65535 RES=0x00 SYN URGP=0
>>> MARK=0x80010000
>>
>> Where is that MARK coming from? Openswan has "taken" the hight bit to mean
>> "This mark is an SAref". If smoothwall is using it for something else, we
>> have a problem.
>
> That's coming from the stuff /usr/lib/ipsec/_updown.mast does in iptables.
> Reference #1 sounds about right; it does track the ref#. Speaking of which,
> if something in SW is using any of those bits, is it much of a pain to change
> openswan to use a different set of bits? That is, would the changes be in the
> shell scripts only? Or also in compiled code? If only scripts would change,
> making a few build-time patches is almost trivial.

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
> OUT  0            10.20.30.0/24      -> 10.20.31.0/24 tun0x1001 at 192.168.1.4
> ref:1 him:0
> OUT  0            10.20.30.0/24      -> 10.20.31.0/24 tun0x1004 at 192.168.1.4
> ref:1 him:0

Odd, so you ARE using mast then....

> 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