Lets just focus on FTP right now.
Here's what I got:
[root@linux01 /]# ipchains -L -n
Chain input (policy ACCEPT):
Chain forward (policy DENY):
target prot opt source destination ports
MASQ tcp ------ 167.16.1.30 167.16.1.219 21 ->
21
MASQ tcp ------ 167.16.1.219 167.16.1.30 21 ->
21
MASQ tcp ------ 167.16.1.30 167.16.1.11 21 ->
21
MASQ tcp ------ 167.16.1.11 167.16.1.30 21 ->
21
- all ----l- 0.0.0.0/0 0.0.0.0/0 n/a
Chain output (policy ACCEPT):
[root@linux01 /]# ipmasqadm portfw -l
prot localaddr rediraddr lport rport pcnt
pref
TCP 167.16.1.30 167.16.1.11 ftp ftp 10 10
I get on a client (167.16.1.219) that has connectivity to BOTH 167.16.1.30
and 11.
When I ftp from client to 167.16.1.30 it times out. During the attemp
though here is something interesting:
[root@linux01 /]# ipchains -M -L
IP masquerading entries
prot expire source destination ports
TCP 00:53.09 167.16.1.11 167.16.1.219 ftp (21) -> 1209
So it looks like its working, but not really because it times out.
Got any ideas?
Thanks.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Derrick Daugherty
Sent: Wednesday, June 23, 1999 9:55 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [Ipchains] Re: [Ipchains] IPCHAINS/IPMASQADM Problem...same
segment.
> (30/31). All machines have connectivity with each other and with this
> internet (not that that matters). What I desire to do (actually the
if i understand your description..i think it is....
> problem is larger than this but this is vastly simplified) is make
Machine
> 1 the access point for all FTP, WWW, , telnet, etc for the LAN.
for outbound connects no prob, but for ftp/www/telnet INSIDE the lan you'd
need to CIDR up so they'd have to use him as a gateway...but still not
what ya really need... i havn't played with layer4 routing/switchign that
much so i wouldn't know that one... prolly possible..i've just never done
it ;)
> For instance of a client on Machine 6 opens a telnet session to Machine 1
> then they would get transparently redirected to Machine 2 for instance.
<snip>
> This doesn't work at all.
> I even tried it with ONE NIC and had no luck as well.
one suggestion, put an ipchains -A forward -l since the policy is denied
so you can see if the masqing is being denied at anypoint.
> Can anyone point me in the right direction? I believe the problem has
> something to do with the fact that MASQed packets still look like they are
> coming from the original source. So during the previous example, Machine
2
those packet's headers should be re-written to show that they originate
form the masqing machine, then the destination replies ot him, and he
de-masqs them.
> thinks that it has a telnet session with Machine 6 even though its
supposed
> to be going though the CHAINS machine 1. The return packets actually have
a
> direct path to the client bypassing the MASQ on return. I don't know what
> effect this has on it but it may be a problem.
Any good tcp stack should -not- be able to start a session
to one ip, then receive the rest of that sequence from another ip. i've
never tried to masq on the same segment, only from one segment to another
so i'm curious if it will behave in the way you desire.
I'm guessing the portfw is just redirecting you instead of actually
masq'ing the packets since your on the same segment.
for what it's worth...
you'll get a solid answer as everyone sifts through
their mail ;)
-derrick
> Thanks for any help you can give!
>
> -------------------------------------------
> Provided to you by Matt Hrynkow
>
>
>
> ----------------------------------------------
> To unsubscribe to this list, write an email to
> [EMAIL PROTECTED] with a body of
> 'unsubscribe'.
>
> www.rustcorp.com - web site
> ftp.rustcorp.com - ftp site
>
> Mail Archives:
> http://www.starshadow.com/pipermail/ipchains
>
http://www.progressive-comp.com/Lists/?l=linux-ipchains&r=1&w=2#linux-ipchai
ns
> ----------------------------------------------
>
---End reply
============== =---------= ==============
remember, it's not work unless you'd rather be doing something else.
Harte Hanks Unix Services [EMAIL PROTECTED]
& Infrastructure 512.434.5999
----------------------------------------------
To unsubscribe to this list, write an email to
[EMAIL PROTECTED] with a body of
'unsubscribe'.
www.rustcorp.com - web site
ftp.rustcorp.com - ftp site
Mail Archives:
http://www.starshadow.com/pipermail/ipchains
http://www.progressive-comp.com/Lists/?l=linux-ipchains&r=1&w=2#linux-ipchai
ns
----------------------------------------------
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
http://tiffany.indyramp.com/mailman/listinfo/masq
Admin requests can be handled by web (above) or [EMAIL PROTECTED]
