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

[Neal Murphy]

(Ref: http://lists.openswan.org/pipermail/users/2010-August/019187.html)

Stephen Jones wrote:
> Greetings openswan users and gurus!
> 
> I am involved with a project that is attempting to drag the venerable 
> SmoothWall 3.0 OSS firewall project kicking-and-screaming into the 21st 
> century.  Among the many, many, many version upgrades required to 
> re-establish the platform around modern versions of gcc 4.4.3 (from 
> 3.3.5) and current 2.6 kernels 2.6.32.17 (from 2.6.16.60), the openswan 
> component was also updated to 2.6.28 (from 2.4.15).
> ...

I've made a little progress with this in the meantime. Kernel is now 
2.6.32.21. IPTables is 1.4.8.

I had previously built the kernel applying the SAREF and klips patches. But 
that hardly worked. So I went back to the beginning and built vanilla kernel, 
iptables, xtables-addons, openswan programs, and openswan ipsec module with 
no patches in any of them. No SAREF, no NETKEY, no built-in ipsec module. 
That seems to work better.

Configuring a tunnel between the new system (left) and the original Smoothwall 
(right) half-works. Negotiation is successful and the tunnel seems to come 
up. The original Smoothwall reports the connection as up in the GUI.

From a node behind right, I can access the left host (ping, ssh, http).
But I can't access anything else behind left. From right itself, I cannot 
access left.

From a node behind left, I can access the left host and internet, but 
everything bound for the tunnel is blocked:

Sep 15 22:29:19 lanner kernel: [  199.875626] IN=eth0 OUT=mast0 
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 

So, the tunnel is up and handles two-way traffic but only if initiated from 
the remote end. The message above just about guarantees that the firewall is 
blocking local access. But where?!? I am at a complete loss. I've waded 
through the updown script, followed its functions, verified its variables; it 
*looks* like it's doing what it should.

What am I missing? It has something to do with the 'new' mast0 interface, but 
I've nary a clue!

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?

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.

Thanks,
Neal