Shorewall users - Oct 2005 - Problem with IPComp on VPN

I''ve created an IPSec VPN using shorewall and racoon-tool under Debian
3.1.  I''m not using the patched iptables/kernel for policy match,
therefore I''m using the tunnels/hosts config method rather than the
ipsec config file method.  I''m running the latest 2.6.13 kernel.

I have no problem getting my VPN connection up and running with one
exception.  Without compression enabled, I have perfect bi-directional
traffic routing between my two LANs. I should mention I''ve got
(nearly) identical linux firewalls on both ends of the link.  The
problem occurs when I enable compression.  As soon as I do this, the
firewall starts dropping the VPN traffic on the remote end of the link
(regardless of which way I send it).  I''ve tried adding a firewall
rule to accept IPComp protocol traffic, but this has no effect.

I''ve checked lsmod and ipcomp,esp,deflate etc are all loaded properly.

Strangely, I noticed in the firewall logs that the protocol being
dropped off the VPN link is "0" rather than ESP or IPCOMP.

"Oct 16 22:21:02 firewall Shorewall:net2all:DROP: IN=eth2
OUTMAC=00:01:51:1e:f1:aa:03:06:32:f3:3d:1c:04:20  SRC=1.2.3.4 DST=5.6.7.8
LEN=68 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=0"

I''m running shorewall 2.4 on both ends.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Cyber Dog wrote:
> I''ve created an IPSec VPN using shorewall and racoon-tool under
Debian
> 3.1. 
Don''t post on the ipsec-tools list saying that you run racoon-tool;
you''ll be run out of town on a rail.

> "Oct 16 22:21:02 firewall Shorewall:net2all:DROP: IN=eth2 OUT>
MAC=00:01:51:1e:f1:aa:03:06:32:f3:3d:1c:04:20  SRC=1.2.3.4 DST=5.6.7.8
> LEN=68 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=0"
> 
I really don''t know what you expect -- you know that the unpatched IP
stack/Netfilter is completely broken with respect to IPSEC and this is
just more evidence of it. And you''ve obfuscated the IP addresses so I
can''t even guess which zone 1.2.3.4 is in.

So let''s make a wild guess and call that zone ''net''.
Then the rule:

ACCEPT    net:1.2.3.4    fw

Will at least stop the messages -- whether it will work and whether it
will open a hole in your firewall wide enough to drive a truck through,
I don''t know.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

On 10/16/05, Tom Eastep <teastep@shorewall.net>
wrote:
> Cyber Dog wrote:
> > I''ve created an IPSec VPN using shorewall and racoon-tool
under Debian
> > 3.1.
>
> Don''t post on the ipsec-tools list saying that you run
racoon-tool;
> you''ll be run out of town on a rail.
>
I wasn''t posting on ipsec-tools, was I?  I''ve run racoon
straight and
with racoon-tool, and this being the _shorewall_ list I didn''t really
think it mattered (especially since I already checked the generated
racoon config to verify it.)
>
> > "Oct 16 22:21:02 firewall Shorewall:net2all:DROP: IN=eth2 OUT>
> MAC=00:01:51:1e:f1:aa:03:06:32:f3:3d:1c:04:20  SRC=1.2.3.4 DST=5.6.7.8
> > LEN=68 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=0"
> >
>
> I really don''t know what you expect -- you know that the unpatched
IP
> stack/Netfilter is completely broken with respect to IPSEC and this is
> just more evidence of it.
No, I don''t necessarily "know" that though I''ve seen
you mention it
before.  My purpose here was to find out if I was making a stupid
shorewall mistake, because it wouldn''t be the first time.
>And you''ve obfuscated the IP addresses so I
> can''t even guess which zone 1.2.3.4 is in.
>
They''re the external addresses on my two firewalls, with no NAT being
done.  Therefore both are "net" zone.  My fault for not including
this.
> So let''s make a wild guess and call that zone
''net''. Then the rule:
>
> ACCEPT    net:1.2.3.4    fw
>
> Will at least stop the messages -- whether it will work and whether it
> will open a hole in your firewall wide enough to drive a truck through,
> I don''t know.
>
> -Tom
I assume from your response that my shorewall config, since it works
without compression, is not at fault for this problem.  Now that I''ve
had this clarified I can procede to hopefully get a bug report in with
the proper developers.  Thanks for your time.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Cyber Dog wrote:
>> -Tom
> 
> I assume from your response that my shorewall config, since it works
> without compression, is not at fault for this problem.  Now that
I''ve
> had this clarified I can procede to hopefully get a bug report in with
> the proper developers.  Thanks for your time.
To summarize:

Once you have added a rule to allow protocol 108 from the remote gateway
(and another one to allow outgoing IPComp traffic if warranted by your
policies) then your Shorewall configuration should be correct. The
appearance of Protocol 0 in log messages definitely looks wrong and the
only way to work around it is to accept *all* traffic from the remote
gateway (In iptables/Netfilter, proto = 0 is equivalent to proto = all).

Have you used tcpdump to see what''s actually crossing the wire?

I am happy to see that Patrick McHardy is once again working on
IPSec/Netfilter integration (he posted some new patches over the
weekend) so hopefully we will see complete support in standard kernels
before too much longer (famous last words).

As a final note, I have stopped using IPSec and now use OpenVPN
exclusively. It imposes a bit more overhead but I don''t have to patch
my
firewall kernels to get it to work properly. I must confess that I did
not try ipcomp -- at the time that I did the Shorewall work for 2.6
kernel IPsec, ipcomp didn''t work at all.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key