[Openswan Users] Questions regarding firewall and routing accommodations for openswan 2.6.28
neal.p.murphy at alum.wpi.edu
Wed Sep 15 19:01:59 EDT 2010
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 18.104.22.168 (from 22.214.171.124), 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
126.96.36.199. 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
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.
More information about the Users