Netfilter and IPSec interaction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux