/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! 
/* ALSO: Don't quote this header. It makes you look lame :-) */


> the reason is that even though incoming packets to any of
> the 3 addresses will get port forwarded correctly, the
> outgoing reply packets will all end up having the same
> source address, that of eth0. needless to say, this will
> confuse tcp/ip stacks who won't consider these reply
> packets to have anything to do with any existing connection.

I had to expect that myself; the fact is I didn't have exact cognition
about how the ftp_masq.o was acting (and had no time to manually check the source).
Sorry if this was a trivial issue. The last time I talked 'bout this with another
Linux fellow he told me that MASQing was expressely done for clients, not
for servers. I simply didn't believe him.

> the solution is to use the iproute2 package to rewrite the
> source address of the reply packets to that of the desired
> "virtual" interface.

I have found it; was still studying it (big thing). Glad to know that
it's the right thing yo check. Will iproute2 need (more) kernel patching
in order to work?

> you can do this by fwmarking the reply
> packets with ipchains on their way in to the masquerading
> host and then doing fwmark nat with the ip utility. read
> the ip command reference that comes with the iproute2 
> package. pay particular attention to appendic C, page 50.

OK! Haven't understood much, but I'm sure I will when I'll check the
right section in the docs of both ipchains and ip. Thank you!


        yo,
        RDO

_______________________________________________
Masq maillist  -  [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ -- 
THIS INCLUDES UNSUBSCRIBING!
or email to [EMAIL PROTECTED]

PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.

Reply via email to