Possible bug ipsec and SNAT?

Possible bug ipsec and SNAT?

[Slagter, EM]

Hi,

I don't know whether this netfilter behaviour is a bug or intentional,
but at least for me it's not what I'd expect (nor want).

Our system (simplified to significant parts):
- linux i386 kernel 2.6.21.2 vanilla, almost all netfilter and ipsec
parts compiled in, no (relevant) modules
- one vlan interface connected to public internet
- one vlan interface connected to internal vlan, RFC addresses
- pluto ("openswan") to manage ISAKMP, appropriate config file
- some netfilter rules that include -m policy to separate the ipsec
traffic before and after encapsulation (for instance to prevent traffic
to be sent over internet without encryption)

Using this scenario, it works pretty much as documented.

As soon as I add SNAT to traffic originating from this vlan (as required
by our supplier), the rules that (properly) used to match on "-m policy
--pol ipsec --dir out --tunnel-src ... --tunnel-dst ..." no longer
match. Even if I remove the tunnel-src and --tunnel-dst the rule no
longer matches. If I change "the --pol ipsec" to "--pol none" the rule
matches again. This is wrong IMHO as the traffic is still encapsulated
(checked this with tshark) as expected.

I've checked the ChangeLogs of the kernel from 2.6.21.2 to current but
there doesn't seem to have been a relevant patch on this matter.

"Please help" ;-)

Re: Possible bug ipsec and SNAT?

[Patrick McHardy]

Slagter, EM wrote:
> Hi,
> 
> I don't know whether this netfilter behaviour is a bug or intentional,
> but at least for me it's not what I'd expect (nor want).
> 
> Our system (simplified to significant parts):
> - linux i386 kernel 2.6.21.2 vanilla, almost all netfilter and ipsec
> parts compiled in, no (relevant) modules
> - one vlan interface connected to public internet
> - one vlan interface connected to internal vlan, RFC addresses
> - pluto ("openswan") to manage ISAKMP, appropriate config file
> - some netfilter rules that include -m policy to separate the ipsec
> traffic before and after encapsulation (for instance to prevent traffic
> to be sent over internet without encryption)
> 
> Using this scenario, it works pretty much as documented.
> 
> As soon as I add SNAT to traffic originating from this vlan (as required
> by our supplier), the rules that (properly) used to match on "-m policy
> --pol ipsec --dir out --tunnel-src ... --tunnel-dst ..." no longer
> match. Even if I remove the tunnel-src and --tunnel-dst the rule no
> longer matches. If I change "the --pol ipsec" to "--pol none" the rule
> matches again. This is wrong IMHO as the traffic is still encapsulated
> (checked this with tshark) as expected.
> 
> I've checked the ChangeLogs of the kernel from 2.6.21.2 to current but
> there doesn't seem to have been a relevant patch on this matter.


This is expected behaviour. Before NAT takes place, the packet
doesn't match a policy, it only does after getting mangled by
NAT, but at that point it already passed through your policy
matches.

Re: Possible bug ipsec and SNAT?

[Slagter, EM]

Patrick McHardy wrote:

>> As soon as I add SNAT to traffic originating from this vlan (as required
>> by our supplier), the rules that (properly) used to match on "-m policy
>> --pol ipsec --dir out --tunnel-src ... --tunnel-dst ..." no longer
>> match. Even if I remove the tunnel-src and --tunnel-dst the rule no
>> longer matches. If I change "the --pol ipsec" to "--pol none" the rule
>> matches again. This is wrong IMHO as the traffic is still encapsulated
>> (checked this with tshark) as expected.

> This is expected behaviour. Before NAT takes place, the packet
> doesn't match a policy, it only does after getting mangled by
> NAT, but at that point it already passed through your policy
> matches.

I think we're not talking about the same thing :-/

I have a rule in the filter table like this:

iptables -t filter -A FORWARD -i ... -o ... -s ... -d ... -m policy
--mode tunnel --pol ipsec --dir out --tunnnel-src ... --tunnel-dst ...
-j ACCEPT

This rule works as expected, it matches certain ipsec traffic as intended.

As soon as I add a rule like this to the nat table:

iptables -t nat -A POSTROUTING -s ... -d ... -j SNAT --to-source ...

then the OTHER rule (above, the one in the filter table) doesn't match
anymore. This has nothing to do with the source address having changed
because even in this "bare" form:

iptables -t filter -A FORWARD -i ... -o ... -m policy --pol ipsec --dir out

it doesn't match.

This one does match (changed --pol ipsec into --pol none):

iptables -t filter -A FORWARD -i ... -o ... -m policy --pol none --dir out

Yet the traffic IS being encapsulated like before I applied the SNAT rule.

That doesn't seem right to me.

Maybe it's just that I take the wrong approach to the problem; our
supplier requires an ipsec "tunnel" where our internal ip addresses are
translated to a public ip address, I am talking about the encapsulated
packets here, not the ESP packets. With my approach and the current
behaviour, I cannot apply policies properly for this traffic. I am not
at all happy with the situation, but I cannot change it :-(

Thx.

Re: Possible bug ipsec and SNAT?

[Patrick McHardy]

Slagter, EM wrote:
> Patrick McHardy wrote:
> 
>> This is expected behaviour. Before NAT takes place, the packet
>> doesn't match a policy, it only does after getting mangled by
>> NAT, but at that point it already passed through your policy
>> matches.
> 
> I think we're not talking about the same thing :-/
> 
> I have a rule in the filter table like this:
> 
> iptables -t filter -A FORWARD -i ... -o ... -s ... -d ... -m policy
> --mode tunnel --pol ipsec --dir out --tunnnel-src ... --tunnel-dst ...
> -j ACCEPT
> 
> This rule works as expected, it matches certain ipsec traffic as intended.
> 
> As soon as I add a rule like this to the nat table:
> 
> iptables -t nat -A POSTROUTING -s ... -d ... -j SNAT --to-source ...
> 
> then the OTHER rule (above, the one in the filter table) doesn't match
> anymore. This has nothing to do with the source address having changed
> because even in this "bare" form:
> 
> iptables -t filter -A FORWARD -i ... -o ... -m policy --pol ipsec --dir out
> 
> it doesn't match.
> 
> This one does match (changed --pol ipsec into --pol none):
> 
> iptables -t filter -A FORWARD -i ... -o ... -m policy --pol none --dir out
> 
> Yet the traffic IS being encapsulated like before I applied the SNAT rule.
> 
> That doesn't seem right to me.


Does this rule apply in the direction you do SNAT or to reply packets?
Please post the rules including IP addresses.

Re: Possible bug ipsec and SNAT?

[Slagter, EM]

> Does this rule apply in the direction you do SNAT or to reply packets?
> Please post the rules including IP addresses.

After a lot more testing and tweaking it seems to be a bug in Open/SWAN
in combination with the 2.6 ipsec kernel implementation. If I create TWO
connections in /etc/ipsec.conf, one with the original source address AND
one with the SNATted source address, everything works as expected. So
apparently the bug is not in netfilter :-/

With ipsec configured as stated, it works with SNAT and DNAT like a
charm, correct, complete policy information is available in all rule
sections I use (filter-FORWARD, nat-PREROUTING and nat-POSTROUTING) :-)

Sorry for the fuzz.