[Bug 792] New: ip_conntrack keep updating incorrect entry in conntrack table after default routing changed

[bugzilla-daemon at bugzilla.netfilter.org]

http://bugzilla.netfilter.org/show_bug.cgi?id=792

           Summary: ip_conntrack keep updating incorrect entry in
                    conntrack table after default routing changed
           Product: netfilter/iptables
           Version: linux-2.6.x
          Platform: x86_64
        OS/Version: Fedora
            Status: NEW
          Severity: minor
          Priority: P5
         Component: ip_conntrack
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: wjguo.netfilterbug at cs.nctu.edu.tw
   Estimated Hours: 0.0


My server has two outgoing interface set with SNAT.
One of them is disconnected, and also as default route. ( interface A,
60.60.60.1)
The other one is connected and workable (interface B, 10.10.10.1)
It has one incoming interface connected with my PC. (192.168.1.0/24)

The reproduce steps are:
1. Using the host under NAT to ping outside like 8.8.8.8. (Windows, with -t)
2. Changing routing from the gateway of interface A (A is not ok) to the
gateway of B( B is ok).
3. The host cannot ping successfully.

I thought it should ping outside successfully, but it didn't.
I captured the packets, and analyzed that it routed to interface B but the
source IP which is modified to 60.60.60.1(A's IP) instead of 10.10.10.1(B's
IP). It was incorrect.

The root cause is that conntrack was still matching the old record and update
its timer. So, it needed that I stop to ping for 30s, or deleting the record
manually.

So, I doubted why it happends only on ICMP, but TCP and UDP not.
I traced the conntrack code, the code of matching the record shows that ICMP
only compares "id, type, code". Those fields are fixed even thought you
create new packets. ICMP always match old one and update its expire time.
I guess that the best way is to compare sequence in ICMP protocol.  

As for TCP and UDP, because source IP is generated randomly. So it didn't match
old one but created new one. This is why TCP and UDP are not effected.

This a little problem.

-- 
Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.