[Openswan Users] help request - traffic not going through IPsectunnel

[David Forbis]

Thanks for the tips, Paul.  Unfortuantely, I've still seen
the same problems.  New ipsec barfs (with and without shorewall
enabled are posted:

http://www.forbis.org/ipsecbarf2.txt
http://www.forbis.org/ipsecbarf_swclear.txt

I went through your suggestions one by one:

>
>From the barf I saw:
>
> all/rp_filter:0
> default/rp_filter:1
> eth0/rp_filter:1
> eth1/rp_filter:1
>
> I'd recommend disabling all of rp_filter in /etc/sysctl.conf

Did that, all of the above now come up as "0"

> I'm not convinced that your NAT is not causing problems. It looks a bit
> complex, and I do
> not see the nat exclusion for packets. You seem to match them for source
> first, and then
> hand them down a chain and skip masq only for destination.

Hmm.  I'll revisit my shorewall configurations.  Wouldn't the fact that I
have the same symptoms while running "shorewall clear" indicate that while
my NAT may be another problem, it isn't the primary one?

> # CONFIG_IP_ADVANCED_ROUTER is not set
>
> I am not sure if this is still optional or mandatory. It won't hurt, and I
> recommend enabling
> the advanced router features.

I had this enabled a week ago, then tried disabling it a few days ago -
did not see a difference either way.  I've re-enabled it in my current
kernel build.

> CONFIG_INET_IPCOMP=y
>
> There are some interop issues between native 2.6 pfkey (and KAME) and
> Openswan/Freeswan KLIPS code.
> Depending on the other end of the connection (eg if it is klips) then you
> might have problems too.
> Freeswan/Openswan does not yet allow for disabling compression (only the
> disabling of advertising it).
> So either you need to ensure that compression isn't asked for at the other
> end (which it cannot if it is
> KLIPS), or you are better of leaving this out of your kernel for now.

OK, I've turned this option off.

> I am not sure if you have af_key or xfrm_user. We need to adjust the barf
> to catch those as well, but
> I assume you do, since you do get conns going and no pf_write failures.

I have XFRM_USER enabled, but did not find an "af_key" - I assume you mean
PF_KEY, which I've got turned on.

> Note that dforbis-common is not loaded as a seperate conn, which I think
> you intended to do. You
> probably got a warning about a double auto= line in dforbis-vpn1
>
> Do something like:
>
> conn dforbis-host
> 	also=dforbis-base
> 	auto=start
> conn dforbis-vpn1
> 	also=dforbis-base
> 	rightsubnet=10.90.101.0/24
> 	auto=start
> conn dforbis-base
> 	...
>
> This way, both will start.
>
> Perhaps that is the mixture of packets you are seeing, the difference
> between the host and the
> subnet conn?

In an effort to simplify things, I've gotton rid of my "dforbis-common"
connection...  I'm really only trying to define one connection (to my
understanding), so I don't think there's a need to have that.

Referring to my barfs, does the error message "could not start conn
"dforbis-vpn1"" mean anything, despite the fact that the tunnel appear to
be established?

Are there any kernel debugging options I can enable to help track this down?

Thanks very much for your time,
Dave