I have a Linux IPSec Tunnel between a GGSN of a network operator and our data center. The IPSec works fine for all traffic but IP Packets coming from our side and are marked with ECN bit set to 0x3 (CE, Congestion experianced) will not encrypted and forwarded to the tunnel.
The Tunnel is setup without ECN support, but for my understanding this should not lead to a packet drop.
Linux Kernel Version is 2.6.18-6-xen-amd64 #1 SMP Fri Dec 12 07:02:03 UTC 2008 x86_64 GNU/Linux (quite old but the xen infrastructure does not allow newer kernels)
Keying Daemon is racoon 0.7.3
Any hints how to overcome this problem?
If something is setting ECN to 0x3 on the outer of the tunnelled packets, without first checking whether the arriving packets are ECN-capable (ECN != 00), this will cause the tunnel egress to drop any packet with ECN == 00 on the inner IP header, but ECN == 0x3 on the outer.
From the question, it sounds like ECN is being set to 0x3 before the tunnel, in which case I can't explain why packets are being dropped. But the question is a bit garbled, so it might be being set within the tunnel, then my explanation would be correct.
The original IETF ECN spec [RFC3168] specified this dropping behaviour for a tunnel egress, and for good reason. ECN != 00 is used by the endpoints to tell the network that they understand ECN (ECN-Capable Transport or ECT). If inner ECN = 00, it means the endpoints won't understand what the network means if it tries to talk ECN. So setting ECN == 0x3 on packets with ECN==00 is defined as an illegal transition. Therefore, if the tunnel discovers packets like this, it is required to drop them, in order to convert the ECN signal into a congestion signal the end-system will understand (drop).
Eaarly IPsec VPNs did not have to conform to this dropping behaviour [RFC4301], but IPsec was harmonized with the original ECN spec in 2010 [RFC6040].
In the question, it's not clear whether ECN = 0x3 is being set on all packets (it certainly shouldn't be). ECN would normally only be set on a tiny fraction of packets, increasing as congestion increases. Then if the tunnel drops these few packets the end systems will perceive a low level of congestion.
If you're using Openswan as I presume, you'll get an answer fastest from #openswan on irc.freenode.net -- that's where the devs hang out, and they will often ask lots of good questions to help you debug your situation.