I will try a newer version, thank you
>>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
> 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.