Re: [LARTC] Getting AOL IM client to work with IPTABLES and IPROUTE2(port forwarding almost)

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



	Hello,

	I'm answering to two emails ...

On Sun, 28 Oct 2001, Christoph Simon wrote:

> On Sun, 28 Oct 2001 07:28:53 -0600
> "David" <maniacdavid@xxxxxxxxxxxx> wrote:
>
> > I'm trying to get my AOL IM'r to work consistenly with 2 cable modems. It
> > seems like it says it can't connect (90% of the time, 10% it works, just
> > pure luck) when I have both of the cable modems working together with this
> > iproute command

	This is a problem for the routing and the way it is used from NAT.

> > ip route default equalize nexthop via ***.***.***.*** dev eth0 nexthop via
> > ***.***.***.*** dev eth2
> > iptables -A POSTROUTING -t nat -j MASQUERADE -o eth2
> > iptables -A POSTROUTING -t nat -j MASQUERADE -o eth0

	I'm not sure Netfilter can work with multipath routes correctly.
Only TCP can work correctly: rerouting after cache entry expiration, etc.

	OTOH, every usage of multipart routes should take care whether
the different gateways allow traffic with the used source addresses
to pass through all paths. The key in using multipath routes is teaching
the NAT code to correctly use the right source addresses when sending
to each path from the multipath routes, especially when they provide
you with distinct public IP ranges. If someone thinks that this should
work by magic, without coding such feature, he is in wrong direction.

> > Internet and everything else works fine with that. I need a solution whether
> > it be some kind of forwarding (port 5190) so that anything received comes
> > through 1 ethernet address. It might even have to be sent out the same
> > ethernet address but I'm thinking either one would work if there is someway
> > to put a return address on the packet or something. I know AOL im'r works
> > 100% when the linux box is routing just through 1 cable modem.
>
> I'm a bit surprised that you say that `Internet and everything else
> works fine'. I've tried this and it did *not* work properly. Actually,

	Chris, did you asked the Netfilter gurus for such features? [I
hope you received my email from October 20]

> if I did understand it well, the usage of the `equalize' argument to
> ip makes the selection of a particular interface packet based, while
> the omission should make it session base. I have tried all

	I'm not sure the equalize patch is into the mainstream kernel.

> combinations I'm aware of, including weight'ing of the nexthops, and
> it did not work. HTTP based Internet access will fail with any more or
> less elaborated site, as requests will come from more than one
> IP. This doesn't mean that session oriented interface selection
> doesn't work (which I can't tell for sure); it just means that certain
> subsequent complete user sessions need to use the same IP. This might
> be the reason why AIM isn't working, as it seems to expect always the
> same IP from you.

	IMO, Netfilter should be teached to use destination cache and
multipath routes. I already have it completely working for Linux 2.2
masquerade (5 patches) but for 2.4 I'm at 60% (3 of 5 patches):

http://www.linuxvirtualserver.org/~julian/
Under the already incorrect title "Dead Gateway Detection"

	The difficult part that remains is the changes in NAT for 2.4.
I hope, I'll have it working in weeks (I'm always busy with other
stuff). Of course, this period can be reduced if some guru helps me :)
The key features required in NAT are:

- when new NAT connection is created obtain the preferred source address
by looking for the right out device and gateway and use it as masquerade
address

- maintain destination cache entry pointer: when it is obsoleted refresh
it by calling ip_route_output (already done for sockets)

> Christoph Simon
> datageo@xxxxxxxxxxxx

Regards

--
Julian Anastasov <ja@xxxxxx>




[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux