iptables, ipsec, and host2host

iptables, ipsec, and host2host

[Joe Pruett]

trying this again on the -devel list.  the basic question i'm trying to 
answer is if there really isn't a way to filter esp/ah packets after 
decryption/decapsulation in host2host mode.  i've looked at what i think 
is the current linus kernel and don't see any changes to esp/ah handling 
to address this.  is tunnel mode the only way i can do filtering on the 
packets after ah/esp have done their work?

> > i have been scouring the net and i can't find any clues to whether i 
> > can do filtering after ipsec has decrypted a packet on a host2host 
> > connection. net2net goes through the filters a second time, but 
> > host2host doesn't seem to do that.  is there some other method i can 
> > use to filter the traffic after being decrypted?
> 
> ok, i'm following up to myself.  i dug into the kernel source (for 
> redhat/centos 5) and have found that there don't appear to be any hooks 
> in the ah4.c or esp4.c code to pass packets back through netfilter after 
> decapsution/decryption.  from what i can tell tunnel mode (net2net) gets 
> the double pass through netfilter only because of the use of the ip-ip 
> protocol and ipip.c does a netif_rx call after decapsulation.
> 
> so maybe i should go dig into the current (from linus) kernel sources to 
> see if there have been any changes.  but i'm hoping that someone here 
> might know if there is a reason that ah/esp packets aren't passed 
> through netfilter again after being decapsulated/decrypted? or should i 
> go find the ipsec mailing list?
> 
> my underlying goal is for a monitoring system that i want to be able to 
> see into customer sites via ipsec, but i don't want them to be able to 
> come back over the ipsec connection to my system.  i could setup tunnels 
> to each site, but host2host is really more what i want.

Re: iptables, ipsec, and host2host

[Patrick McHardy]

Joe Pruett wrote:
> trying this again on the -devel list.  the basic question i'm trying to 
> answer is if there really isn't a way to filter esp/ah packets after 
> decryption/decapsulation in host2host mode.  i've looked at what i think 
> is the current linus kernel and don't see any changes to esp/ah handling 
> to address this.  is tunnel mode the only way i can do filtering on the 
> packets after ah/esp have done their work?

Packets in both tunnel and transport mode traverse the netfilter hooks
after decapsulation and before encapsulation. From a users POV there
should be nothing special about it.

Re: iptables, ipsec, and host2host

[Jan Engelhardt]

On Tuesday 2009-02-17 19:23, Patrick McHardy wrote:
> Joe Pruett wrote:
>> trying this again on the -devel list.  the basic question i'm trying to answer
>> is if there really isn't a way to filter esp/ah packets after
>> decryption/decapsulation in host2host mode.  i've looked at what i think is
>> the current linus kernel and don't see any changes to esp/ah handling to
>> address this.  is tunnel mode the only way i can do filtering on the packets
>> after ah/esp have done their work?
>
> Packets in both tunnel and transport mode traverse the netfilter hooks
> after decapsulation and before encapsulation. From a users POV there
> should be nothing special about it.

Precisely, see http://jengelh.medozas.de/images/nf-packet-flow.png .

Re: iptables, ipsec, and host2host

[Joe Pruett]

> Joe Pruett wrote:
>>  trying this again on the -devel list.  the basic question i'm trying to
>>  answer is if there really isn't a way to filter esp/ah packets after
>>  decryption/decapsulation in host2host mode.  i've looked at what i think
>>  is the current linus kernel and don't see any changes to esp/ah handling
>>  to address this.  is tunnel mode the only way i can do filtering on the
>>  packets after ah/esp have done their work?
>
> Packets in both tunnel and transport mode traverse the netfilter hooks
> after decapsulation and before encapsulation. From a users POV there
> should be nothing special about it.

i don't see that behaviour on rhel/centos 5 kernels.  could this have 
changed since 2.6.18?  for tunnel mode, it looks to me like the ip-ip 
module is what causes traffic to be seen after decrypt/decap, and i just 
don't see anything like that for transport mode.

i'll do some more experiments.

Re: iptables, ipsec, and host2host

[Patrick McHardy]

Joe Pruett wrote:
>> Packets in both tunnel and transport mode traverse the netfilter hooks
>> after decapsulation and before encapsulation. From a users POV there
>> should be nothing special about it.
> 
> i don't see that behaviour on rhel/centos 5 kernels.  could this have 
> changed since 2.6.18?  for tunnel mode, it looks to me like the ip-ip 
> module is what causes traffic to be seen after decrypt/decap, and i just 
> don't see anything like that for transport mode.
> 
> i'll do some more experiments.

IIRC the IPsec support was merged around 2.6.17, but that might be wrong.

Re: iptables, ipsec, and host2host

[Jan Engelhardt]

On Tuesday 2009-02-17 19:33, Joe Pruett wrote:
>> Joe Pruett wrote:
>>> trying this again on the -devel list.  the basic question i'm trying to
>>> answer is if there really isn't a way to filter esp/ah packets after
>>> decryption/decapsulation in host2host mode.  i've looked at what i think
>>> is the current linus kernel and don't see any changes to esp/ah handling
>>> to address this.  is tunnel mode the only way i can do filtering on the
>>> packets after ah/esp have done their work?
>>
>> Packets in both tunnel and transport mode traverse the netfilter hooks
>> after decapsulation and before encapsulation. From a users POV there
>> should be nothing special about it.
>
> i don't see that behaviour on rhel/centos 5 kernels.  could this have changed
> since 2.6.18?  for tunnel mode, it looks to me like the ip-ip module is what
> causes traffic to be seen after decrypt/decap, and i just don't see anything
> like that for transport mode.

ipip is not used for ipsec.

Re: iptables, ipsec, and host2host

[Joe Pruett]

On Tue, 17 Feb 2009, Jan Engelhardt wrote:

> ipip is not used for ipsec.

my reading of the code was that in tunnel mode, the next protocol header 
is ip and so the packet then gets handed off to the ip-ip handler.  and 
that is where i saw it being handed off to the recv routine again.  that 
seemed to match what i see with tcpdump since both the ipsec packet and 
the decrypted packet show up.

Re: iptables, ipsec, and host2host

[Jan Engelhardt]

On Tuesday 2009-02-17 19:46, Joe Pruett wrote:
> On Tue, 17 Feb 2009, Jan Engelhardt wrote:
>
>> ipip is not used for ipsec.
>
> my reading of the code was that in tunnel mode, the next protocol
> header is ip and so the packet then gets handed off to the ip-ip
> handler.

Still the ipip.ko module (used for creating an explicit tunnel
interface) is not used nor required to be loaded.

When an ESP packet with IPv4 outer address is received, the function
ip_rcv() will eventually deal with it, moved to the xfrm decoder and
then reinjected by calling netif_rx (see xfrm_input.c) on the skb
with its decoded payload.

Also, do not confuse IP-in-ESP-over-IPv4 with IP-(in/over)-IP.
For about every router and subsystem other than xfrm, there
is no way to look into ESP payload and hence, it's just
ESP-on-IPv4 or ESP-on-IPv6.

Re: iptables, ipsec, and host2host

[Joe Pruett]

On Tue, 17 Feb 2009, Jan Engelhardt wrote:

> Still the ipip.ko module (used for creating an explicit tunnel
> interface) is not used nor required to be loaded.
>
> When an ESP packet with IPv4 outer address is received, the function
> ip_rcv() will eventually deal with it, moved to the xfrm decoder and
> then reinjected by calling netif_rx (see xfrm_input.c) on the skb
> with its decoded payload.
>
> Also, do not confuse IP-in-ESP-over-IPv4 with IP-(in/over)-IP.
> For about every router and subsystem other than xfrm, there
> is no way to look into ESP payload and hence, it's just
> ESP-on-IPv4 or ESP-on-IPv6.

i have to now beg forgivness.  i think i ended up doing some of my testing 
on a rhel/centos 4 box which is only 2.6.9 with ipsec backported.  now 
that i correctly tested on my version 5 box, everything is working as i 
expect.  follow that with a few minutes of code reading and i convinced 
myself that host2host just wasn't doing what i wanted.  i'll go crawl back 
under the rocks now :-).

Re: iptables, ipsec, and host2host

[Joe Pruett]

On Tue, 17 Feb 2009, Joe Pruett wrote:

> i have to now beg forgivness.  i think i ended up doing some of my testing on 
> a rhel/centos 4 box which is only 2.6.9 with ipsec backported.  now that i 
> correctly tested on my version 5 box, everything is working as i expect. 
> follow that with a few minutes of code reading and i convinced myself that 
> host2host just wasn't doing what i wanted.  i'll go crawl back under the 
> rocks now :-).

and i forgot to add that the rhel/centos 4 kernel does not reprocess the 
decrypted/decapsulated packets.  once you accept the ah/esp packet, it 
doesn't go through the iptables again.  this is ok for my scenario where i 
want my central machine to be able to see inside the firewall of the 
remote systems.  i just don't want the remotes to be able to see back 
beyond what the normal firewall allows.  i've already learned about using 
packet marks to allow my net2net traffic to bypass the firewalls and was 
expecting to need the same for host2host and when the first box i tried 
didn't need that, i started digging and got myself turned around.  so at 
least i'm not a total crackpot.

iptables, ipsec, and host2host

[Joe Pruett]

i have been scouring the net and i can't find any clues to whether i can 
do filtering after ipsec has decrypted a packet on a host2host connection. 
net2net goes through the filters a second time, but host2host doesn't seem 
to do that.  is there some other method i can use to filter the traffic 
after being decrypted?

Re: iptables, ipsec, and host2host

[Joe Pruett]

On Wed, 28 Jan 2009, Joe Pruett wrote:

> i have been scouring the net and i can't find any clues to whether i can do 
> filtering after ipsec has decrypted a packet on a host2host connection. 
> net2net goes through the filters a second time, but host2host doesn't seem to 
> do that.  is there some other method i can use to filter the traffic after 
> being decrypted?

ok, i'm following up to myself.  i dug into the kernel source (for 
redhat/centos 5) and have found that there don't appear to be any hooks in 
the ah4.c or esp4.c code to pass packets back through netfilter after 
decapsution/decryption.  from what i can tell tunnel mode (net2net) gets 
the double pass through netfilter only because of the use of the ip-ip 
protocol and ipip.c does a netif_rx call after decapsulation.

so maybe i should go dig into the current (from linus) kernel sources to 
see if there have been any changes.  but i'm hoping that someone here 
might know if there is a reason that ah/esp packets aren't passed through 
netfilter again after being decapsulated/decrypted?  or should i go find 
the ipsec mailing list?

my underlying goal is for a monitoring system that i want to be able to 
see into customer sites via ipsec, but i don't want them to be able to 
come back over the ipsec connection to my system.  i could setup tunnels 
to each site, but host2host is really more what i want.