[Openswan Users] help request - traffic not going through
DL at forbis.org
Wed Apr 14 09:20:21 CEST 2004
Thanks for the tips, Paul. Unfortuantely, I've still seen
the same problems. New ipsec barfs (with and without shorewall
enabled are posted:
I went through your suggestions one by one:
>From the barf I saw:
> 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
> 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
> conn dforbis-vpn1
> 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
Are there any kernel debugging options I can enable to help track this down?
Thanks very much for your time,
More information about the Users