On Mon, Apr 29, 2002 at 10:34:19AM -0400, Joe Patterson wrote: > Actually, you're wrong there. Conntrack will track gre packets. It will, > however, have some possibly-unexpected results when it does. The first gre > packet it sees going from one host to another will be in state NEW. A gre > packet going from the other host to the first one will be in state > ESTABLISHED. Further traffic between those two hosts will be in state > ESTABLISHED. This can be very frustrating if you, as many places do, allow > everything in OUTPUT and allow ESTABLISHED in INPUT. > > Say you ping from host A to host B. (note that these are not necessarily > the gre endpoints, just something that routes across the gre tunnel) The > first icmp echo request hits the gre endpoint, is (we assume) allowed, and > is encapsulated. The gre packet goes out and is in state new. The other > endpoint gets the packet, which is in state new in chain input. That host > drops the packet. Your ping doesn't seem to work. You leave it running. > You connect to a host on the other network, and ping from host B to host A. > The endpoint on the B side gets it, decides to forward it, encapsulates it, > and sends it out. To the B-side, this packet is in state NEW. To the > A-side endpoint, it's part of the connection that was established by the > encapsulated packets from the original ping. As soon as the B-side endpoint > sends it, the packets from the A-side are part of an ESTABLISHED connection. > So your original ping starts working, and your second ping works. And now > everything works fine, and continues to work, until there is a lull in > traffic such that no traffic passes for more than 600 seconds. The entry > gets removed from conntrack, and you're back to square one.
You misunderstood me. I didn't say that connection tracking ignores non-tcp/udp/icmp packets. And, yes, conntrack will track the GRE packets, but from/to the starting/termination point of the tunnel. That is the extend of the netfilter's intelligence about this traffic. What I meant is exactly what you described in your example. There is no association between the GRE header and the encapsulated IP header which I referred to as "ip_conntrack_gre". The reason that one side's ESTABLISHED does not take the GRE traffic as also ESTABLISHED (or RELATED, for that matter) means that the IP header in the GRE payload is not being associated with the GRE header itself as RELATED, hence the need for "ip_conntrack_gre" to make it work transparently. Ramin > > So, the moral of this story is, connection tracking does not ignore > non-tcp/udp/icmp packets. Those packets are tracked. However, in many > cases (such as gre tunnels) the connection tracking done to them is very > seldom useful. You should always specifically allow this traffic, or you > will start having problems that are very frustrating and painful to debug. > (note that the same behavior happens for many tunneling protocols, such as > ipip and IPSec ESP) > > -Joe
