Netfilter and IPSec interaction

Netfilter and IPSec interaction

[Aleksandar Milivojevic]

I'm writing set of firewall rules for IPSec based VPN, and have couple of
questions.

I know that packets are supposed to go through Netfilter tables twice (as
received from the wire, and than as outputed by IPSec module).  However, what I
noticed is that this seems to be true only for incomming packets.  The outgoing
packets seems to go through Netfilter tables only once.

For example, I've placed bunch of LOG rules in every chain of filter and mangle
tables, logging all icmp and esp protocol packets.  I've placed them as the
very first rules in each chain, so basically they should log everythign that
goes on.  I've observed this when pinging a host on remote network (over IPSec
tunnel):

Sending ICMP ping, only one pass:
   mangle   PREROUTING    cleartext icmp packet
            FORWARD       cleartext icmp packet
   filter   FORWARD       cleartext icmp packet
   mangle   POSTROUTING   encrypted esp packet

Basically packet went through Netfilter tables only once, with IPSec kicking in
somewhere between filter's FORWARD and mangle's POSTROUTING chains.  I would
expect encrypted packet to also go through filter's and mangle's OUTPUT chains.
 After all, the esp packet is locally generated.  But it never got there, it
just went straight to mangle's POSTROUTING chain and hopped onto the wire.

On the other hand, the return packet was handled as expected (this part included
more as reference):

Receiving ICMP pong, first pass:
   mangle   PREROUTING    encrypted esp packet
            INPUT         encrypted esp packet
   filter   INPUT         encrypted esp packet
IPSec kicks in, and we have second pass:
   mangle   PREROUTING    cleartext icmp packet
            FORWARD       cleartext icmp packet
   filter   FORWARD       cleartext icmp packet
   mangle   POSTROUTING   cleartext icmp packet

So, my question is, is something going wrong here, or is this asymetry by
design?

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: Netfilter and IPSec interaction

[Taylor, Grant]

Aleksandar Milivojevic wrote:
> I'm writing set of firewall rules for IPSec based VPN, and have couple of
> questions.
> 
> I know that packets are supposed to go through Netfilter tables twice (as
> received from the wire, and than as outputed by IPSec module).  However, what I
> noticed is that this seems to be true only for incomming packets.  The outgoing
> packets seems to go through Netfilter tables only once.

What kernel are you running and have you applied the (4) Patch-o-Matic (NG) IPSec patches that are meant to address this very issue?  Word to the wise, I've had problems applying said patches in such that I had to edit the info file inside of the <pom root>/patchlets/ipsec-0<number>-<rest of patch name>/ directory and remove the dependencies on other patches.  I've found that patch 01 would not apply b/c it was looking for a different patch that does not exist as it has already been applied to the 2.6.10 and 2.6.12.2 (other unknown) kernel.  Once patch 01 has been applied 02, and 03 should go ok, but 04 does not see that 03 has been applied.  If you remove the dependency (or require word (what ever)) on patch 03 then patch 04 will (test and) apply cleanly to a kernel with patches 01, 02, and 03 already in place.

Has any one else experienced such problem with applying the IPSec-0x patches?



Grant. . . .

Re: Netfilter and IPSec interaction

[Trevor Cordes]

On Thu, Jul 14, 2005 at 12:21:09PM -0500, Aleksandar Milivojevic wrote:
> I'm writing set of firewall rules for IPSec based VPN, and have couple of
> questions.
> 
> I know that packets are supposed to go through Netfilter tables twice (as
> received from the wire, and than as outputed by IPSec module).  However, what I
> noticed is that this seems to be true only for incomming packets.  The outgoing
> packets seems to go through Netfilter tables only once.

It drove me batty when I first ran into it... you are not alone.

> So, my question is, is something going wrong here, or is this asymetry by
> design?

No, it's a serious shortcoming of the design of the NAT/IPSEC code and 
needs to be addressed in the mainstream kernel yet no one AFAIK knows how 
to do it cleanly yet.  See my RH bugzilla post and make some noise:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143374

Grant's post gives an excellent summary.  As per his hints, I'm going to 
try to get the ipsec/nat patches into the latest FC3 kernel (2.6.12) and 
see if I can get that working.  My old patched 2.6.10 is getting long in 
the tooth and another old 2.6.10 mem leak bug is killing me once in a 
while.

I'll report back.

(Grant, are you for sure saying you got the patches to go into 2.6.12 and 
compile?)

Re: Netfilter and IPSec interaction

[Grant Taylor]

>(Grant, are you for sure saying you got the patches to go into 2.6.12 and 
>compile?)
>

Sorry for not getting back to you sooner, I've had a VERY busy time.

I do not recall if I compiled or not for sure because I was doing *SO* 
much to the kernel in question and trying *SO* many different versions.  
Namely I was testing to see which patches out of the IPTables 
Patch-o-Matic would apply in what combination to a few different kernel 
sources.  I had also had to apply a different patch to my kernel source 
b/c I was running it on a Cobalt RaQ 4i and had to fix the shutdown / 
restart issue with the watchdog.  As such I do not remember for sure 
that I _did_ compile the kernel.  Sorry.

What I DO know for sure is that I DID successfully apply the IPSec 
patches 1 - 4 after I went in to the info files and removed dependencies 
on previously patches.  I was not able to apply patch #1 b/c it was 
looking for a specific patch (the name eludes me at the moment).  I 
found the patch in question on the net in a mail list archive from the 
original author of the patches.  When I got to looking the (missing) 
patch was already in the mainstream kernel and thus was not available 
for patching.  So I removed the dependency on it for the IPSec-01 
patch.  Once I had removed the dependency I tested the IPSec-01 patch 
and it did apply cleanly.  Once the IPSec-01 patch was in place patches 
IPSec-02 and IPSec-03 applied cleanly.  The IPSec-04 patch did not want 
to apply stating that it was dependent on the IPSec-03 patch.  Having 
just applied the patch that IPSec-04 wanted I knew that it was there so 
I removed the dependency in the info file and was able to apply the 
IPSec-04 patch with out any problems at all.  The only thing that I 
could find wrong with the four IPSec patches was the dependency tree 
checking.  Not being a real programmer (I just hack things together when 
I have to) I don't know how to fix what is wrong, that is for others to do.



Grant. . . .

Re: Netfilter and IPSec interaction

[Aleksandar Milivojevic]

Aleksandar Milivojevic wrote:
> I'm writing set of firewall rules for IPSec based VPN, and have couple of
> questions.
> 
> I know that packets are supposed to go through Netfilter tables twice (as
> received from the wire, and than as outputed by IPSec module).  However, what I
> noticed is that this seems to be true only for incomming packets.  The outgoing
> packets seems to go through Netfilter tables only once.

Thanks to everybody who replied on the list and off-list.  I'll just 
write a short summary.

Apperently, this is a known problem and it has been discussed on 
Netfilter's development lists.  There are some patches that solve it, 
but they are not going to get into mainstream kernel since approach 
taken in them is problematic (and according to some sources, those 
patches are abandoned and not maintained anymore).  I wasn't able to 
find why the approach is problematic, but apperently answer to that 
question is burried somewhere in archives of Netfilter's development 
list.  Seems that correct approach to solve the problem still needs to 
be found (and once found and implemented will become part of mainstream 
kernel).

Re: Netfilter and IPSec interaction

[Trevor Cordes]

On Sun, Jul 17, 2005 at 10:23:58PM -0500, Aleksandar Milivojevic wrote:
> 
> Apperently, this is a known problem and it has been discussed on 
> Netfilter's development lists.  There are some patches that solve it, 
> but they are not going to get into mainstream kernel since approach 

I can now confirm that the current PoM 2.6sec/NAT patches do compile into 
a 2.6.12 kernel (for me FC3 2.6.12-1.1372) with a few modifications to 
dependencies, etc.  I will be heavily testing this new kernel very 
shortly.

> taken in them is problematic (and according to some sources, those 
> patches are abandoned and not maintained anymore).  I wasn't able to 
> find why the approach is problematic, but apperently answer to that 

From my understanding, the patches are too broad and affect too many 
source files.  It's not "clean" and prone to maintenance errors.  The way 
it's coded/architected needs to be rethought and will probably require a 
rethink/rewrite of much more than just the bits the patch touches.

> question is burried somewhere in archives of Netfilter's development 
> list.  Seems that correct approach to solve the problem still needs to 
> be found (and once found and implemented will become part of mainstream 
> kernel).

Yes, it would be nice to see that some effort is going into this problem.