Hi, I am trying to do simple round robin load balancing of GRE packets using iptables 'statistic' extension. I have multiple rules in sequence that DNAT the packets to specific IPs. But the problem is as soon as first GRE packet is received and DNATted, connection tracking makes an entry for it and all the subsequent GRE packets get DNATted to the same IP. What's more surprising is that, if I see the counters of the DNAT rule entry, its value stays at one. This implies that all subsequent packets are getting DNATted because of connection tracking and not because of DNAT rule. I confirmed this by deleting all the DNAT rules and surprised to see that packets were still getting DNATted until I flush the GRE connection from connection tracking. Here are the details of how I want to achieve load balancing but due to Connection Tracking I am unable to achieve the same. iptables -t nat -A PREROUTING -m statitstic -p GRE -d 172.16.96.173 --mode nth --every 2 --packet 0 -j DNAT --to 15.0.0.2 iptables -t nat -A PREROUTING -m statitstic -p GRE -d 172.16.96.173 --mode nth --every 1 --packet 0 -j DNAT --to 15.0.0.3 '172.16.96.173 is the GRE tunnel endpoint which I intend to load balance.' My intentions are to DNAT GRE packets in a round robin fashion between 15.0.0.2 and 15.0.0.3. I believe my logic is fine but the way DNATted GRE packets are tracked by netfilter connection tracking it is not working. What I have understood so far is that, unlike TCP where source port gets changed frequenlty, all the GRE packets hitting my router have same source and destination IP and 'GRE key', connection tracking treats them as packets of same connection. If I keep on flushing DNAT GRE connecton using conntrack command line, the things seem to work, BUT is it the only possible SOLUTION ? Please SUGGEST what am i MISSING and how I can ACHIEVE my goals. I can provide further details of my setup if needed. Thanks Karan Pugla -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
