Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: iptables: User

ipt_MASQUERADE issue

 

 

iptables user RSS feed   Index | Next | Previous | View Threaded


stevesz at enternet

Sep 6, 2007, 6:35 AM

Post #1 of 5 (6899 views)
Permalink
ipt_MASQUERADE issue

Hi All,

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.
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?

Thanx in advance.
Steve


pascal.mail at plouf

Sep 6, 2007, 7:48 AM

Post #2 of 5 (6570 views)
Permalink
Re: ipt_MASQUERADE issue [In reply to]

Hello,

stevesz [at] enternet 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 ?

> 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.


stevesz at enternet

Sep 6, 2007, 8:58 AM

Post #3 of 5 (6590 views)
Permalink
Re: ipt_MASQUERADE issue [In reply to]

On Thu, 06 Sep 2007 16:48:15 +0200, Pascal Hambourg
<pascal.mail [at] plouf> wrote:
> Hello,
>
> stevesz [at] enternet 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.


pascal.mail at plouf

Sep 6, 2007, 9:38 AM

Post #4 of 5 (6582 views)
Permalink
Re: ipt_MASQUERADE issue [In reply to]

stevesz [at] enternet a écrit :
>>
>>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.

Ok. You could change this behaviour by blocking outgoing packets in the
INVALID state.

> So after my IP
> has changed and the conntrack table's got flushed, TCP connections continue
> traversing through the firewall

Sorry but I still do no see how this is possible. The remote hosts
cannot continue previously established TCP connections ("established"
according to the TCP/IP stack, not Netfilter conntrack) with you if your
apparent IP address changes. They will continue to send traffic to your
old IP address and ignore traffic from your new address. A TCP
connection is defined by the source and destination addresses and ports.
If any of these 4 elements changes, the connection is broken.

> 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.

Same remark as above. You cannot change the address of an established
TCP connection.


stevesz at enternet

Sep 7, 2007, 12:51 AM

Post #5 of 5 (6579 views)
Permalink
Re: ipt_MASQUERADE issue [In reply to]

On Thu, 06 Sep 2007 18:38:06 +0200, Pascal Hambourg
<pascal.mail [at] plouf> wrote:
> stevesz [at] enternet a écrit :
>>>
>>>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.
>
> Ok. You could change this behaviour by blocking outgoing packets in the
> INVALID state.
>
>> So after my IP
>> has changed and the conntrack table's got flushed, TCP connections
> continue
>> traversing through the firewall
>
> Sorry but I still do no see how this is possible. The remote hosts
> cannot continue previously established TCP connections ("established"
> according to the TCP/IP stack, not Netfilter conntrack) with you if your
> apparent IP address changes. They will continue to send traffic to your
> old IP address and ignore traffic from your new address. A TCP
> connection is defined by the source and destination addresses and ports.
> If any of these 4 elements changes, the connection is broken.
>
>> 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.
>
> Same remark as above. You cannot change the address of an established
> TCP connection.

Hey, UR absolutely right. I've been thinking too fast. Thanx for correcting
me. But I still don't know why ipp2p does not recognize the resetup. Maybe,
it does not know that 'command'. I think, I'll have to make a capture and
try to isolate the resetup message(s), and the report it to the developer
of
ipp2p.

Thanx again.
Steve

iptables user RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.