Yeah, the number of connections was pretty low, and there weren't any errors about the table being full. In fact there aren't any kernel/netfilter errors at all getting logged. Dan On Wed, 2005-04-20 at 17:07 +0200, Fabien Germain wrote: > Hi Daniel, > > Did you try to increase ip_conntrack_max ? > (/proc/sys/net/ipv4/netfilter/ip_conntrack_max) > If you use p2p for example, you can quickly reach the limit. > > Hope it helps. > Fabien > > > > On 4/20/05, Daniel Wittenberg <daniel-wittenberg@xxxxxxxxxxx> wrote: > > We've got a high-speed wireless and DSL connection so I decided to try > > and load-balance the out-going connections. I run a little script that > > does: > > > > route flush scope global > > route flush cache > > route add default scope global equalize nexthop via <external gw 1> dev > > eth0 weight 1 nexthop via <external gw 2> dev eth1 > > > > This appears to work for awhile, then incoming connections stop getting > > nat'd to their internal addresses. I reboot or reset the firewall > > (flush all the tables and re-run this script) and things are good again > > for awhile. I tried flooding some of the external IP's that are nat'd > > and it seems like after a certain amount of traffic the nat just stops > > working. tcpdump shows traffic on the external interface coming in, but > > not going out anywhere. > > > > Anyone have ideas on how to debug this further or things to check? > > > > Thanks, > > Dan
