NAT behind IPSEC GW working OK - please review patch

NAT behind IPSEC GW working OK - please review patch

[Robert Borger]

Hello,

I have a subnet behind an IPSEC GW which is
NATed to the IPSEC GW address.  The IPSEC tunnel
is between the GW host address and the subnet
behind the remote IPSEC GW. It is required that
the NATed packets from the local subnet and the
packets originating on the GW must both pass
through the tunnel to the remote subnet.

Before applying the Patrick McHardy ipsec0x
and policy patches, there where problems
getting the NATed packets out over the tunnel.

After the patches where applied, the packets
got out the tunnel and returned via the tunnel
as expected, but were dropped during forwarding.

It appeared that the packet was still considered
to be an part of the encrypted stream and there
was no policy to forward it to the local subnet.

I changed the "xfrm_policy_check" function in
"./include/net/xfrm.h" to allow forwarding if
the "decap_done" flag is set.

Does anyone see any detrimental effects for this change?

Could I have achieved the same result with a
configuration change?

I started with a virgin 2.6.10 kernel then applied the
Patrick McHardy patches ported for the 2.6.10 kernel from:
http://www.zcu.cz/ftp/pub/network/shorewall/contrib/IPSEC

Then I made this change to "xfrm.h":

static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff
*skb, unsigned short family)
{
  if (sk && sk->sk_policy[XFRM_POLICY_IN])
    return __xfrm_policy_check(sk, dir, skb, family);
		
  return(!xfrm_policy_list[dir] && !skb->sp) ||
    (skb->sp && skb->sp->decap_done) || /* Added this line */
    (skb->dst->flags & DST_NOPOLICY) ||
    __xfrm_policy_check(sk, dir, skb, family);
}


Thank You,
Bob Borger

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.1 - Release Date: 3/9/05
 

Re: NAT behind IPSEC GW working OK - please review patch

[Christophe Saout]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

Am Freitag, den 11.03.2005, 11:38 -0600 schrieb Robert Borger:

> After the patches where applied, the packets
> got out the tunnel and returned via the tunnel
> as expected, but were dropped during forwarding.
> 
> It appeared that the packet was still considered
> to be an part of the encrypted stream and there
> was no policy to forward it to the local subnet.
> 
> I changed the "xfrm_policy_check" function in
> "./include/net/xfrm.h" to allow forwarding if
> the "decap_done" flag is set.
> 
> [...]

> Then I made this change to "xfrm.h":
> 
> static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff
> *skb, unsigned short family)
> {
>   if (sk && sk->sk_policy[XFRM_POLICY_IN])
>     return __xfrm_policy_check(sk, dir, skb, family);
> 		
>   return(!xfrm_policy_list[dir] && !skb->sp) ||
>     (skb->sp && skb->sp->decap_done) || /* Added this line */
>     (skb->dst->flags & DST_NOPOLICY) ||
>     __xfrm_policy_check(sk, dir, skb, family);
> }

I can confirm that this fixes the problem you described.
(I'm using the IPSEC+NAT patches I forward-ported for 2.6.11).

The line you added should be enclosed in an pair of #ifdef
CONFIG_NETFILTER and #endif.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: NAT behind IPSEC GW working OK - please review patch

[Patrick McHardy]

Christophe Saout wrote:
>>static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff
>>*skb, unsigned short family)
>>{
>>  if (sk && sk->sk_policy[XFRM_POLICY_IN])
>>    return __xfrm_policy_check(sk, dir, skb, family);
>>		
>>  return(!xfrm_policy_list[dir] && !skb->sp) ||
>>    (skb->sp && skb->sp->decap_done) || /* Added this line */
>>    (skb->dst->flags & DST_NOPOLICY) ||
>>    __xfrm_policy_check(sk, dir, skb, family);
>>}
> 
> 
> I can confirm that this fixes the problem you described.
> (I'm using the IPSEC+NAT patches I forward-ported for 2.6.11).
> 
> The line you added should be enclosed in an pair of #ifdef
> CONFIG_NETFILTER and #endif.

This is not correct, the reason why the packets are dropped
is most likely a missing forward policy. If this is not the
case, there must be a bug somewhere in nf_nat_decode_session4().

Regards
Patrick

Re: NAT behind IPSEC GW working OK - please review patch

[Andrew Hall]

> Christophe Saout wrote:
>>>static inline int xfrm_policy_check(struct sock *sk, int dir, struct 
>>>sk_buff
>>>*skb, unsigned short family)
>>>{
>>>  if (sk && sk->sk_policy[XFRM_POLICY_IN])
>>>    return __xfrm_policy_check(sk, dir, skb, family);
>>>
>>>  return(!xfrm_policy_list[dir] && !skb->sp) ||
>>>    (skb->sp && skb->sp->decap_done) || /* Added this line */
>>>    (skb->dst->flags & DST_NOPOLICY) ||
>>>    __xfrm_policy_check(sk, dir, skb, family);
>>>}
>>
>>
>> I can confirm that this fixes the problem you described.
>> (I'm using the IPSEC+NAT patches I forward-ported for 2.6.11).
>>
>> The line you added should be enclosed in an pair of #ifdef
>> CONFIG_NETFILTER and #endif.
>
> This is not correct, the reason why the packets are dropped
> is most likely a missing forward policy. If this is not the
> case, there must be a bug somewhere in nf_nat_decode_session4().
>
> Regards
> Patrick
>
There definately seems to be an issue somewhere, because I haven't been able 
to get SNAT working via the tunnel in transport mode without this patch, but 
this maybe an issue with my understanding of how the policy match works. Can 
you please confirm the following:

Traffic that requires SNAT modification will need a policy match to be 
applied to a rule in the POSTROUTING chain. IPSEC with your patches applied 
will make the traffic pass the POSTROUTING chain twice. The first time is 
clear, and the second time is encrypted. To mark packets for translation we 
set a rule something like the following:

iptables -A POSTROUTING -t nat -s 10.1.1.0/24 -d 10.1.2.0/24 -m policy --pol 
none -j SNAT --to-source 11.1.1.200

Is this correct? Setting pol = none matches on traffic that has not yet been 
encrypted (but will be next time through the chain), and pol = ipsec matches 
on traffic that has already been encrypted (for POSTROUTING) and visa versa 
for PREROUTING? Your confirmation will help clarify if I'm doing this 
properly or if there is infact a problem with my configuration.

Thanks,
Andrew. 

Re: NAT behind IPSEC GW working OK - please review patch

[Christophe Saout]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

Am Sonntag, den 20.03.2005, 17:12 +0100 schrieb Patrick McHardy:

> This is not correct, the reason why the packets are dropped
> is most likely a missing forward policy. If this is not the
> case, there must be a bug somewhere in nf_nat_decode_session4().

You were right. Actually it's working without the patch, I was just too
stupid to allow forwarding in the other direction when I tested it the
first time.

And there actually was a bug in my nf_nat_decode_session4 when using
both SNAT and DNAT.

The updated version of ipsec-04-policy-checks.diff can be found at
http://www.saout.de/misc/linux-2.6.12-rc1-ipsec-nat/

The patches are against linux-2.6.12-rc1, but the only change compared
to linux-2.6.11 is ipsec-01-output-hooks.diff.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: NAT behind IPSEC GW working OK - please review patch

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 3140 bytes --]

* Christophe Saout (christophe@saout.de) wrote:
> Am Sonntag, den 20.03.2005, 17:12 +0100 schrieb Patrick McHardy:
> > This is not correct, the reason why the packets are dropped
> > is most likely a missing forward policy. If this is not the
> > case, there must be a bug somewhere in nf_nat_decode_session4().
> 
> You were right. Actually it's working without the patch, I was just too
> stupid to allow forwarding in the other direction when I tested it the
> first time.
> 
> And there actually was a bug in my nf_nat_decode_session4 when using
> both SNAT and DNAT.
> 
> The updated version of ipsec-04-policy-checks.diff can be found at
> http://www.saout.de/misc/linux-2.6.12-rc1-ipsec-nat/
> 
> The patches are against linux-2.6.12-rc1, but the only change compared
> to linux-2.6.11 is ipsec-01-output-hooks.diff.

Using these patches (except w/ ipsec-01-output-hooks.diff from the prior
thread w/ 2.6.11 since the one from the URL above didn't patch cleanly)
I seem to still be having a problem with certain situations.  Hopefully
you all might be able to shed some light on it.  This is the situation:

IPSEC tunnels using strongswan for:
A <--> B
A <--> B/subnet *
subnet/A <--> B *
subnet/A <--> B/subnet

This all worked just fine under 2.6.10 w/ the 2.6.10 ipsec/netfilter
patches.  Using 2.6.11.6 the two *'d tunnels don't seem to be working.  
When trying to ping from A to B/subnet what I see happening is this:

Packet from A is encrypted using the appropriate tunnel going from 
A to B.  On B I see the packet going through the firewall rules I have
set up in iptables and see the appropriate response is generated and
according to tcpdump on B the return packet is encrypted and sent out
the correct B -> A tunnel.  I don't see that encrypted return packet 
on A though, again according to tcpdump.  I also see both the icmp 
return packet and the encrypted packet pass through the OUTPUT chain 
of B, which is what I'd expect.  I also don't see the encrypted or 
unencrypted return packet from B to A in the chains of netfilter 
on A (checked INPUT and nat/PREROUTING).

subnet/A and B/subnet are subnets on the localhost interface of the
associated machine using aliases, technically.  This didn't seem to
bother 2.6.10 at all and I wouldn't expect 2.6.11.6 to care but I wanted
to put that out there too in case it makes a difference.  I could test
w/ real interfaces if necessary but what I actually want working is with
them on localhost.  Additionally, I'm using Vserver 1.9.5 (which is why
I want things on localhost to work in this setup).  Again, worked fine
under 2.6.10 and wouldn't expect it to be a problem.

I understand that people using 2.6.11 have this working w/o the
netfilter patches (at least the A <--> B/subnet part, don't know if
they've tried it w/ using localhost but wouldn't expect that to make a
difference...)..

I've also tried disabling all the firewall rules on both systems and
still the same problem.  I'm probably going to try w/o the patches but
I'd really like to have them..

Any thoughts?

	Thanks,

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]