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. 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 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ramin Alidousti > Sent: Monday, April 29, 2002 9:59 AM > To: Dani Arbel > Cc: [EMAIL PROTECTED]; Mark Orenstein > Subject: Re: GRE tunneling & ipfilters > > > On Mon, Apr 29, 2002 at 04:56:05PM +0300, Dani Arbel wrote: > > > Hi! > > To support GRE tunnel, you would need rules both in INPUT and OUTPUT > > chains, since conntrack do not track them. > > Right. I knew that the conntrack wouldn't track them because > there is no ipt_conntrack_gre module which contains the GRE > intelligence. But, thanks. Now I know that INPUT/OUTPUT is the > starting/termination points. > > Ramin > > > Dani > > > > On Mon, 29 Apr 2002, Ramin Alidousti wrote: > > > > > On Sun, Apr 28, 2002 at 09:04:00PM -0400, Mark Orenstein wrote: > > > > > > > Quoting Ramin Alidousti <[EMAIL PROTECTED]>: > > > > > Yes. Once when it comes through the physical interface. > There, netfilter > > > > > would see it as an IP packet with protocol 47 (GRE). And > once when the > > > > > packets come out of the GRE tunnel. Here again, netfilter > would see IP > > > > > packets but the protocol part would be TCP/UDP/ICMP... > > > > > > > > > > Try these rules to see the association: > > > > > > > > > > $IPT -A FORWARD -i <physical-interface> -p 47 -j LOG > > > > > $IPT -A FORWARD -i <gre-interface> -j LOG > > > > > > > > > > Ramin > > > > > > > > > Thanks very much Ramin, one more question though. Would > the first rule above > > > > actually be in the INPUT chain? I'll be in school tomorrow > morning, so I will > > > > be able to experiment to get a better understanding. > > > > > > A very good point Mark. I don't know but having thought about it, what > > > you said sounds absolutely right. The first rule might not > work as those > > > packets are not meant to get routed. Please do test both and > let me know > > > the outcome. Thank you. > > > > > > Ramin > > > > > > > > > > > Thanks again, > > > > Mark Orenstein > > > > East Granby, CT School System > > > > >
