I will try a newer version, thank you

On 1/27/06, Patrick McHardy <kaber@trash.net> wrote:
reydecopas wrote:
>>But the source address of this packet will be GW_A's external IP address.
>>Have you got a security policy in place for IPSEC encrypting traffic with a
>>source of GW_A(ext) and dest of lanB?
>
>
> The source address of this packet is the lanA ip address which was the
> destiny of the original packet,
> though this packet is generated in GW_A, is generated by "iptables -Reject"
> in this way.
> So this packet match with the policy (src_address is lanA and dst_address is
> lanB). I noticed that with tcpdump...
>
> What I see is that this packet generated by iptables is bypassing the
> policies
>
> If I remove iptables from GW_A and I put the same rules on the server on
> lanA it works perfectly, because the packet is the same but generated in a
> machine inside the lanA behind the GW_A, which  sends it into the TUNNEL so
> itīs not a mismatch of policies. I think  it has to be something related
> with  level of the priority  in the   tcp/ip  stack between  setkey policies
> and iptables chains

Older linux versions had a bug that made packets generated by ipt_REJECT
bypass IPsec. Current versions of the kernel should work fine.