On Thu, 06 Sep 2007 16:48:15 +0200, Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx> wrote: > Hello, > > stevesz@xxxxxxxxxxx a écrit : >> >> I'm using kernel v. 2.6.22.1, iptables v. 1.3.8. >> I have an ADSL connection with dynamic IP. >> I use ipp2p to indentify and CONNMARK to mark p2p >> traffic. Then I classify the marked packets to a >> low-prio class. This all work fine until the first >> ip change comes. Because ipt_MASQUERADE flushes all >> the conntrack entries which belong to my external >> interface, so the marks are reset along with this. >> Then the p2p traffic goes to the default class, which >> is not good for me. > > I am not sure I understand what the problem is. When the IP address > changes, any existing connections that were using the old IP address are > broken. So new connections have to be established using the new IP > address. New P2P connections should be identified and marked again by > ipp2p and CONNMARK, as the old ones were. Or am I missing something ? In my firewall config it is allowed for any packet to go out from my local network to the internet even it is not in the conntrack. So after my IP has changed and the conntrack table's got flushed, TCP connections continue traversing through the firewall and they get a new entry in the conntrack table, but without a mark. Because they don't get lost, they are not set up again, therefore ipp2p does not recognize them. :-( > >> Is it possible to tell ipt_MASQUERADE not to flush >> these entries, just update them with the new IP? >> Or is there an alternative solution for this? > > You may use SNAT instead of MASQUERADE. Of course you will have to > update the SNAT rule after each IP address change. Or you may hack the > kernel source by commenting out the two ip_ct_iterate_cleanup() calls in > net/ipv4/netfilter/ipt_MASQUERADE.C and rebuild a new kernel. > > But be aware that either way will let the conntrack table filled with > obsolete connections for several days after an IP address change. I was thinking of hacking, just wanted to ask people, if there is some other solution. My plan is to modify the code, so it would replace the old addresses with the new one in the conntrack table keeping the port assignments. Thanx again. I'll try it.
