OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: inet_interfaces with virtualdomain and localhost
From: Will Day (willdayrom.oit.gatech.edu)
Date: Thu Nov 02 2000 - 01:40:34 CST

A short time ago, at a computer terminal far, far away, Richard Huxton wrote:
>> I want outgoing mail to originate with the ip addr on eth0:1, so I
>> configured thus:
>>
>> However, outgoing mail still originates from the real ipaddr
>> (door.house.com).
>
>Are you sure this isn't a routing issue? Postfix should be announcing itself
>based on $myhostname (telnet to port 25 to check) but when it sends mail it
>will use whatever interface is set up in the routing table. So, if eth0 is
>the default route, that will be the one used. Have I got the problem right
>here?

Well, the thing was, I _didn't_ want it to go out the default route
interface, but rather, the other interface - while wanting all other
traffic to continue going out the default route interface.

>I don't think you can have smtp traffic using one interface and everything
>else on the other, but maybe the new ip code in the 2.2+ kernels can.

Generally, that appears to be the case. As far as I know, routing has
traditionally let you choose outgoing interface based only on the
destination _IP address_, and not things like which tcp port the packet is
sourced from or destined to. In order to have traffic of a particular port
go out one interface as opposed to the other, you'd have to either (a) have
the application bind() to a particular local ip address (corresponding to
the interface) before doing the connect() (as done above in the postfix
config), or (b) have access to some of the new-fangled routing that can
decide based on port/protocol or other criteria.

With the linux 2.2 kernels, it appears you can combine ipchains with
iproute2, to mark packets based on given criteria (like port), and then
route based on those marks. However, the marking/routing appears to work
only for _incoming_ packets, and not _locally generated_ packets, because
of the order of the packet pipeline (locally generated packets can only be
marked in the "output" filter, and routing decisions have already been made
by that time). That is, it would work if the linux machine were a
firewall, and the SMTP traffic were generated on a machine behind the
firewall, but it _won't_ work if the SMTP traffic is generated on the linux
firewall machine itself..

However, it looks like the 2.4 kernel and the new "netfilter"
infrastructure, which replaces ipchains with "iptables", has changed the
packet pipeline around a bit, plus it seems to now re-evaluate routing
after the "output" filter, so you can mark packets and then have them
routed based on the mark. Then you could, indeed, route all outgoing
(locally generated) HTTP through one interface, and all SMTP out another
interface, or even funky things like one user's traffic out a different
interface from another user's traffic. It looks pretty slick. :)

I haven't finished getting a 2.4 kernel up and running, though, so I
haven't been able to test it out.

In any case, that was probably more than you really wanted to know. :) But
since I've spent the last few days searching dejanews, google, HOWTO's,
mailing lists, and any number of linux/networking/firewall/masquerading
pages to try and find out if it could be done, I felt I needed to share. :) 

-- 
Will Day     <PGP mail preferred>     OIT / O&E / Technical Support
willdayrom.oit.gatech.edu            Georgia Tech, Atlanta 30332-0715
  -> Opinions expressed are mine alone and do not reflect OIT policy <-
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    Benjamin Franklin, Pennsylvania Assembly, Nov. 11, 1755
  • application/pgp-signature attachment: stored