masquerading won't flush conntrack cache

masquerading won't flush conntrack cache

[Michael Hecker]

Hi everyone,

I'm having a strange problems with masquerading.
I'm masquerading my traffic, which leaves my machine through ppp0 on a
dialup line.
When UDP packets leave my machine on the ppp0 interface, an
appropriate entry is created in the conntrack cache
(/proc/net/ip_conntrack). As the remote machine replies to these UDP
packets, the conntrack module sees them as a stream and therefore
increases the timeout to 180 seconds.
However, when my line gets disconnected and reconnects again, the
entries in the cache are not flushed as expected. Now, the
masquerading of outbound traffic is done improperly. The outgoing
packets use the OLD IP-address, which was valid before the
disconnection of the dialup line and not the new one. When I look into
/proc/net/ip_conntrack I can still see the old and now invalid entries
being refreshed every time the internal machine tries to reach the
external one with these UDP packets. As it is clear, that no response
is possible, the internal machine tries endless and the entry in the
conntrack cache never times out --> an endless loop.
Any idea, why the entries are not flushed when ppp0 goes down and up again?

Thanks.
Michael.

Re: masquerading won't flush conntrack cache

[Les Mikesell]

On Thu, 2004-10-14 at 08:17, Michael Hecker wrote:

> However, when my line gets disconnected and reconnects again, the
> entries in the cache are not flushed as expected. Now, the
> masquerading of outbound traffic is done improperly. The outgoing
> packets use the OLD IP-address, which was valid before the
> disconnection of the dialup line and not the new one.

I see exactly the same effect with GRE packets that make it out
the default masq'd interface before the correct route for them
is established.  When the correct route comes up, the packets go
there but continue to be source-NATed with the address of the
incorrect masq-ing interface. It appears to be impossible to ever
change a route after an ip_conntrack entry has been established, at
least when NAT is involved.  Is there a better source for information
about the ip_conntrack module than this list?

---
  Les Mikesell
   les@futuresource.com

Re: masquerading won't flush conntrack cache

[Michael]

My solution for the moment (which is not really a solution), is to
flush all iptable rules and unload all netfilter modules in ip-up,
when the interface goes up again with the new ip-address. However,
this also flushes all other rules, which were not affected by the
external interface (e.g. from eth0 to eth1 or so) and therefore all
state information is lost.

Michael.

On Thu, 14 Oct 2004 09:50:47 -0500, Les Mikesell <les@futuresource.com> wrote:
> On Thu, 2004-10-14 at 08:17, Michael Hecker wrote:
> 
> > However, when my line gets disconnected and reconnects again, the
> > entries in the cache are not flushed as expected. Now, the
> > masquerading of outbound traffic is done improperly. The outgoing
> > packets use the OLD IP-address, which was valid before the
> > disconnection of the dialup line and not the new one.
> 
> I see exactly the same effect with GRE packets that make it out
> the default masq'd interface before the correct route for them
> is established.  When the correct route comes up, the packets go
> there but continue to be source-NATed with the address of the
> incorrect masq-ing interface. It appears to be impossible to ever
> change a route after an ip_conntrack entry has been established, at
> least when NAT is involved.  Is there a better source for information
> about the ip_conntrack module than this list?
> 
> ---
>  Les Mikesell
>   les@futuresource.com
> 
>

Re: masquerading won't flush conntrack cache

[Les Mikesell]

On Thu, 2004-10-14 at 10:13, Michael wrote:
> My solution for the moment (which is not really a solution), is to
> flush all iptable rules and unload all netfilter modules in ip-up,
> when the interface goes up again with the new ip-address. However,
> this also flushes all other rules, which were not affected by the
> external interface (e.g. from eth0 to eth1 or so) and therefore all
> state information is lost.

I can fix my particular situation with this approach because the
'correct' route is through a VPN tunnel that normally stays up
once it is established, but this seems like a fairly serious bug
in terms of general purpose routing since you should be able to
change routes on the fly and have the new route work without disrupting
other connections.

---
  Les Mikesell
    les@futuresource.com