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

[Neal Murphy]

On Wednesday 15 September 2010 19:45:56 Paul Wouters wrote:
> On Wed, 15 Sep 2010, Neal Murphy wrote:
> > I had previously built the kernel applying the SAREF and klips patches.
> > But that hardly worked.
> >
> > 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.

>
> > What am I missing? It has something to do with the 'new' mast0 interface,
> > but I've nary a clue!
>
> 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'?

> > Next, since /proc/net/ipsec_eroute no longer shows the state of the
> > tunnel(s), what exactly do I look for in the output of 'ipsec auto
> > status' to determine which tunnels are up? Is there no other place where
> > tunnel status is stored?
>
> In 2.6.29rc1 and onwards, you can use "ipsec policy" to get an "eroute
> like" output.

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

Should it report two tunnels? And there's no change otherwise; still can't get 
out through the 'local', but the 'remote' is up and functional. It's 
definitely something in iptables; I just can't figure out the magic 
incantation to use, and I've mislaid Mickey's magic wand*. Hmmm. Would this 
be related to 'new' connections and 'established' connections being handled 
differently in iptables?

> > Finally, would someone take a gander at the makefile for 'make minstall'
> > and verify that setting DESTDIR does NOT work as expected? My experience
> > is that it always intalls the module in the chroot jail's root and not in
> > the specified package directory.
>
> Are you confusing DESTDIR with FINALDESTDIR? The first is the physical
> location, eg ~/BUILD/openswan/usr/lib/ipsec/pluto while the latter is the
> location of the file after the package install, on the live system, eg
> /usr/lib/ipsec/pluto

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.

Neal


* Fantasia, for those who aren't familiar with the movie.
-------------- next part --------------
--- openswan-2.6.29rc/Makefile-orig	2010-09-16 01:19:30.000000000 -0400
+++ openswan-2.6.29rc/Makefile	2010-09-16 01:36:35.000000000 -0400
@@ -462,14 +462,14 @@
 		exit 93 ; \
 	fi ; \
 	set -x ; \
-	mkdir -p $$OSMODLIB/kernel/$(OSMOD_DESTDIR) ; \
-	cp $(MOD26BUILDDIR)/ipsec.ko $$OSMODLIB/kernel/$(OSMOD_DESTDIR) ; \
+	mkdir -p $(DESTDIR)$$OSMODLIB/kernel/$(OSMOD_DESTDIR) ; \
+	cp $(MOD26BUILDDIR)/ipsec.ko $(DESTDIR)$$OSMODLIB/kernel/$(OSMOD_DESTDIR) ; \
 	if [ -f /sbin/depmod ] ; then depmod -a ; fi; \
 	if [ -n "$(OSMOD_DESTDIR)" ] ; then \
-	mkdir -p $$OSMODLIB/kernel/$(OSMOD_DESTDIR) ; \
-		if [ -f $$OSMODLIB/kernel/ipsec.ko -a -f $$OSMODLIB/kernel/$(OSMOD_DESTDIR)/ipsec.ko ] ; then \
-			echo "WARNING: two ipsec.ko modules found in $$OSMODLIB/kernel:" ; \
-			ls -l $$OSMODLIB/kernel/ipsec.ko $$OSMODLIB/kernel/$(OSMOD_DESTDIR)/ipsec.ko ; \
+	mkdir -p $(DESTDIR)$$OSMODLIB/kernel/$(OSMOD_DESTDIR) ; \
+		if [ -f $(DESTDIR)$$OSMODLIB/kernel/ipsec.ko -a -f $(DESTDIR)$$OSMODLIB/kernel/$(OSMOD_DESTDIR)/ipsec.ko ] ; then \
+			echo "WARNING: two ipsec.ko modules found in $(DESTDIR)$$OSMODLIB/kernel:" ; \
+			ls -l $(DESTDIR)$$OSMODLIB/kernel/ipsec.ko $(DESTDIR)$$OSMODLIB/kernel/$(OSMOD_DESTDIR)/ipsec.ko ; \
 			exit 1; \
 		fi ; \
 	fi ; \